Live data from Hacker News

Life, the Universe and Technical Interviews

diegobasch.com

11–15 of 15 posts

Re: Life, the Universe and Technical Interviews

#11
post #7
post #3

I tend to ask what I think is a rather simpler question in most interviews: find the sum of the two largest (most positive) numbers in an array of arbitrary integers. Consider the efficiency of your solution for very large arrays. It is amazing how many seemingly knowledgeable, intelligent people cannot do this. And the vast majority of those who do, do it by sorting the array, efficiency be damned. Actually, I'd lik…

I have seen plenty of useful code far worse than sorting such an array. IMO, someone missing the 'obvious' choice in an interview question is completly reasonable. Thinking back how many people verified that the array was non empty and it had more than one element? I call it the toy problem mindset, when coding you consider things deeply but in meetings your looking for roadblocks not optimal solutions. PS: From a pr…

Most people didn't think to check that the array had at least two elements, but more did that than managed to correctly loop through it.

I'm not sure what your PS is referring to. Which posted solutions, and what article?

Re: Life, the Universe and Technical Interviews

#12
post #7

Earlier quoted context omitted.

I have seen plenty of useful code far worse than sorting such an array. IMO, someone missing the 'obvious' choice in an interview question is completly reasonable. Thinking back how many people verified that the array was non empty and it had more than one element? I call it the toy problem mindset, when coding you consider things deeply but in meetings your looking for roadblocks not optimal solutions. PS: From a pr…

Most people didn't think to check that the array had at least two elements, but more did that than managed to correctly loop through it. I'm not sure what your PS is referring to. Which posted solutions, and what article?

link at the top...

"life the universe and technical interviews" http://diegobasch.com/life-the-universe-and-technical-interv....

Every solution has a loop 1 to 1000000 which is N but then they check every digit which is a log N making them N log N solutions. But there are Log N solutions that avoid checking every possibility.

Ex:

s dup if 10 /mod recurse + then ; : f 0 1000000 0 do i s 42 = if 1 + then loop ;

Re: Life, the Universe and Technical Interviews

#13
post #9

Earlier quoted context omitted.

Solution is just to have two indices into it leapfrogging as they find the next biggest one, right, and sum at the end if they've moved? Why would you sort?

My thoughts exactly. O(n) vs O(nlog(n)). Or even if you don't have formal comp sci experience, it seems intuitive that sorting the entire array (which I specify could be large) just to get the two highest values is overkill. Want to apply to our full stack developer position? Edit: Out of curiosity, what would you initialize the two tracking variables to?

Initialization is language dependent, of course :-)

Re: Life, the Universe and Technical Interviews

#14
post #9

Earlier quoted context omitted.

Solution is just to have two indices into it leapfrogging as they find the next biggest one, right, and sum at the end if they've moved? Why would you sort?

My thoughts exactly. O(n) vs O(nlog(n)). Or even if you don't have formal comp sci experience, it seems intuitive that sorting the entire array (which I specify could be large) just to get the two highest values is overkill. Want to apply to our full stack developer position? Edit: Out of curiosity, what would you initialize the two tracking variables to?

So, both variables are just indices, so we'll just start them at the first and second elements in the array. The smaller of the two we'll start marching forward, comparing against the value at the larger. Once the value is larger, we'll start marching the other one forward until we hit the end of the array.

At this point, I realize that if we just reuse the indices, life becomes difficult if we don't encounter a larger value later in the array and hence we lose the smaller of the two largest values.

So, instead, let's start with three indices (Biggest,Biggerest,Curr), set at the first, second, and third positions. So, now, we'll just move the Curr index forward, and if it encounters a value larger than the the current largest value, we'll set the index of the Biggerest into the Biggest and the index of the Curr into the Biggerest. We can then continue until we hit the end of the array, and add the values under the Biggest and Biggerest indices.

I think that'll work.

EDIT: For cleanliness' sake, we could init the Curr and Biggerest to both point at the second element of the array, but there may be a little special-case code there to worry about and I'm not awake enough yet for that. :)

Re: Life, the Universe and Technical Interviews

#15
post #9

Earlier quoted context omitted.

My thoughts exactly. O(n) vs O(nlog(n)). Or even if you don't have formal comp sci experience, it seems intuitive that sorting the entire array (which I specify could be large) just to get the two highest values is overkill. Want to apply to our full stack developer position? Edit: Out of curiosity, what would you initialize the two tracking variables to?

So, both variables are just indices, so we'll just start them at the first and second elements in the array. The smaller of the two we'll start marching forward, comparing against the value at the larger. Once the value is larger, we'll start marching the other one forward until we hit the end of the array. At this point, I realize that if we just reuse the indices, life becomes difficult if we don't encounter a larg…

That sounds about right. Initializing the variables to the first two elements in the array is something very few people think to do. Most people set them to 0, which obviously doesn't work if the array doesn't contain at least two positive values. Of course, Blackthorn is also right that it's language-dependent. Most languages give you negative infinity, or treat null or false as negative infinity in comparisons, which makes things simpler.
Post reply on HN