| An approach that I've seen work reasonably well: Spend a bit of time just talking to them. Work background, but also just finding out who they are as a person. Give them some code to read - one page. It should compile - don't ask them to be a compiler. It shouldn't depend on obscure library calls, though it can use well-known ones. The question you're asking them is, what does it do? Then, give them some code to write. Not a leetcode problem, but something one level above FizzBuzz. Yeah, this is probably at a whiteboard, but it could be at a keyboard in an IDE if they want. They can use any language they want. You want them to think out loud while they're doing it. Can they figure out the steps to implement a solution? Can they write code that isn't too badly broken? Again, you aren't asking them to be a compiler - if they miss a semicolon, that's not a failure. Then, you ask them to do a bit of design. Just draw some boxes for how they would break up some problem. You're not looking for perfect UML here. Can they design a subsystem, or not? Then, you ask them if they have any questions for you. That's it. Two hours max. You might give them a half-hour phone screen before you schedule them for the interview. |