4 ms·

I could've phrased that better. You're making a prediction about your ultimate hiring recommendation, not about whether they complete the problem or answer your

I could've phrased that better. You're making a prediction about your ultimate hiring recommendation, not about whether they complete the problem or answer your questions correctly or not. The point of this exercise is not to produce useful data but to draw your attention to your own decision-making. > not to come up with a BFS But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)

anonymoushn 6y ago
Sure. At some other company, I interviewed a bunch of candidates in a section that was mostly about knowing how the protocols we dealt with work and how one might build a toy version of the software we worked on. For a section like this, it's easy to help candidates too much or too little, or to let one's preconceived notions about the candidate color one's recommendation too much. I am again concerned that I may have some actual ability to predict the candidate's performance (to the extent that people's knowledge of protocols and understanding of how to write server software exists as a real thing rather than a thing that I made up) from their resume, but now I additionally worry that as far as debiasing goes, just making predictions and comparing them to outcomes will not be doing nearly enough. I would prefer not to have such a section, but I am usually not in charge of these things. > But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;) I did not say that the interview process at that company was my favorite or was the same as the one in the OP. That said, my experience as a candidate at FAANG and smaller-but-not-super-small companies has generally been that I must at a minimum solve the problem, and that sometimes I must also solve it exactly the way some rubric says it is to be solved, so that providing an unusual approach that uses half the space and just as much time as the best approach the department has heard of also causes one to fail.

anonymoushn 6y ago

Sure. At some other company, I interviewed a bunch of candidates in a section that was mostly about knowing how the protocols we dealt with work and how one might build a toy version of the software we worked on. For a section like this, it's easy to help candidates too much or too little, or to let one's preconceived notions about the candidate color one's recommendation too much. I am again concerned that I may have some actual ability to predict the candidate's performance (to the extent that people's knowledge of protocols and understanding of how to write server software exists as a real thing rather than a thing that I made up) from their resume, but now I additionally worry that as far as debiasing goes, just making predictions and comparing them to outcomes will not be doing nearly enough. I would prefer not to have such a section, but I am usually not in charge of these things. > But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;) I did not say that the interview process at that company was my favorite or was the same as the one in the OP. That said, my experience as a candidate at FAANG and smaller-but-not-super-small companies has generally been that I must at a minimum solve the problem, and that sometimes I must also solve it exactly the way some rubric says it is to be solved, so that providing an unusual approach that uses half the space and just as much time as the best approach the department has heard of also causes one to fail.