[ivanche]

I think an obvious reason for this type of interview problems is because developers at work usually talk loudly while solving problems and write code without the help of any external resource while the clock is ticking in the background. Oh, wait...

[lordCarbonFiber]

What both you and the parent post you're deriding are missing is white-boarding (when done correctly) isn't about the problem at all. It's just an easy way to get a candidate in the room and construct a technical conversation.

As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.

Do your recruiting right and you shouldn't need the white board to simulate whether the candidate can code at all (I think white-boarding with the intent of looking for named algorithms is a waste of everyone's time), instead you want to see if they can synthesize information, engage with other people, and otherwise display the soft skills that tend to be much more useful metrics for employee success than coding aptitude.

Granted, my industry is known for not having deep coding problems to solve, this strategy might not be as useful in verticals that require more technology chops.

[krisdol]

>As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.

The post you're responding to makes a great point that this isn't the normal working environment for 99% of actually-writing-code developers. I discuss and iterate designs with my coworkers/leads/managers/architects just fine, but a surprise algorithmic problem you have to simultaneously solve, draw on a whiteboard, and constantly present to an audience while being timed isn't something I have been great at. I bet many others aren't either. I got good at it after a few interviews last time I was looking for a job; but if I hit the interview trail again today, I'm confident that I would flounder in that setting for a while.

Imagine if, instead, the candidate worked out a project -- maybe at home, or maybe in an interview room for some time -- then you take time to review and understand their work and then go through this back-and-forth process of discussing their work. This would also benefit the candidate's understanding of how you collaborate to problem solve in your work environment.

The problem with this approach is that it requires the interviewer to actually invest time to understand the candidate's work.

Anyway, I hope you see why many see it as a problem that the process for a candidate to succeed at a job interview is to practice interviewing skills rather than demonstrating their engineer skills.

[clarry]

> As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful.

As an investor, I don't care how great your skills are, if you can't come up with your new business idea on the spot and walk me through your thought process as you're doing it, you probably suck.. right?

Nah.

Unless you already have the answer, the first step is to come up with the solution. This could involve time spent alone just thinking, or brainstorming with coworkers, or researching the problem on the net, etcetra. What the right steps are depend on the problem, available resources, your background, even your preferred way of working.

The second step is to present and dissect the solution. I dare say this is the point at which the majority of engineers have no problem whatsoever talking about their thought process.

Do you work in an industry where engineers genuinely have to walk somebody through their thought process while they're trying to think up a solution?

If a problem comes up at a meeting and you don't have a solution on the spot, you take note and discuss it later or add it on the agenda for the next meeting. I think that's how people work.

I don't care about where, when, and how you came up with the idea. I care that you can present and discuss it once it's ready for that.

I think this is why many prefer the take-home test. They can focus on the solution. Then, at the interview, they can focus on the talk about the solution. It's also a great equalizer as e.g. people coming to work in a domain they have less experience with can take more time to research the solution space.

The complaints about homework taking up too much time may be valid, but I'd be most happy to trade 2 hours of interviews for about 75 minutes of homework and 45 minutes of interview.

[ivanche]

"When done correctly" is the key here. Alas, in my experience I was usually heavily penalized if I kept my mouth shut for as little as 15-20 seconds because interviewer "couldn't see my thought process". At the same time expecting from me to write syntactically and semantically correct, industrial strength bug-free code with optimum space and time performance for a problem I never ever encountered with the interviewer "helpfully" distracting me 4-5 times a minute.