STEVE’S DO’S _ 1 Always get them to write some code, potential. You have to spend the first part of NONO even if it is small. There is a tremendous the interview putting them at ease if they TION TTION T amount of subtle signal to observe in how are nervous, otherwise you will get very someone writes code. How quick are they in little, or they will clam up. So get them to the integrated development environment talk about what they have done, ask them (IDE)? Do they touch type? Do they know some easy questions until they relax a bit. ALENT AALENT A keyboard shortcuts? Do they close their brackets as they open them? Do they have 4 SS certain rituals of laying out code using a Incorporate some open questions. Like SESSES process? Are they careful with indentation? “What happens if I type www.google.com All of these help you build a picture of the into the browser and hit enter, in as much SMENTSMENT candidate's experience and confidence. depth as you understand.” 2 5 Split the language/framework Ask them for their opinion on knowledge from general purpose problem something they mention. “Ok, I see you solving/computer science concepts. For follow TDD at your last place? What is your example, you might want evidence that the experience of that like?” candidate understands computer science concepts like recursion, indirection, trees, 6 hash tables and so on. You could test these Let them ask questions. If they don’t with an abstract problem solving question. have any questions about process/tools/ Language/framework knowledge testing is expectations that is a warning sign. more straightforward. 7 3 Always make notes on the answers to Build their confidence and get the questions, so you can justify your decision interaction to conversational level if if the need ever arises (discrimination / possible - this is particularly key with unfair claims / hiring discussion). graduates. You may have a good candidate who, because of nerves, cannot show their 7272