Making software engineering interviews predictive of job performance
In the end, it&#x27;s a crap shoot... Even their highest marker of validity is only about 50%.<p>In the end, if you make it too hard in an employee market, you will have good to great candidates drop off... if you make it too easy, you will wind up at the bottom of the barrel.  Market pay will also vary wildly and dramatically, and perception is equally varied.<p>Where I work now, we have a small pre-interview code challenge... it&#x27;s not particularly difficult and in general should be resolvable in under an hour.  I&#x27;ve seen questions on the other side, that I&#x27;ve literally spent 3+ hours on something that said an hour.  I suggest those coming up with these things actually implement their challenge on a clean computer (only tools, no reference code) and time themselves.  I now cut myself off at an hour and submit what I have stating as much.<p>As to structured interviews, it will depend.  It bugs me both ways when I see more generic, low level pattern questions in interviews only because the practical implications are usually very limited.  On the interviewer side, it does help to ask some of the more quiz-like questions as it tends to give you a decent baseline of what the person being interviewed understands.<p>In the end, personal questions along the lines of what a person works on (developers) outside of educational or work settings gives a ton of information on how they work as well as what they know.<p>Culture, for as much of a B.S. thing that it is, is actually very important as well.  A functional team or set of teams needs a few different types of personalities and worker types in order to do things well as a team.  Being able to get along together is also imperitive.<p>In the end.. it&#x27;s a crap-shoot and understanding the needs, fill and fit are all varied a bit... trying to normalize doesn&#x27;t help much.  Also, business needs and talent pools will vary greatly.