[uptown]

I’ve never tried this exactly, but I wonder how “live coding” interviews might go if the interviewer was the one doing the typing/coding and the candidate’s role was to verbalize what the interviewer was doing (and why) - and also guide them to some degree.

It’d be more akin to pair-programming, which some of the interviews I’ve conducted have evolved into, depending on the strength of the candidates.

Would that capture enough to get a sense whether this person gets the gist of the code being written such that they could replicate the same output in a less contrived scenario?

[kevinmchugh]

My first job split the programming interview in two. 45 minutes where the candidate drive (typed) and 45 minutes where the interviewer drove while the candidate guided them. The first half disqualified a lot more candidates than the second. It was usually pretty clear how the candidate would do by the end of the first half. Occasionally a candidate would be too limited in their communication to do well while not typing.

That job had a lot of people working in pairs very frequently so it made tons of sense to do it that way there.

[em-bee]

my experience with junior programmers suggested that they are not familiar with doing this. it seemed easier to give them the keyboard and let them work on the problem how they saw fit while observing and asking them questions in order to get them talking.

there is also the problem that instructions given by the candidate may not be clear and then i have to decide whether i just assume what they meant (because i already know how to solve the problem) or if i try to take them literally leading to frustration.

[RandallBrown]

This is exactly how a company I used to work at interviewed. We did all the typing to remove that layer of stress and focus on their problem solving ability. It worked extremely well.

[fourseventy]

I actually was interviewed this way once. It worked pretty well.