|
|
|
|
|
|
by liegroup
3291 days ago
|
|
|
It took me 30 minutes because I'm out of interviewing practice mode, and I was pair-programming with a backend/infrastructure dev :). When I tried it alone, I did it in about 7 minutes. Would you agree that 15 minutes is enough to get a sense of the candidate's approach, and be able to tell whether or not they'd be able to solve it given 45 minutes? |
|
|
My approach to interviewees is no panacea but I try to start low and build up in complexity from there by playing on their strength and finding where that brings the both of you (hopefully to their upper limit). It means a bit of preparation before hands based on their resume or a prior phone interview.
Some interviewees just slice through whatever you give them and others are in an uphill battle. To somehow answer you question about being able to infer if a candidate can solve a problem in a given amount of time, I believe the only way to know is to give them that time. A bit of help here and there can help move on to a different question and I've yet to see someone properly 'fake' understanding code (ie. they say they understand but not really).
I also believe that it's only by knowing what candidates are able to do and what their current limits are that I can make a good hiring decision. This is very hard to do and I often get it wrong. Comparatively, it's easy to find what a candidate can't do but it does not help you much deciding who to hire.
If a candidate fails all questions, either the questions are inadequate/wrong or they are a fraud.