Comment by time_is_scary | Hacker News Reader

Comment by time_is_scary | Hacker News Reader

> Google’s recruiting process is well documented online, and from this point my experience was pretty typical.The only difference is that I didn’t need to go through a technical phone screen since I had already demonstrated some proficiency with coding through the foo.bar exercises.

> For my interview, I spent a day at Google headquarters in Mountain View solving problems on a white board.

So what's the point? A phone screen takes what, 30 minutes? This is a lot of time to put in only to have to do it all again on a whiteboard.

I guess it would be better than a phone screen for Google, but this seems like just another hoop for candidates to jump through.

One of my gripes with the tech industry is that companies keep adding more onto the funnel part of the hiring process, but once you get the interview none of it matters. You can contribute to open source, have substantial github projects, complete coding challenges, have years of experience: all of this just helps you get the interview. Once you are in the companies hiring pipeline everyone is put through the same process, none of the other stuff really matters after that point.

Maybe I'm just bitter that my team just hired one candidate over another because they did better in the whiteboard interviews (but had no side projects or real code to show us) while the other person had a lot of (good) code and pretty creative projects to look at.

What is absolutely baffling to me is that companies assign coding tests as a pre-qualifier for the usual whiteboard interview despite the coding test being a far more adequate measure of the abilities of an engineer. I've had interviewers tell me that my coding samples went above and beyond what they usually receive (exhaustive docstrings, tests that make sense) and yet rather than discuss, say, how my code worked or why I chose one algorithm over another, they insist on making me solve puzzles on the whiteboard as the ultimate decider.

The ideal hiring process for me would be introductory culture fit phone call, in which working hours, benefits, vacation policy etc are discussed to see if there is a lifestyle fit between prospective hire and employee (not 'Do you rock climb and crush brews?' culture BS), then a coding challenge, and then an in-person discussion of your code. The in-person discussion could involve throwing new requirements and hypotheticals at the problem to see how the candidate thinks on their feet, but it would still be relevant to the work they did at hand rather than some arbitrary puzzle pulled from Cracking the Coding Interview.

I would be interested to know how the hoop-jumping-to-whiteboard process came to be standard. To me it does not make any sense why the determining factor for receiving an offer for a software engineering job should be dependent on one's improvisational problem solving abilities over actually writing code that runs and satisfies requirements. Is it because a whiteboard interview is much more cut and dry than code evaluation? Because every software company wants to think that they are Google?

> What is absolutely baffling to me is that companies assign coding tests as a pre-qualifier for the usual whiteboard interview despite the coding test being a far more adequate measure of the abilities of an engineer.

A coding test doesn't tell you how well a candidate can collaborate. Can you toss them an idea, and have them successfully expand it and put it to use? Can you give them a couple of half ideas, and they expand them to full ideas? Would they be able to work together with you? Can they understand you? Can you uderstand them?

Those are all vital components to success, and you can't see those answers from a test. But white boarding is excellent for answering all those questions.

A quick word about hoop jumping. Being willing to jump through hoops means you're willing to cooperate and go the extra mile, and that you want to work at the company in question. This is a useful filter for the employer. They might lose some of the least patient and dedicated engineers (and perhaps some of the most talented) developers in the process.

> A coding test doesn't tell you how well a candidate can collaborate.

Agreed.

> But white boarding is excellent for answering all those questions.

I disagree. There is no team social dynamic in a white-board interview. There is one person in a position of power who is judging you with a critical eye. The other person is being judged and either really wants this job or, worse, needs the job.

That is the social dynamic in the room.

That doesn't go away by saying "Let's play pretend like we are working on a project as equals".

Interviewers will often discuss their rationale as if the candidates know what it is, or that they should be able to know it.

For instance, "I want to see if they can take suggestions and run with it".

Great, how does the candidate know that's what you want? Maybe the last interview they were in wanted to see if they could take bad advice and quickly explain why that strategy wouldn't work.

Those both look the same from a candidate's point of view. They need to toss the dice and assume they interpret your intentions clearly.

> Being willing to jump through hoops means you're willing to cooperate and go the extra mile

I don't know if I fully agree, but working at a big company does involve a lot of hoop jumping in your day-to-day, so I guess it is something good to test for.

> I disagree. There is no team social dynamic in a white-board interview. There is one person in a position of power who is judging you with a critical eye. The other person is being judged and either really wants this job or, worse, needs the job.

Well, it could be like that, and that's the popular conception, but it doesn't need to be like that. If it was handled more like a small meeting with them all contributing (but the interviewers possibly holding back some as needed to allow the interviewee to contribute), you could probably get a fairly good idea of how quickly they grasp concepts from other, how familiar they are with what they are trying to to, and how well they collaborate.

> They need to toss the dice and assume they interpret your intentions clearly.

Actually, that's testing collaboration right there. If the question is vague, ask if they mean this, or that. Tossing the dice and assuming is exactly the opposite of collaboration.

It's possible the interviewer is just a prick, but it's also possible they want to see how you work and collaborate.

> A coding test doesn't tell you how well a candidate can collaborate.

My solution for this is a pair programming interview:

http://www.quora.com/What-are-the-best-programming-interview...

Like a whiteboard I'm there for everything that happens and can judge collaborative ability. And like a coding test, I'm seeing what people really do.

I may also do some whiteboard work, as being able to talk over an idea is also part of the job. But that's not in the "please do something arbitrary that you will never have to do in real life" vein. I try to make the whiteboard work as much like real work as possible.

The part that is weird for me is that you are aggravated from a candidate perspective, I am aggravated from a hiring perspective, but nothing will change.

I think it became standard because it scales, at least in some sense. Once big companies started doing it (because of scaling issues) small companies started doing it (because of "hey, it works for Google" issues). If I was in a small company, I am sure I would have a little more freedom in how I hire, but I am not.

I think I am actually okay with the white-board puzzle quizzes if you have nothing else to go on. For instance, a college graduate who only has course projects. However, we use them for everyone.

Maybe once you get to X years of experience (maybe 10?) the white-board interviews become easy, you're used to them.

> You can contribute to open source, have substantial github projects, complete coding challenges, have years of experience: all of this just helps you get the interview. Once you are in the companies hiring pipeline everyone is put through the same process, none of the other stuff really matters after that point.

This reminds me of "90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off." - https://news.ycombinator.com/item?id=9695102

I remember seeing that tweet, but didn't know it was posted here.

Pretty interesting discussion both for and against this type of hiring process.

Reply on news.ycombinator.com