If we step back and think about software development and interviews, we might see two high-level ideas. First - the interview should probably be a lot like how

If we step back and think about software development and interviews, we might see two high-level ideas. First - the interview should probably be a lot like how work is done by the employer. The details of the requirements probably are murky, but they'll be clarified later. The deadline may or may not be arbitrary. The goals are different - you don't need a useful, profitable end product. You need a demonstration of the ability to make such a thing (within the limitations imposed by the employer.) Second - to be kind to your fellow human taking the interview, you shouldn't place them under undue stress. I enjoy David Rock's work on the brain and the chemical processes in our bodies. (I won't attempt to speak on them nearly as eloquently as the original author.) In short, there are five major things that affect our brains in a very similar way to immediate physical danger; the S.C.A.R.F. acronym, for Status, Certainty, Autonomy, Relatedness and Fairness. In an ideal workplace, and an ideal interview, you wouldn't be threatening those things more than you need to. Status is already threatened in a way - the interviewee likely desires the job to improve their status in life. But you shouldn't be forcing inferiority down their throat. Certainty - well this is almost in direct opposition to the reality of doing work in many workplaces, but it shouldn't be. In this case, what you're asking the interviewee to do and to demonstrate should be laid out in clear, understandable terms. You should try to remove some of the barriers to getting them to focus on the core abilities you need them to demonstrate. Of course, understanding communication is a valid skill to test, and you might hope to simulate your real workplace environment by being vague and using insider terminology, but you also have to remember that they have 0 days on the job in your particular place of employ. So they have yet to learn shared terminology. Knowing esoteric insider information shouldn't be tested! Autonomy - while the above means you should be giving hints as to what you want them to do, and perhaps some suggestion of methodology, they should still feel like they are in control of their choices. You're testing for an ability to reach a conclusion, and you will observe the methods used to get there, but you shouldn't remove all sense of self-direction. Relatedness - this is controversial, because we've always relied on "people like us" in interviews, only too well. You should want to connect interviewee and interviewer on some shared values and interests, but de-emphasize any focus on likeness determined by birth lottery. That is, they should feel like they can fit in, regardless of superficial differences! Fairness - this just makes me think about the potential pitfalls. Openly mentioning "better" candidates, your buddy, your niece that's applying, doing a group interview and showing favoritism. Maybe someone else can think about this one and offer up suggestions. What do you think about applying the above mental framework to how you design and conduct interviews?