This is a great topic.<p>I like to split my interview to the following steps:<p>- introduction, small talk about the company or the candidate
- level 1
write a function that flips a bit that is represented as a single digit integer: (0 -> 1, 1 -> 0)
flip two variables (int) without a third one: (a,b -> b,a)<p>- level 2
what is the runtime complexity of a nested loop (assuming n == m)
lease write a function that returns the list of numbers (in a string representation) that are permutation of N digits, where digits are 0..9.
(1 -> 0..9, 2 -> 00 01....98 99 etc.)
please explain recursion<p>- level 3 99% of the candidates do not make it to here
I guess I should just make them flip that binary tree over the phone. :)<p>This is basics I think, so most of the software engineers should be able to solve these, even with a little hint.<p>On the top of these artificial tasks I usually ask them what is the biggest system they contributed code to, what was the contribution. What tools are they using. What is the favorite language and why. How do you to performance profiling for your code. What was the last problem that you solved in production, what was the problem and what is the solution.<p>And few others.
I like to give some broken code and ask them to fix it...or give a Class that's missing a function or two and ask them to fill in what seems to be missing.<p>I tend to like those types of problems more than the "blank page" kind...I've found it to be a closer approximation of the everyday tasks they'll be encountering on the job.
I like to describe a problem that we are currently experiencing or one that we had in the past to see the troubleshooting logic in play. I love explaining something that is not quite optimal in production and see if this person could help.