One thing about feedback: Too much feedback helps candidates game the system. This ultimately leads to bad hires, who end up getting fired. It hurts the process overall. When interviewing with a good interviewer, he (or she) knows that whiteboard sessions / tests / projects are just hypothetical situations. If I throw an unfamiliar API in front of you, and you ask certain wrong questions, I know you're not going to w…
> Regarding whiteboarding, if the candidate argues with me about why we're using a particular API, I pretty much reject the candidate. (No, we can't use the new threading API, I want to see how you can learn this API. No, we can't use an ORM, I want to make sure that you understand how to use a database.) YUCK. One of the first things I will do when presented with a technical scenario is start questioning the problem…
I try to hype myself up with a "thank you sir may I have another" once I get through solving what I think is a silly question.
I remember being asked to solve a linked list problem with callbacks in JS where a service returned a Node and the API call to the next node in a list.
I had to just build a function to traverse the async list - I'd have wanted to just redesign that API, but instead I had to solve their silly problem.
I got the job, and it was all due to forcing myself to have a positive attitude and being happy to solve the problems vs questioning why one would ask it.