5 ms·
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
by 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 agoThat seems good to me. I would enjoy doing that kind of interview.
- jonathankoren 10y agoI do not understand how a "working" and "tested" code is not a "full solution."
- lispm 10y agoIt'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. ;-)