2 ms·

As an interviewer I wholeheartedly agree with this. I think most egregious problems are: 1) candidates assuming that I am only interested in them producing a

As an interviewer I wholeheartedly agree with this. I think most egregious problems are: 1) candidates assuming that I am only interested in them producing a solution 2) candidates assuming that I am interested in checking their knowledge of the language or standard library In fact, the process is mostly what I am interested in and I am pretty happy to give hints and especially when it comes to trivia like what is the name of the function that does some specific thing and what kind of parameters it takes. I just would like to see how the candidate approaches and deals with the problem. Does he/she have analytical, planned, ordered approach or is everything chaos? High on my list of things that don't impress me is solving the problem by running the code dozens of times. This shows the person cannot write any stretch of the code without running it because he/she does not actually have a mental model of what is going on and relies on actually running the code as a crutch for their lack of understanding.

kioleanu 6y ago
If I understand correctly what the guy says in the article, his candidates lose points if he gives them hints. And about running the code often, what's the problem with getting early feedback? There are people (that I agree with) that run the unit test on the code they're writing every added line or two. Some who also commit every line or two and then squash the commits once the whole "unit" is done. By no means does this mean they don't know what's going on
- lmilcin 6y ago
  There is no single right way to conduct an interview. Each interviewer has his own style and I think it is fine. I think giving the candidate a hint has a purpose and that is to keep the process of finding a solution progressing. Otherwise the candidate may get stuck and as an interviewer this is bad because we are now wasting time to let me know the candidate. At the very beginning I tell the candidate some of the things that I feel are fine or not fine. For example, I will tell the candidate that I am happy to give out names of functions and lists of parameters as long as the candidate can describe exactly what the function is doing. So I give these for free because in normal work I would expect he/she can find it in couple of seconds on the internet, anyway, and that's also how I do this. What I don't give for free (ie. mentally deduct points for) is give larger hints that would normally be thought as part of the solution. Likewise, when I start technical question section I tell candidates that "I give 5 points for not answering the question". Most people are quick enough to figure out this means I penalize bad answers and would prefer the candidate to say they don't know something rather than keep talking nonsense.
rimliu 6y ago
3) Interviewer assumes he has skills to evaluate candidates's approach.
- lmilcin 6y ago
  The post is about candidates' failings, presumably to help them. The failings of interviewers are whole other, not less interesting, story. As to your point, it is completely misplaced in that list which is list of problems with my candidates. When I interview candidates I am expected to do my job which is to treat the candidate humanely and give back quality, actionable feedback. Why wouldn't I be able to evaluate candidate's approach? Can he solve the problem? If his approach is so good I can't understand it why then he wasn't able to solve the problem? Why would that happen on a problem I chose? When I put up a problem for my candidate I have already solved it in every imaginable way so I know ins and outs of every possible solution. I do that so that I can stop focusing on the approach and focus on the candidate because that is ultimately my task. I can imagine the candidate providing another solution but why wouldn't I be able to even evaluate the solution if I have spent so much effort on relatively simple problem already? It is also important to understand, that the job of the interviewer is not to approve every good candidate. The job is to prevent bad candidates from getting hired. It is expected that some good candidates will be lost in the process and it is acceptable, because hiring a bad candidate is much, much worse than loosing a good one. If you loose a good candidate you have a queue of other candidates so the worst that will happen is you will spend a little bit more on acquisition and maybe make a little suboptimal decision. If you hire bad candidate you are tied to him/her for a long time and usually have to expend huge amount of resources before the candidate is finally let go or maybe while he/she stays indefinitely, blocking your ability to find better candidate.

kioleanu 6y ago

If I understand correctly what the guy says in the article, his candidates lose points if he gives them hints. And about running the code often, what's the problem with getting early feedback? There are people (that I agree with) that run the unit test on the code they're writing every added line or two. Some who also commit every line or two and then squash the commits once the whole "unit" is done. By no means does this mean they don't know what's going on

lmilcin 6y ago
There is no single right way to conduct an interview. Each interviewer has his own style and I think it is fine. I think giving the candidate a hint has a purpose and that is to keep the process of finding a solution progressing. Otherwise the candidate may get stuck and as an interviewer this is bad because we are now wasting time to let me know the candidate. At the very beginning I tell the candidate some of the things that I feel are fine or not fine. For example, I will tell the candidate that I am happy to give out names of functions and lists of parameters as long as the candidate can describe exactly what the function is doing. So I give these for free because in normal work I would expect he/she can find it in couple of seconds on the internet, anyway, and that's also how I do this. What I don't give for free (ie. mentally deduct points for) is give larger hints that would normally be thought as part of the solution. Likewise, when I start technical question section I tell candidates that "I give 5 points for not answering the question". Most people are quick enough to figure out this means I penalize bad answers and would prefer the candidate to say they don't know something rather than keep talking nonsense.

rimliu 6y ago

3) Interviewer assumes he has skills to evaluate candidates's approach.

lmilcin 6y ago
The post is about candidates' failings, presumably to help them. The failings of interviewers are whole other, not less interesting, story. As to your point, it is completely misplaced in that list which is list of problems with my candidates. When I interview candidates I am expected to do my job which is to treat the candidate humanely and give back quality, actionable feedback. Why wouldn't I be able to evaluate candidate's approach? Can he solve the problem? If his approach is so good I can't understand it why then he wasn't able to solve the problem? Why would that happen on a problem I chose? When I put up a problem for my candidate I have already solved it in every imaginable way so I know ins and outs of every possible solution. I do that so that I can stop focusing on the approach and focus on the candidate because that is ultimately my task. I can imagine the candidate providing another solution but why wouldn't I be able to even evaluate the solution if I have spent so much effort on relatively simple problem already? It is also important to understand, that the job of the interviewer is not to approve every good candidate. The job is to prevent bad candidates from getting hired. It is expected that some good candidates will be lost in the process and it is acceptable, because hiring a bad candidate is much, much worse than loosing a good one. If you loose a good candidate you have a queue of other candidates so the worst that will happen is you will spend a little bit more on acquisition and maybe make a little suboptimal decision. If you hire bad candidate you are tied to him/her for a long time and usually have to expend huge amount of resources before the candidate is finally let go or maybe while he/she stays indefinitely, blocking your ability to find better candidate.