What kills me with Do Work While We Stare At You interviews is my process is all over the place. I tend to draft something, try it, find my five mistakes, try more things, etc.
That doesn't fly in an interview. At least, I don't feel it does. Interviewers expect mostly right and mostly very fast. I end up standing there trying to pre-think the entire problem so something correct comes out the first time, which, to them, is just dead time with me staring at the wall.
The other option is to "dive in" and backtrack a lot, but the people watching can't tell the difference between actual incompetence and just figuring it out.
I've been interviewing a lot lately, and I'm totally fine with people trying something, changing their mind, fixing mistakes, etc. When they get stuck, I help them out. All decent interviewers know that being interviewed is stressful and that you need to cut candidates some slack.
Speaking personally, I don't care much about speed. I care about things like how much fluency do you have with your programming language (is writing a for loop something you have to struggle with?), do you know how to use a hash table (you'd be amazed at how many people don't), can you explain what the tradeoffs are when you make design choices and compare them to the alternatives, etc.
Also, since I can, I'm going to complain about my pet peeve: candidates who want to write a solution in C++ or C or java (I let them choose any language they want) but who refuse to use a container library. They'll insist on using arrays, even when the problem pretty clearly requires something like std::vector. And then they'll tie themselves in knots to make static fixed size arrays work. Now, if you can justify why you don't want to use a @#$! container library, that's fine, but usually the justifications are garbage ("it will be too slow...no, I've never measured that"). What really gets me is that a good sw engineer should be able to see that rewriting stl::vector by hand in every application intertwining its code with your application code (vector's client) is a maintenance and performance nightmare.
And here's the rub: Running an interview this way is hard to do RIGHT. The questions have to be tractable for the given time, not too oblivious that the candidate blows through them, not too domain-specific that the interviewer ends up giving a lecture to education the interviewee on the domain. Then there's the proctoring of the question.
Show of hands here: Who here has worked a companies where they used white boarding as part of their process? Did any of the following happen?
* Interviewers asked pet questions instead of using a vetted list of questions
* Interviewers never tried any of the questions in interview conditions
* Interviewers were never trained/practiced giving these sorts of interviews
* Random developers were pulled into interviews to proctor a white boarding.
Guess what? The development team is learning how to interview candidates by interviewing candidates! Not prepping a team on how to interview seems very common. Maybe candidates are expendable and ultimately are the ones that need to prove themselves.
I have to wonder how many times qualified candidates get bypassed because they didn't whiteboard just so to the interview's liking. More concerning, how many times have unqualified candidates buffalo inexperienced interviewers with hand-waves or by luck of having seen the problem before, and end up weighing down the team with incompetence.
> What kills me with Do Work While We Stare At You interviews is my process is all over the place. I tend to draft something, try it, find my five mistakes, try more things, etc.
Well yeah, that's exactly how those interviews generally go. You have to kind of narrate what you're doing, and that can be awkward at first but coming up with the optimal answer in the end is not the only goal of the interview. By all means show your work.
My process is similarly all over the place, but DWWWSAY suffers from the additional problem that 80% of my thinking power is taken up with social crap in a situation like this, so the interviewer is essentially seeing me at 20% speed. This may be why I have never gotten a job after being asked to demonstrate coding something on a whiteboard. :)
That doesn't fly in an interview. At least, I don't feel it does. Interviewers expect mostly right and mostly very fast. I end up standing there trying to pre-think the entire problem so something correct comes out the first time, which, to them, is just dead time with me staring at the wall.
The other option is to "dive in" and backtrack a lot, but the people watching can't tell the difference between actual incompetence and just figuring it out.