Hacker News Reader

Comment by nan0 | Hacker News Reader

Agreed , but development teams already have a understanding of each and every team member's skill set. You pretty much go into whiteboard interviews without knowing the people all that well.

View on HN

If you're in a small company, possibly. In a large organisation, I fairly regularly find myself having to explain technical stuff to people I've never met before. Some are non-technical, some are very technical. Some are external suppliers, or people working in one of our many overseas divisions.

Admittedly, my job may not be typical of what the average dev has to do. But if that's the kind of role that this company was looking for, then asking someone to talk through something on a whiteboard doesn't seem too unreasonable.

I don't know the company, but I'm guessing that they aren't going to be that bothered that you can't remember the exact syntax of a particular function without checking it on Google. What I assume they're looking for is someone who can clearly communicate their thought process.

Sorry, meant to clarify that with only small focused teams that could be working a specific feature etc. Yes if the job was for a more responsible role like the one you describe, I would hope they would give the applicant a while board and more to show his/her skills.

I can disagree that for a just a technical interview that a while board isn't the best tool to bring out people's collaboration skills.

I don't know what the whiteboard should be replaced with, though.

And during the process, you find out about each other.

You can do that in a real life situation too; why a white board without a computer? Sit all in front of a computer on a beamer or whatever and jump into something in a language the interviewee says she is good at. The whiteboard can be used for the high level decisions and the total process for the soft skills.

I do a lot of interviews and that's what we do for the more technical interview:

    * give a written problem description with some reading time
    * ask some questions about the problem and the tasks,
      so we all have the same idea what is needed
    * treat the candidate as a team member in the lead role,
      support him/her
    * let him/her explore the problem and a possible solution
      design using the whiteboard
    * support him/her
    * use a computer/ide to sketch an implementation while
      he/she has Internet access and can ask any question.
      There is not a single solution we are looking for.
      Let the candidate explore his/her approach.
    * interview team sees a mirror of the screen, and the
      candidate explains what he/she is thinking/doing
    * try to get something useful running with some
      tests written. A complete solution is not needed.
      Working, tested, well written code > full solution. 
    * do a quick feedback/review round
    * if the candidate is junior, didn't get that far,
      but shows some promise, he/she gets the problem
      as homework and can send in a complete and
      tested solution within a week

We like to see: good communication skills, teamwork and excellent coding skills. We know though, that the combination of all three isn't that common.

That seems good to me. I would enjoy doing that kind of interview.

I do not understand how a "working" and "tested" code is not a "full solution."

It's not a solution of the whole problem given, that's what we would call a full solution. An extremely good coder might approach 99% of the problem, but the average coder will only get to solve one or two subproblems, which would be around 30% to 50% of the full solution. But that's fine for us. Selecting an interesting part of the problem is one of the tasks. ;-)

Reply on news.ycombinator.com