4 ms·

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

tluyben2 10y ago
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.
- lispm 10y ago
  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.
  - tluyben2 10y ago
    That seems good to me. I would enjoy doing that kind of interview.
  - jonathankoren 10y ago
    I do not understand how a "working" and "tested" code is not a "full solution."
    - lispm 10y ago
      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. ;-)

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.

lispm 10y ago
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.
- tluyben2 10y ago
  That seems good to me. I would enjoy doing that kind of interview.
- jonathankoren 10y ago
  I do not understand how a "working" and "tested" code is not a "full solution."
  - lispm 10y ago
    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. ;-)