Short answer: this popped up on r/programming the other day. Lots of interesting questions there, and they don’t come with answers. This will force you to solve them yourself, without spoilers, which is an incredibly valuable exercise which I strongly recommend for any questions you ask.
Long answer: you’re going to have to unpack your intentions a little. You only have an hour (or less!), and you want to provide the maximum possible resolving power, so to do the best possible job you must know what your company’s decision criteria are for this employee, and also what kinds of evidence your fellow interviewers are going to provide. “Ask technical questions” is too broad a mandate to be really ideal, so here are some questions which might help:
Do you need to do a basic competence check? This is a concrete coding question which a minimally capable developer can solve on a whiteboard, with fully correct syntax, in five minutes or less. Fizzbuzz is the canonical example; I’ve also seen “write a function to determine whether an input string is a palindrome” used to good effect. The point of this question is to efficiently divide your candidate pool into “people who maybe ask a few clarifying questions and then write out a correct, compilable answer as quickly as they can move the whiteboard marker” and “people who fumble around for half an hour and eventually come to something that’s kinda right”. Senior candidates will sometimes balk at this, especially if they’re older than you are; I’ve found it works well to present the problem as a warmup, before you get to the more interesting stuff.
Do they have to already know the languages/tools you use? If so, then you have to drill down on that. Write down a bunch of things which you do in your env every day, pick a random subset, and ask your candidate how to do them. Java people need to know the difference between overloading and overriding, Javascript people had better be able to explain callbacks, and so forth.
How important is it that the candidate be able to solve new problems from scratch? To evaluate this, you want a problem which is novel and not easily solved with a standard algorithm. From the link above, “Add two strings. For example “”423“ + “99” = “522”” is a good example of this sort of problem, I think (or else I just don’t know the standard algorithm). For contrast, question #46 is not good for this: some candidates will have read about reader/writer locks and will immediately start reciting various algorithms and tradeoffs, while others won’t have and are stuck trying to solve what was once an open research problem in the final half hour of your interview.
What algorithms/data structures must they already have mastered? Everybody needs arrays and hash tables, most people need sets and graphs. Good is to ask people to explain them, better is to ask a question that’s easily solved using them.
Do they need to understand the hardware? Probably not, but maybe you’re developing for a console, or doing embedded work, or something.
That got really long, and I don’t have time to make it shorter. Sorry. tl;dr be mindful: know what your criteria are before you ask the questions, not afterward when you’re trying to judge the answers.
Short answer: this popped up on r/programming the other day. Lots of interesting questions there, and they don’t come with answers. This will force you to solve them yourself, without spoilers, which is an incredibly valuable exercise which I strongly recommend for any questions you ask.
Long answer: you’re going to have to unpack your intentions a little. You only have an hour (or less!), and you want to provide the maximum possible resolving power, so to do the best possible job you must know what your company’s decision criteria are for this employee, and also what kinds of evidence your fellow interviewers are going to provide. “Ask technical questions” is too broad a mandate to be really ideal, so here are some questions which might help:
Do you need to do a basic competence check? This is a concrete coding question which a minimally capable developer can solve on a whiteboard, with fully correct syntax, in five minutes or less. Fizzbuzz is the canonical example; I’ve also seen “write a function to determine whether an input string is a palindrome” used to good effect. The point of this question is to efficiently divide your candidate pool into “people who maybe ask a few clarifying questions and then write out a correct, compilable answer as quickly as they can move the whiteboard marker” and “people who fumble around for half an hour and eventually come to something that’s kinda right”. Senior candidates will sometimes balk at this, especially if they’re older than you are; I’ve found it works well to present the problem as a warmup, before you get to the more interesting stuff.
Do they have to already know the languages/tools you use? If so, then you have to drill down on that. Write down a bunch of things which you do in your env every day, pick a random subset, and ask your candidate how to do them. Java people need to know the difference between overloading and overriding, Javascript people had better be able to explain callbacks, and so forth.
How important is it that the candidate be able to solve new problems from scratch? To evaluate this, you want a problem which is novel and not easily solved with a standard algorithm. From the link above, “Add two strings. For example “”423“ + “99” = “522”” is a good example of this sort of problem, I think (or else I just don’t know the standard algorithm). For contrast, question #46 is not good for this: some candidates will have read about reader/writer locks and will immediately start reciting various algorithms and tradeoffs, while others won’t have and are stuck trying to solve what was once an open research problem in the final half hour of your interview.
What algorithms/data structures must they already have mastered? Everybody needs arrays and hash tables, most people need sets and graphs. Good is to ask people to explain them, better is to ask a question that’s easily solved using them.
Do they need to understand the hardware? Probably not, but maybe you’re developing for a console, or doing embedded work, or something.
That got really long, and I don’t have time to make it shorter. Sorry. tl;dr be mindful: know what your criteria are before you ask the questions, not afterward when you’re trying to judge the answers.