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

How to solve a hard programming interview question

dailycodingproblem.com

Post reply on HN
Print view View original

81–84 of 84 posts

Re: How to solve a hard programming interview question

#81

Post by virgilp »

mattm wrote: post #80
virgilp wrote: post #72

Earlier quoted context omitted.

That's why he can ask if he doesn't know what we expect. Silence is the worst option - we're there to form an impression on you (an accurate one, hopefully) - if you just sit there silently, it won't help us. (I actually ask the candidate to talk us through his thinking process if I see him sitting there; I start asking questions if he still refuses. I realize that it's an artificial setting, where many people feel p…

Please be comfortable and be yourself...but we'll have you vocalize your thought process even though this is something you never do while working, you have no experience doing and it makes it tougher to think while you're talking. If someone was a great coder but a mute, your process would weed them out.

But why do you assume such extreme inflexibility? I actually interviewed a blind person, and believe me, I didn't write/draw stuff and expect him to be able to read it.

Process is about the rule, not the exception. If you don't have killer credentials, and don't do well on the "whiteboard interview", what will happen is that we assume you might not handle pressure well/ are timid, and we'll give you a fairly consistent "homework" (e.g. "fix this Firefox bug, or at the very least analyze the root cause/ how it should be fixed. Send us a log of what you did to narrow down on the issue and on the solution"). If you don't have time to do that (which is possible)... yes, we may not hire you - but, please propose a better alternative if you have one, for I have not found it. I'd actually be very grateful if you can help me find a way to improve this process.

Re: How to solve a hard programming interview question

#82

Post by zaptheimpaler »

virgilp wrote: post #81
mattm wrote: post #80

Earlier quoted context omitted.

Please be comfortable and be yourself...but we'll have you vocalize your thought process even though this is something you never do while working, you have no experience doing and it makes it tougher to think while you're talking. If someone was a great coder but a mute, your process would weed them out.

But why do you assume such extreme inflexibility? I actually interviewed a blind person, and believe me, I didn't write/draw stuff and expect him to be able to read it. Process is about the rule, not the exception. If you don't have killer credentials, and don't do well on the "whiteboard interview", what will happen is that we assume you might not handle pressure well/ are timid, and we'll give you a fairly consiste…

There is a whole class of people you will miss - those who can solve problems, but can't vocalize effectively while solving them.

And its frustrating to be one of those people in interviews like that.

And there are plenty of solutions to evaluating a candidate. One, let them take 5-10 minutes of silence to solve if they need it, and discuss AFTER that. You say you want to see a "thinking process" or the candidate evaluating & throwing out ideas, but all of that is possible after a 5-10 minute silence period too.

Its frustrating because I suspect either that you are really just uncomfortable with silence, or have a certain idea of how people SHOULD approach the problem, and your interview process penalizes everyone who doesn't approach it that way. Its a recipe to selecting a certain type of person only and wasting everyone else's time.

Re: How to solve a hard programming interview question

#83

Post by virgilp »

zaptheimpaler wrote: post #82
virgilp wrote: post #81

Earlier quoted context omitted.

But why do you assume such extreme inflexibility? I actually interviewed a blind person, and believe me, I didn't write/draw stuff and expect him to be able to read it. Process is about the rule, not the exception. If you don't have killer credentials, and don't do well on the "whiteboard interview", what will happen is that we assume you might not handle pressure well/ are timid, and we'll give you a fairly consiste…

There is a whole class of people you will miss - those who can solve problems, but can't vocalize effectively while solving them. And its frustrating to be one of those people in interviews like that. And there are plenty of solutions to evaluating a candidate. One, let them take 5-10 minutes of silence to solve if they need it, and discuss AFTER that. You say you want to see a "thinking process" or the candidate eva…

> There is a whole class of people you will miss

I'm acutely aware that there's a degree of arbitrariness in hiring. That's why I was quite honest in saying that I'd appreciate suggestions for better process.

> One, let them take 5-10 minutes of silence to solve if they need it, and discuss AFTER that.

I do that; as you mentioned, people are diverse - some are bothered/ inhibited by silence. If they are silent, I say something like "I can leave you think about it for a few minutes in silence, but it's best if you can just talk to us about how you'd approach the problem, even about the approaches that you know are not good enough; and you can ask clarifying questions if you need to".

Thing is... if you kept silent for more than 30s without writing anything on paper, and I felt the need to intervene, it's either a problem that I consider "easy" and you should've figured out already - or it's one that is probably "hard" and you stand little chance of figuring out by yourself during the interview/under pressure (I've had a few people ask for silence, but can't remember a single one of them that found a good solution in due time). At that point, the only solution is to fall back to the "homework", because while you may be a good programmer, you're not giving me the information to assess that during the whiteboard/in-person interview.

[edit] I should also note that this is valid for algorithmic questions; and not all jobs require that sort of questions to be asked - for some, I might ask some basic stuff to figure out that you know the basic algorithms, but I won't go into hard stuff if I'm asked to hire a junior frontend dev.

Post reply on HN