Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to get hired (or, 'The silly story of interviewing in the valley')

trapm.com

Post reply on HN
Print view View original

11–20 of 178 posts

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#11

Post by Stwerner »

robobenjie wrote: post #6
Aqua_Geek wrote: post #2

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

We use these types of questions to allow an applicant to show us that they can, in fact, write a simple program (see http://www.codinghorror.com/blog/2007/02/why-cant-programmer... ) and we use programming puzzles to make it more interesting for the bright candidates.

Are there any good sites out there that have a lot of these types of problems that are asked in interviews? Sites like http://spoj.pl seem to have problems that are more longer form. But it would be fun to start practicing solving the shorter ones that are asked without the hassle of interviewing to get them.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#12

Post by Aqua_Geek »

ejames wrote: post #7
Aqua_Geek wrote: post #2

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

Yes, interview questions like this are common. The problem with "practical application" questions is that the answer almost always comes down to "it depends". The correct optimization or fix is specific to the actual thing you are doing; that's what makes it practical. In order for an interview question to be useful, both the interviewer and the interviewee must be able to answer it. The applicant doesn't know the in…

> The problem with "practical application" questions is that the answer almost always comes down to "it depends."

Agreed. Talking about application of theory is way too vague and leaves way too much room for bs. But I think my original point was unclear. I'm not suggesting that interview questions be "When would you use a linked list?" but rather "Let's hack on something using a linked list (something beyond just simply reversing it)." Like the article mentions, once you've built a linked list before and have optimized (and reversed) it to death, there's little to be gained from doing it again for somebody else.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#13

Post by groby_b »

sgrove wrote: post #9
timr wrote: post #3

"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…

Yeah, that was more or less the point of the post. For applicants, don't feel nervous, it's a silly game just to see if you know some of the puzzles. For people hiring, go ahead and use this as a first-pass filter, but realize that it's easy to game (by someone who's trying hard and learning, so there is a positive signal in that). It's going to be important to go through and work with them for a period of time in a…

In all my history of interviewing people, I've always found there's almost no info to be had in correct answers to any kind of question. You learn about a candidate once you guide them into territory where the fail.

Both where that line is, and how they handle the failure tells you a lot.

(Caveat: Make sure you're keeping it on the fail/no-fail edge, and you treat the candidate with respect. The point is not to show them that they're wrong, but to explore the boundaries of their skill set. Without being mean is a major goal here)

And if you can't push the candidate there: HIRE THEM. Right away. If they know that much more than you do that you can't get them beyond their limits, they are a fantastic addition to your team. (Provided they match personality-wise, too)

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#14

Post by kenjackson »

timr wrote: post #3

"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…

I have some simple baseline questions I ask everyone. Getting it right just means we continue the rest of the interview, but doesn't get you a job.

I almost always have a programming question I just made up 30 minutes before the interview. I make sure that I can easily do it in 10 minutes and then ask it. It really isn't important to me if they get they answer, but I want to see what questions they have, and how they think. Good candidates will usually get it coded, but some may get hung up on something early on, but still make good progress.

If they come in with a precanned response to my question then they're either a mindreader or can time travel. In either case, I still went them on my team.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#15

Post by gcp »

Aqua_Geek wrote: post #2

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process).

Why is so much emphasis placed on the theory of how linked lists work (for example) instead of the practical application of where they'd be used?

Edit: Big O notation is great and all, but shouldn't the emphasis be more on shipping than optimizing? You can optimize your MVP to death, but if you never finish it what good does that do?

I feel the third paragraph here conflicts with the second one. In effect, understanding Big O would help you identify where linked lists are applicable. You seem to want to be given an exhaustive list of where they should be used. Sorry, but that's not how programming works.

Secondly, I take issue with the "limiting your applicant pool to only those who got a CS degree". If you're going to work in the CS field, I think its only normal you are asked question to see if you've got a grasp of the foundations of your job. You don't need a CS degree for that, there exists such a thing as self-study, and I think its a very reasonable thing to require if you're trying to transition between fields.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#16

Post by observer1 »

"....this process, starting from ~50+ raw leads whittled down into ~40 initial phone interviews/coding challenges, which went to ~25 next stage interviews, eventually down to ~6 really good offers, all in about ~1.5 weeks."

Does this timeframe seem a little dubious to anyone else? I count 65 technical interviews plus interviews with hiring managers, etc., followed by receiving offers. And all of this happening in about 8 days. This story would be a lot more believable if it had a realistic timeframe.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#17

Post by rauljara »

I was flabbergasted that someone was asked implement a linked list in Ruby. My initial reaction was 'That is an incredibly stupid thing to do.' My slightly more in depth reaction was "Isn't that what mutable arrays are for?" And my final reaction was, "Maybe I'm missing something." At which point I tried to figure out the benefits of a linked list over a ruby array. I wasn't able to come up with a good reason to use a linked list in Ruby, but maybe someone could enlighten me.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#18

Post by robobenjie »

Stwerner wrote: post #11
robobenjie wrote: post #6

Earlier quoted context omitted.

We use these types of questions to allow an applicant to show us that they can, in fact, write a simple program (see http://www.codinghorror.com/blog/2007/02/why-cant-programmer... ) and we use programming puzzles to make it more interesting for the bright candidates.

Are there any good sites out there that have a lot of these types of problems that are asked in interviews? Sites like http://spoj.pl seem to have problems that are more longer form. But it would be fun to start practicing solving the shorter ones that are asked without the hassle of interviewing to get them.

http://projecteuler.net/problems is a nice source

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#19

Post by philwelch »

Aqua_Geek wrote: post #2

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

Isn't the MVP stage a little early to hire developers?

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#20

Post by langsamer »

I think a much better indicator of how valuable a person will be in your company is not if he can solve puzzles on the fly but how munch time he puts into coding. If a person is coding in his free time and keeping up with technology and experimenting even though his current job doesn't require it, that person is more likely to have a breadth of knowledge that will pay dividends over time. Something like that cannot be gauged by him/her solving a "reverse-linked-list" problem.

Furthermore, a person involved in the community is more likely have in-roads with other strong developers, which again might pay dividends in the future in terms of hiring.

Post reply on HN