Ask HN: What is your favourite technical interview question?
I ask this question after reading this post http://news.ycombinator.com/item?id=1840774 [My Favorite Engineering Interview Question(skife.org)]
I didn't find any similar question in HN after a quick search in google, so please give your favourite interview question.
22 comments
[ 4.8 ms ] story [ 54.9 ms ] thread* Larry Wall wrote "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." Pick one of these three "virtues" and tell me about a time you exhibited it.
[1] - Some less-than-perfectly-fluent English speakers are unfairly thrown by this question, it has a lot of relatively obscure vocabulary, and then layers irony on top. BTW, even among native English speakers the single most common response is "what is hubris"?
Also, a standard although not necessarily favorite general interview question I use (technical or not) is something like:
* Suppose we brought you on board at Firm X and found that you were doing an excellent job. What kinds of things could we do to reward you?
followed by:
* No job lasts forever. What sorts of things do you think would make you want to leave Firm X eventually?
Very interesting questions the last two, I am wondering what are the answers that you get and how do you evaluate them.
Now that I think about it, this also may say something about the candidates ability to think on their feet and/or the degree to which their curiosity exceeds their reluctance to appear ignorant, since the way the question is structured it is fairly obvious you don't need know what hubris means to answer the question. You can just pick another "virtue". I'm pretty sure that's what I'd do in that scenario, but maybe I'm less candid than others in interviews.
A couple of interesting things about that first question:
* My friend who introduced me to this question said he once had a candidate pick "impatience" and then proceeded to tell the story of how and why he threw a chair through a glass window during a meeting. That guy did not get the job. There probably would have been other red flags with that candidate, but it is interesting to note how few questions would likely lead to the candidate volunteering that anecdote. Throwing a chair through a window in a business setting is very bad. Not having the sense to keep that story to yourself during a job interview is the icing on the cake.
* I'm surprised how often candidates will miss or choose to ignore the "pick one" aspect of the question and proceed to give one example for each. This doesn't necessarily strike me a positive or negative (actually, maybe a little positive), but it happens probably 60% of the time.
* For the some candidates this can be a good "employer branding" question in the sense that it suggests the hiring manager is at least a little bit clueful and appreciative of "hacker" culture. (And vice versa. Most answers to this question are acceptable, but language/culture issues aside I'm always a little troubled by candidates that don't understand how one could possibly consider those virtues. More to the point I don't see how a good developer could not recognize the importance of a little bit of laziness, impatience or hubris to their craft.)
Regrading the latter two questions:
Clearly the intent of the questions are to get a sense of what motivates the potential employee (both positively and negatively).
I didn't know it when I first started using them, but it turns out these questions are most valuable after the candidate has been hired, as they provides significant insight into how to manage and motivate the employee. It's nearly essential to understand how to motivate an employee, and this turns out to be an easy way to get at that information. You could (and I have) ask this question after the candidate is hired, but in my experience people are candid about different things before and after being hired, sometimes it's useful to plan for that.
I've come to realize that there isn't really a bad answer to this question. (Well, maybe if the candidate couldn't come up with any reward or cause for leaving, but that's never happened.)
Answers I frequently hear for the first question include "give me more money", "give me a promotion", "give me more time off" or "give me more freedom/flexibility/autonomy". There's nothing really negative about any of these answers, in fact I think each of them are pretty respectable, but more importantly they say something about what the candidate values.
At some cash-strapped places I've worked the "more money" answer was a little problematic, not for anything it says about the candidate as much as it suggests they won't be happy in the environment that we could provide them. At one firm I worked at "work/life balance" was non-existent, so "give me time off" suggested a poor culture fit.
For most environments I've worked in a good answer to the first question is something like "Once I've proven my competence I'd appreciate the opportunity to take on new or broader responsibilities, or to work on more interesting, more important or higher visibility projects." A good answer to the second question is something like "If ...
Non-technical: What are you passionate about? (This can tell you a lot about someone.)
Technical: How would you solve problem x? (Where x is an actual problem we have had to solve working on our application. Relevancy is important and cuts through the 99 common interview questions fluff).
"Define polymorphism."
Without fail, every single interviewer in my experience was looking for an answer strictly in terms of whatever language(s) they're using at the company, or whatever language the interviewer is most familiar with. If you stray outside of what they know and what they're looking for, they have no idea what you're talking about.
Polymorphism in Java is slightly different than for Ruby than for C than for Haskell than for yadda, yadda. No matter what, it's always going to be somewhat arbitrary and tied to some kind of language dependent implementation or feature. If your language doesn't even have classes, the answer is different, if your language doesn't have functions, it's different, etc, etc.
I suppose the closest thing to a right answer would be to define it in pure mathematical terms using Turing machine notation, so as to make it universal. However I have no idea if such an answer even exists. If anyone has seen such a thing, please do share it.
A better version I would ask would be: define polymorphism using x86 AT&T assembly. or: define what polymorphism represents
It the answer is not start notepad (I'll accept Notepad+), type in Hello World and save it as .htm or .html and put it on a webserver then for most of the places I have done interviewing for over the years they have missed the first requirement, get it done as easily and quickly as you can.
I fully appreciate that this varies massively by company, and I would want to know that the person can answer certain levels of technical questions but finding people who don't overcomplicate problems is hard, finding people who learnt recursion at university or as another commentator mentioned, can define polymorphism is actually not that hard.
design (with the aid of a whiteboard): how would you go about writing a call-graph explorer? start with the high level pieces and go into more detail as asked.
algorithms: "there are data structures that make tradeoffs between various operations (give examples). can you design one that has O(1) insert and O(1) extract-minimum, with everything else running in as much time as you like?"
if you're asking about my favourite question i've been asked, it was "given a set of numbers from 0 to 2^n-1, with one missing, how would you find the missing number in one pass through the set and using at most n bits of extra storage" (took me embarrassingly many tries to get it, but it was a satisfying question to solve)
You are given two eggs and a hundred story building. You need to tell me, using as few drops as possible, what the highest floor you can drop an egg from and it won't break.
I find this is a good mix of not too trivial but not overwhelming, I don't expect people to come up with the fastest possible algorithm on the spot. If they code the naive solution, that's OK if it makes sense and they can describe the performance characteristics. Then we'll talk over the algorithm and I lead them to something better and see how the conversation develops.