29 ms·

How I ended up conducting successful tech interviews with just 1 question

261 points by bubblicious 12y ago

cportela 12y ago
I'm fairly certain I can't pass this test even though I've tried. Just haven't had the skills yet for what I want to make and the stuff I've made doesn't impress the people I want to be with.
insaneirish 12y ago
I can't take seriously someone who doesn't capitalize letters appropriately.
- sho_hn 12y ago
  Most alphabets don't have letter case. Its utility particular in written English is questionable at best. I'm not saying you should stop capitalizing, mind you -- there's value in standardized orthography. But it's a good idea to set your horizon beyond it. I've noticed that I've become much more flexible and less dogmatic about things like this since looking at a bunch of other languages and writing systems and recognizing written communication as spectrum.
  - heurist 12y ago
    I learned the other day that before the printing press all characters were 'upper case' but were squashed down to be able to write quickly and use less space. Printing press creators copied what they saw in written text by creating small characters alongside the normal large characters and case rules developed out of that. You can play around with squashing handwritten uppercase characters (write them fast and small) and see why lowercase characters look the way they do.
  - nawitus 12y ago
    >Most alphabets don't have letter case. But the latin alphabet is apparently the most common alphabet. I don't really see your argument here.
    - sho_hn 12y ago
      My argument is one in favor of being more flexible than the OP proposes, by introducing the idea that letter case isn't a universal or even frequent trait of similar writing systems, and that you can even call into question its utility. As for modern Latin (Latin originally didn't have letter case, either; widespread use of letter case is a fairly recent development), most common doesn't mean best - how the "market share" of languages and writing systems evolves is a more complex topic (Nicholas Ostler's Empires of the Word: A Language History of the World is a good book). That means looking at and comparing with other examples is often useful. It's a little like the reason you want to learn more than one programming language - it trains your ability to think about problems on a more abstract level than a single toolbox allows, and gives you insight into the strengths and weaknesses of each of your tools and how to apply them best. Even if you wind up only programming in a single language anyway. It also tends to make you less dogmatic and more willing to go back to first princples. Or willing to entertain notions like "just because this man isn't capitalizing his letters it doesn't necessarily mean he has nothing to tell me".
      - walterbell 12y ago
        Agreed. One could argue that modern "design thinking" involves the creation and extension of non-alphabetic, visual language. Someone unfamiliar with modern logos (e.g. share icons) and UI conventions (e.g. "hamburger" icon) may view these symbols like they would view Egyptian hieroglyphics. 2nd-order cybernetics is about observing the observer, which includes observing the limitations of communication. Studying different languages helps identify the limitations of each, i.e the untranslateables. There's a great book on this topic (we need an equivalent for software), a 1300 page "Dictionary of Untranslateables". http://www.washingtonpost.com/posteverything/wp/2014/07/16/how-to-translate-an-untranslateable-book/ http://www.washingtonpost.com/posteverything/wp/2014/07/16/h... "This depends on what one means by “untranslatable.” Cassin and her team believe that an “untranslatable” word is not one that cannot be translated, but rather a word we can’t stop trying to translate, aware always that we haven’t quite hit it, that it isn’t right."
        sho_hn 12y ago
  - insaneirish 12y ago
    He or she is writing in English. English has rules. Some rules are made to be broken. Capitalization is not one of them when it comes to writing coherent prose.
    - sho_hn 12y ago
      I disagree. I think the bar is "does this text accurately convey the intended meaning and is comfortable to read?", and I think it's interesting and worth thinking about that written English largely still meets that bar when you remove capitalization. Capizalization mostly doesn't encode significant additional information (yes, there are counter-examples - the article we're talking about actually does capitalize acronyms) or enhances ergonomics all that much. This is really more a social thing and about what the choice not to use capitalization communicates, i.e. you may be reacting negatively because you read it as a "I do not care to conform" or "I do not care about your appraisal of my writing" marker. Which is understandable, but I wonder if that isn't a too-quick judgement to serve as a rule.
      - xux 12y ago
        Nah DuDE if I wrItE liKE thIS DO u AUdoMAticalYLY geT annoyINgED? Yes. So why the heck is not capitalizing your sentences ok? Language is a tool to communicate with the masses. We have rules and standards so everyone can understand them. If you can't do that effectively, then you have failed in your communication.
        sho_hn 12y ago
        > So why the heck is not capitalizing your sentences ok? The two examples aren't the same, and the reasons a reader experiences discomfort reading your example text are different. They're about ergonomics. The erratic variations in letter footprints and the up-and-down-and-up from the ascender line to the x-height and back affect reading speed. It's also spurious; the capitalization style in your example doesn't add additional information. Try giving some thought to capitalization along those lines. Does capitalization add information that otherwise isn't explicit? How does it affect reading speed? The anwers are roughly "yes, sometimes" and "yes, sometimes" (the latter depends a lot on how you define "reading speed/performance"; "reading" decomposes into a set of different types of interacting with text, like searching, information/keyword retention, etc). You can call this a good case for capitalization, but I'm not convinced it's a given, and competing writing systems do get by well without it. > We have rules and standards so everyone can understand them. Sorta. "Understand" is a big topic to broach, see above. It's of course true that shared language and shared orthography enable sophisticated communication and grease its wheels. And in that light, not conforming may suggest an exclusionary attitude (just like e.g. excessive use of jargon can be motivated by tribalism). But it's not where I'd personally draw the line; I'd read a text rather than dismiss it beforehand based solely on a lack of capital letters. > If you can't do that effectively, then you have failed in your communication. The many other comments discussing the actual information content of the text seem to suggest that it hasn't.
- archagon 12y ago
  I think it lends a sense of humility to the writing.
  - sliverstorm 12y ago
    To me it just lends a sense of laziness.
- ldng 12y ago
  It's some French hipster fad. My ex-boss did it too. It can b annoying at times but once you get accustom, it's bearable. I don't even notice now.
  - deleted 12y ago
    [deleted]
- ianstallings 12y ago
  It doesn't help that it's pretty long-winded to just make a simple point, taking it from just annoying to painful. I think I could fit the point into a tweet to be honest - 'What was your most interesting project?' is the best interview question. And the fact that we're discussing it here in this thread makes your point stand - it detracts from the message trying to be conveyed.
asuffield 12y ago
The flaw in this method is that it assumes there is only one kind of developer: the lone architect, who builds fine tents out of whatever is lying on the ground and then departs. What it won't get you is breadth of experience, operational background, full-stack thinking, or people who can look at somebody else's work and say "here are the ways in which that is going to blow up in your face, two years from now". (Anybody care to add to this list?) If all you ever do is bootstrap new projects from nothing then maybe that's the sort of people you want to hire, but it's probably not enough to build a sustainable product.
- Spearchucker 12y ago
  It doesn't assume that at all. You as the interviewer get to listen. You can ask probing questions to get the insight you need, or to steer the conversation. It's a great question, because it relaxes the interviewee as she gets to talk about something she knows well, probably enjoyed, and - if she's as good as you hope - has good depth and breadth of knowledge about.
- howeyc 12y ago
  I admit I just skimmed the article, but I don't see a requirement that the project you choose to talk about be a solo effort. I think the point of the question is to find people who are passionate about their profession (in this case programming).
- iamben 12y ago
  I'm not sure I agree - from reading the article, I got that the author found people who were excited and passionate about what they did, people who were excited to code. It may have been the lonewolf project that lit them up, it may have been the massive team effort where they found a novel way to help an entire team. But it was someone who really believed in something, rather than someone who was simply working for the weekend.
- Goladus 12y ago
  I don't think that question precludes all of those things. Anyone who is a "full-stack thinker" with broad experience should have at least one project in their past where they created something they're proud of.
reality_czech 12y ago
Everyone knows that the only question you need to ask is "how is this an issue?" http://27bslash6.com/interviews.html http://27bslash6.com/interviews.html
Goladus 12y ago
tl;dr: The question he arrived at is: “... will you please tell me about the best project that you’ve ever created?” Then watch for enthusiasm and pay attention to the details. The goal seems to be to identify someone who really enjoyed and takes pride in a program they've written.
- wildpeaks 12y ago
  The "project you're the most proud of" might be a more precise way to phrase it because "best project" could mean either: - created the most value for your employer even if it was a soul-sucking nightmare / merely maintenance project with no challenges. - you learnt the most from it / overcame challenges you didn't know you could / came up with moonshot solutions to issues no one even realized were there.
  - spoondan 12y ago
    People can be proud of either of those accomplishments as well. Honestly, I doubt "most proud" versus "best" makes a difference at all. Candidates generally explain their answers to these open ended questions. If they (for some reason) don't recognize the implicit, "And why?" part of the question, you just follow up with it. The conversation will never be just, "Foobaz, next question." One way or the other, it will be, "Foobaz because..." It saved the company $2M/year. Or users really loved it. Or it improved the engineering process and made releases faster and lower risk. Or it was a really tough problem that required a lot of creative thinking. Or it taught me a lot about 3D game programming.
warcher 12y ago
It's always surprising how often interviewers fall back on "API Jeopardy" when trying to make hiring decisions. Maybe it's just because my career hasn't really allowed the luxury of getting deep on any technical stack and staying there, but I just don't keep the details of obscure function calls in my head all the time. And I have to wonder at the utility of testing a developer on having memorized the kinds of things that they will always, ALWAYS be able to look up when they're actually working.
coldcode 12y ago
Thank you, finally someone who gets the idea. Though I like to ask two questions, one the best project you ever worked on, one the worst project you ever worked on. You can learn a lot about a programmer by the details they relate in both cases.
- chippy 12y ago
  ooh, that is a good one! I wonder if some people would mention the same project?
danmaz74 12y ago
The "tell me about your best project" question is great, but I always combined it with one apparently simple programming question, like giving the quadrant from the (x,y) coordinates. Maybe the OP is able to understand how logic-minded his candidates were just from talking, but many times I was disappointed from the actual ability to write down some code (even discounting the stress of the situation).
ruswick 12y ago
The problem is that this method disproportionately hurts people who don't have the time or energy to effectively hold two jobs (one full-time position at their day job and one as an independent developer or open-source contributor by night) because of family, friends, or some other facet of life beyond their laptop. I think it's totally unreasonable to expect that everyone spend every minute of their lives coding or to have some kind of deep, personal connection to the code they write. This thinking is ridiculous, and doesn't really appear in any other industry. Do you care whether your accountant's idea of an enjoyable Friday night is sitting at home making more spreadsheets? Would you demand that your eye doctor go home and craft her own lenses in her garage for fun? Competency doesn't require fanaticism, and no employer should expect that their employees devote their entire lives to their occupation. If I want to code for 8 or 10 hours a day, go home and enjoy myself in the little free time I do have, then wake up and do it again, I don't see why that makes me an inferior employee. This just seems like more misguided, unjustified cultural absolutism that is so prevalent in the industry. EDIT: For those saying that the article doesn't necessitate spending massive time outside of work writing code, the author clearly conflates the two. "i have always been convinced that those who love code do not restrict their coding activities to their work. they take home that love and continue to create for fun as a hobby." Personally, I think passion could be a valuable heuristic in hiring, but the author seemed to imply that passion is only measured by your willingness to work outside of your day job. At the very least, that seems to be his expectation of good candidates, and his hiring process clearly disadvantages people who can't or won't code 24/7.
- eps 12y ago
  Accountants don't create something out of nothing. It's an inherently supporting activity. Also, the question doesn't imply in any way that it has to be an off-work project. Its only point is to see if a person actually cared for any code they wrote in the past or if they treated coding just as means to an end.
  - nawitus 12y ago
    The question in the article was 'will you please tell me about the best project that you’ve ever create', which excludes most work projects, since work projects are typically not single-developers projects.
kika 12y ago
That's almost exactly what I was doing for years. Two differences: 1. I sometimes ask 1-2 technical questions, for example if the candidate claims exceptional knowledge of some important (for us) technology, but his/her resume doesn't show extensive use of it. Like: "You say you know CouchDB inside out, but you've used it only once and not for long, interesting.... Can you tell me how the _changes feed works - if I listen on this feed do I get just the changed documents IDs or whole documents?" 2. Instead of "what's your best project" I ask more aggressive question - "imagine I give you 1 million dollars right now and in return I want to be a part of what you use it for - a share of profits, credits in the movie, etc. What would you do?". Edit: ah, the almost mandatory third question: why do you want to leave the job you're currently having?
cottonseed 12y ago
The best advice I've seen on how to structure an interview came from Nick Corcodilos of Ask the Headhunter [1] fame, from his book Reinventing the Interview to Win the Job [2]. If you want to show someone you can do the job (or see if they can do the job), do the job, or as close as you can get to it in an interview setting. Anything will be selecting for indicators that will be more or less correlated with job performance. [1] http://www.asktheheadhunter.com/articles.htm http://www.asktheheadhunter.com/articles.htm [2] http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0452278015&linkCode=as2&tag=wwwonebadseec-20&linkId=OBQZTIGOSOWYFUSZ http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=...
- cottonseed 12y ago
  Coincidentally, the most recent Ask the Headhunter article [1] is "The Single Best Interview Question... And The Best Answer". Hint: It isn't about your hobby project. [1] http://www.asktheheadhunter.com/habestinterviewquestion.htm http://www.asktheheadhunter.com/habestinterviewquestion.htm
  - lifeisstillgood 12y ago
    Absolutely love that ! Weirdly it reminds me of ramit sethi briefcase "technique" which is roughly research the prospect, come up with some proposal that shows you can as value and pull it out of your briefcase at the opportune time.
  - djur 12y ago
    This is specifically about technical interviews as one of several steps, though. "What is your plan for being effective in this job" is the kind of question that, in the OP's three-step interview, should be asked by the manager. My current employer has candidates do a brief presentation about a project they are proud of. It's useful but imperfect (some people just aren't good at speaking to a group, which is okay for this job; some people aren't legally permitted to go into a lot of detail about their earlier projects).
xur17 12y ago
From an interviewee's perspective, these are my favorite interviews too. I get to talk about something that interests me, and have a discussion about the different decisions I made. If the interviewer wants, they can dig into specific details, or ask more pointed questions about the programming language. I find trivia questions off-putting, and tend to limit the depth of discussion into my skills. And to the people saying that this necessitates projects outside of work - I don't see why it does. You can talk about school projects, projects from previous jobs, etc.
recalibrator 12y ago
TL;DR Please tell me about the best project that you’ve ever created
Tomis02 12y ago
Give it a couple of months, it will start not feeling right again.
lifeisstillgood 12y ago
Everyone seems to have missed the most important part of the article "this was in France, and you can't just fire someone so if you hire badly you are stuck with that person forever" The US has the most liberal/right wing/psychotic labour laws in the Western world, and as such the best approach is to hire anyone not an idiot and fire them once on the job experience teaches you if it's a good fit. This results in massive turnover, and little incentive to improve the interview process I'm not sure where I am going with this but I am amazed that the local labour laws are not mentioned on this three (afaik)
- Renaud 12y ago
  Even in the US, where labour laws generally don't favour the worker, it wouldn't make much sense to set the bar too low and count on being able to fire people to eventually get the right one. Hiring people is resource consuming and is always a large investment for a company. Unless you are hiring low-skill workers who can easily be replaced, a high-tech worker will require time before she's productive on the job. Those weeks/months, cost money and figuring out that someone is not working out after 3 months of investing in her could cost a lot more to the company than just the cost of re-hiring someone else. It's always a better strategy to be diligent early and avoid wasting company resources just to shorten the hiring process. That being said, being able to easily part ways with an employee is important for a company since the cost of taking a risk is much lower. In France, employers are very reluctant to take risks as they can get stuck with people who are either bad or don't fit in. There is a middle ground between a system where you can fire people for any reason, whether related to their work or not, and a system where you can't even fire people who don't work out.
  - lifeisstillgood 12y ago
    Tokenadult has a regular post that has grown to the size of a small essay which basically says the only way to tell if someone can do the job is to give them the job to do. How long does it take to become obvious someone is not a good fit? A couple of hours? No, if humans could not fake it for a couple of hours no one would ever go on a date again. A couple of days - maybe. My own pet theory is when I hit a new contract is to commit a bug fix by the end of the day and push to production by the end of the week. But no one sane is willing to give a week to an interview, and few a whole day. I think in the end we judge people by their public output - in other words GitHub reall is going to be our CV
randomfool 12y ago
In these free-form discussions I find it really important to politely disagree with some technical decision of their project to see how they take the feedback and defend the decision. Red flags are when they either cannot accept disagreement or come up with questionable justifications. Correct answers include clear explanations of what the trade-offs would be and clear rationale for their original decision process.
- clairity 12y ago
  this is a good point. one developer i hired had the spark but not the maturity to deal with disagreement objectively. he has trouble communicating and working with others. he has potential, so i'm hoping he grows out of it over time.
- bubblicious 12y ago
  Yes, those open questions could tell you a lot about how the person communicates as well, even though I was very careful as the context of an interview is always biased towards people who are extraverts.
crazygringo 12y ago
On the one hand, this resonates with me... the last time I was doing a round of interviewing (being interviewed at several companies), one person asked this question -- and it was the one point when I really "lit up" and really enjoyed being interviewed. On the other hand, I wonder if it really produces results that are any better. At least, with a quiz, you can give it to current employees who work great, and discover the quiz turns out to be worthless. (As the author described.) But with a open-ended question inviting open-ended answers, how can you tell if it's really working? Of the many coworkers I've had before, I can think of one who certainly would have aced the question -- a programmer through and through -- but who was fired after a few months due to poor work ethic and sloppiness. Because while he had enthusiasm for programming, he had no time for "standards" or "teams" or "business needs" -- things like commenting code, communicating well with others, following through on commitments, etc. So I wonder if the author is going to discover, after a few more months, that there are a few more questions than just this 1 question that also matter just as much...
- Kaivo 12y ago
  I recently went through an interview where they asked me somewhat similar questions, where I was able to talk about my personal projects and let them see how much I love doing that. Before the interview, they told me they went through my Github and looked at my projects, and actually called me for an interview partly because of that. My Github served me as a portfolio. Artists have to hand in example of their work, and I believe programmers should do as well. That should be enough to see most of those who don't comment enough, don't follow rules and standards, etc. It still comes back to the issue of having time to work on personal projects and having it displayed somewhere, but the same could be said for Artists.
- bubblicious 12y ago
  To answer your question, I worked for another year for that company and must have done about 100 interviews with that method. It wasn't perfect, but I found that it gave better results than the other stuff I had tried. Also, I found that the more I would bring the person in his comfort zone, the better appreciation I had for their qualities as a programmer. Also, that one question would always lead to a 30 minute discussion about their project (hobby or work). I would of course ask a bunch of other questions, but it was on the things they were the most comfortable with. I didn't have to ask them if they knew this or that, they would tell me all that they knew and we would discuss it. And wherever there was excitement, there was an indication of a good hire.
nwhitehead 12y ago
If you are limited to one short question, a better choice is to ask them: "Teach me something technical you've learned recently." You can evaluate their answer on technical depth and correctness, communication skills, and timeliness of the topic. And if they can't think of anything they've learned recently, that tells you something as well.
- dpark 12y ago
  I suspect you're largely filtering for people who are aggressively interviewing. When I'm deep into a meaningful project, I spend less time learning interesting technical bits. When I'm looking for a new job, I spend a lot of time learning random things that might be useful as a clever answer in an interview (because that's what so many interviewers want).
- fillskills 12y ago
  Thats a neat question. Will keep it in mind for the next interview in addition to the OP
sheepmullet 12y ago
My best project was 12 years ago and I hated it at the time. If you had asked me about it while I was working on it, and I didn't sugar coat, I bet you would have said no hire. Secondly, it has just taken me 10 minutes to remember the details in enough depth to have a proper conversation about it. Again that would probably be "best work behind him...", or "doesn't seem to know the details....insincere" etc. This question is easy to game and disadvantages people who aren't prepared for it.
- sumedh 12y ago
  If you know body language you can figure out if the candidate is honest or lying.
zeroonetwothree 12y ago
It seems that every week there's a post on HN about the "right way" to do interviews. It's too bad there's never any research done to actually test these strategies. I don't believe that you can get a good answer just from personal experience.
rdtsc 12y ago
Ok this is good. I have been facing the same problem. I did fizzbuzz, we have the quiz I also often ask about he "favorite" or most challenging "project", but I don't dwell enough on it. But now I think I should. I like this, I will have to steal this idea.
fiatjaf 12y ago
I see this kind of passion about personal projects and excitements about doing something only in the programming field, maybe some other fields, but never fields like dentistry or civil engineering. Am I missing something? What prevents people from other fields from having "personal projects" to be excited with?
rbobby 12y ago
Shows up to the interview and then spends 5-10 minutes quietly reading the candidate's resume and making notes. Not very courteous and makes for an awful first impression.
- vehementi 12y ago
  Said commenting, not silently reading. "Ok you worked here... and here... you worked on this? Ok..." without saying "explain your work here" etc.
chazu 12y ago
Great article. Despite the comments decrying this 'one question' as unfair, I think we can all agree that having a real passion for programming is the single most important thing in making it from nooblet to competent and confident developer.
ScottBurson 12y ago
I like to ask a variant of this: "what's the most interesting project you've done?" If they come back with something that impresses me, I take that as a good sign.
dj-wonk 12y ago
I really hope that the magic question is useful, and I agree that many boilerplate Java-specific questions are misguided and less useful. Still, but I find it unwise to bet everything on one question. Did the author collect data once he perfected his technique. Is there data? In my experience, the best tests have many questions, including "experimental" ones, because you want to be able to test your hypothesis against various data points. I'm also not saying that everything needs do be quantified. Open ended questions are very useful. But why not at least collect the data and tally it to the best of your ability.
kabdib 12y ago
One of my favorite questions is, "Tell me about the best bug you've ever found." It's a great touchstone. Sure, it's subjective, but it gives valuable insight into someone's level of skill, how they approach problems, how they do diagnosis, and so on. Are they scientific? Do they hate on people and their code? Do they follow through with testing? I've gotten answers ranging from "I don't know" (which is a fail, by the way) to full-stack expositions that boil down to bad code generated by the compiler, to someone finding and solving a fundamental design problem in a years-long project. Any sufficiently senior engineer will have a tale of a bug that they tell in the circle around the campfire when the kids are tucked away (and probably still listening anyway). And if you're not a seasoned vet, I'd still like to hear about the race condition / double free / syntax error that took you a while to find.
- YZF 12y ago
  I think when you're just starting that first race condition or memory management issue are exciting. After a while it's not that exciting any more. I got asked that question and the first thing that popped to my mind was a very unexciting bug I was chasing in legacy code I was maintaining. I don't think the interviewer liked that answer because it was mostly grunt work and not some some amazing feat of engineering. I don't think it's a particularly good open ended question for more experienced developers and an interview is not a camp fire circle... It could be part of an investigation in some past project, e.g. what problems did you have and how did you solve them...
- halisaurus 12y ago
  I've had this question asked of me before, and it seems valuable for the same reason as the question on the article: It's an opportunity to show passion/enthusiasm for programming work. I think even novice programmers who love to code will have that one bug that got them. Even if the story is anticlimactic ("I missed a semicolon"). iMo, explaining how they got to that conclusion in a logical, positive way, didn't give up or just copy/paste the answer, and ultimately moved on in the project with a new lesson in syntax is the real "passing answer."
- trentnelson 12y ago
  > One of my favorite questions is, "Tell me about the best bug you've ever found." I've started an initial push at Continuum to open source our interview questions... and this is the first question :-) https://github.com/ContinuumIO/interview-questions https://github.com/ContinuumIO/interview-questions
gregwebs 12y ago
Others have noted that the best way to interview is to see if someone can do the job is to have them do the job or the closest thing to it. For the typical developer not available for freelance I combine this approach with the approach in the article. Show me some code from a project of yours and I will ask you to add a feature, fix a bug, or maintain it. The project can be something really simple. It is hard to learn new technologies without creating some kind of simple project. This is a second interview, the first interview is by Skype to figure out the logistical/cultural fit, go over resume, and then spend some time talking through a technical issue. This worked very well for my first hire. The downside of this approach, and a big reason it is not done is it requires an hour of preparation time for the interviewer to understand the candidate's code, run it, look for bugs, and figure out what to ask about. I think it is a much less arrogant way to conduct interviews though and a much more rewarding process for the candidate: they get to delve further into something they already have interest in.
capkutay 12y ago
With all the APIs and frameworks that make churning out good looking, usable apps a relatively simple process, I don't think this is a good question by itself.
dzink 12y ago
To add on to the "Tell me about a project you are most proud of?" question, having gone through different stages from burnout to re-kindling of the hacker within, I can see it measures attitude well, which is crucial. For aptitude, however I would go a few layers deeper. "What was the toughest problem you have worked on or solved?", "How did you solve it?", "What did you learn?" the choices of problems tell you as much if not more than the answers about where the candidate's passion stands. Are they vague or specific? Do they use industry terms or are they self taught? What types of issues make their eyes spark? etc. If you are hiring entry level people, passion is most important, but if you need to have people who hit the ground running in an area, nothing beats a nice rigorous interview, with some code writing involved, in addition to your question.
fillskills 12y ago
In addition to hiring people passionate about coding, I have found out that anyone who is really passionate about something (music/surfing/rock climbing etc) is a good programmer. Some of the best programmers I worked with were either crazy about programming or passionately followed through with something else in their lives. The key being that they followed through with their passion. Has anyone else seen this? Or is my data too limited to my personal experience
nardi 12y ago
The real problem with this style of interview question is that it is good for those who talk well, and bad for those who don't talk well. I have seen my fair share of candidates who are great talkers, but can't code for crap. The interviewers who didn't ask coding questions loved them, but those of us who made them code knew they sucked. You should have stuck with programming on the white board. That's the right way to find good programmers.
falsedan 12y ago
I like a more structured technique called GRASS, described in Ovid's 'Agile Companies go P.O.P.' presentation: http://www.slideshare.net/Ovid/a-14058644/22 http://www.slideshare.net/Ovid/a-14058644/22 The basics are: ask the candidate to describe a project they worked on (that they enjoyed, listed on their resume, or anything). Ask follow-up questions until you find out: the Goal of the project; their Role on the team; what Actions they personally took to reach the goal; whether the project Succeeded or not; and Speculation on what they would do differently in hindsight. Repeat until they run out of projects to talk about, or you run out of time.
netforay 12y ago
My interview question was similar "What is the biggest program you have ever written" (As I hire only freshers). Problem is, not even 1% seems to pass this test. For those who are talented but lazy till now, I offered another choice, or "Can you do me a small Snake game now"?

261 points by bubblicious 12y ago

I'm fairly certain I can't pass this test even though I've tried. Just haven't had the skills yet for what I want to make and the stuff I've made doesn't impress the people I want to be with.

insaneirish 12y ago

I can't take seriously someone who doesn't capitalize letters appropriately.

sho_hn 12y ago
Most alphabets don't have letter case. Its utility particular in written English is questionable at best. I'm not saying you should stop capitalizing, mind you -- there's value in standardized orthography. But it's a good idea to set your horizon beyond it. I've noticed that I've become much more flexible and less dogmatic about things like this since looking at a bunch of other languages and writing systems and recognizing written communication as spectrum.
- heurist 12y ago
  I learned the other day that before the printing press all characters were 'upper case' but were squashed down to be able to write quickly and use less space. Printing press creators copied what they saw in written text by creating small characters alongside the normal large characters and case rules developed out of that. You can play around with squashing handwritten uppercase characters (write them fast and small) and see why lowercase characters look the way they do.
- nawitus 12y ago
  >Most alphabets don't have letter case. But the latin alphabet is apparently the most common alphabet. I don't really see your argument here.
  - sho_hn 12y ago
    My argument is one in favor of being more flexible than the OP proposes, by introducing the idea that letter case isn't a universal or even frequent trait of similar writing systems, and that you can even call into question its utility. As for modern Latin (Latin originally didn't have letter case, either; widespread use of letter case is a fairly recent development), most common doesn't mean best - how the "market share" of languages and writing systems evolves is a more complex topic (Nicholas Ostler's Empires of the Word: A Language History of the World is a good book). That means looking at and comparing with other examples is often useful. It's a little like the reason you want to learn more than one programming language - it trains your ability to think about problems on a more abstract level than a single toolbox allows, and gives you insight into the strengths and weaknesses of each of your tools and how to apply them best. Even if you wind up only programming in a single language anyway. It also tends to make you less dogmatic and more willing to go back to first princples. Or willing to entertain notions like "just because this man isn't capitalizing his letters it doesn't necessarily mean he has nothing to tell me".
    - walterbell 12y ago
      Agreed. One could argue that modern "design thinking" involves the creation and extension of non-alphabetic, visual language. Someone unfamiliar with modern logos (e.g. share icons) and UI conventions (e.g. "hamburger" icon) may view these symbols like they would view Egyptian hieroglyphics. 2nd-order cybernetics is about observing the observer, which includes observing the limitations of communication. Studying different languages helps identify the limitations of each, i.e the untranslateables. There's a great book on this topic (we need an equivalent for software), a 1300 page "Dictionary of Untranslateables". http://www.washingtonpost.com/posteverything/wp/2014/07/16/how-to-translate-an-untranslateable-book/ http://www.washingtonpost.com/posteverything/wp/2014/07/16/h... "This depends on what one means by “untranslatable.” Cassin and her team believe that an “untranslatable” word is not one that cannot be translated, but rather a word we can’t stop trying to translate, aware always that we haven’t quite hit it, that it isn’t right."
      - sho_hn 12y ago
- insaneirish 12y ago
  He or she is writing in English. English has rules. Some rules are made to be broken. Capitalization is not one of them when it comes to writing coherent prose.
  - sho_hn 12y ago
    I disagree. I think the bar is "does this text accurately convey the intended meaning and is comfortable to read?", and I think it's interesting and worth thinking about that written English largely still meets that bar when you remove capitalization. Capizalization mostly doesn't encode significant additional information (yes, there are counter-examples - the article we're talking about actually does capitalize acronyms) or enhances ergonomics all that much. This is really more a social thing and about what the choice not to use capitalization communicates, i.e. you may be reacting negatively because you read it as a "I do not care to conform" or "I do not care about your appraisal of my writing" marker. Which is understandable, but I wonder if that isn't a too-quick judgement to serve as a rule.
    - xux 12y ago
      Nah DuDE if I wrItE liKE thIS DO u AUdoMAticalYLY geT annoyINgED? Yes. So why the heck is not capitalizing your sentences ok? Language is a tool to communicate with the masses. We have rules and standards so everyone can understand them. If you can't do that effectively, then you have failed in your communication.
      - sho_hn 12y ago
        > So why the heck is not capitalizing your sentences ok? The two examples aren't the same, and the reasons a reader experiences discomfort reading your example text are different. They're about ergonomics. The erratic variations in letter footprints and the up-and-down-and-up from the ascender line to the x-height and back affect reading speed. It's also spurious; the capitalization style in your example doesn't add additional information. Try giving some thought to capitalization along those lines. Does capitalization add information that otherwise isn't explicit? How does it affect reading speed? The anwers are roughly "yes, sometimes" and "yes, sometimes" (the latter depends a lot on how you define "reading speed/performance"; "reading" decomposes into a set of different types of interacting with text, like searching, information/keyword retention, etc). You can call this a good case for capitalization, but I'm not convinced it's a given, and competing writing systems do get by well without it. > We have rules and standards so everyone can understand them. Sorta. "Understand" is a big topic to broach, see above. It's of course true that shared language and shared orthography enable sophisticated communication and grease its wheels. And in that light, not conforming may suggest an exclusionary attitude (just like e.g. excessive use of jargon can be motivated by tribalism). But it's not where I'd personally draw the line; I'd read a text rather than dismiss it beforehand based solely on a lack of capital letters. > If you can't do that effectively, then you have failed in your communication. The many other comments discussing the actual information content of the text seem to suggest that it hasn't.
archagon 12y ago
I think it lends a sense of humility to the writing.
- sliverstorm 12y ago
  To me it just lends a sense of laziness.
ldng 12y ago
It's some French hipster fad. My ex-boss did it too. It can b annoying at times but once you get accustom, it's bearable. I don't even notice now.
- deleted 12y ago
  [deleted]
ianstallings 12y ago
It doesn't help that it's pretty long-winded to just make a simple point, taking it from just annoying to painful. I think I could fit the point into a tweet to be honest - 'What was your most interesting project?' is the best interview question. And the fact that we're discussing it here in this thread makes your point stand - it detracts from the message trying to be conveyed.

asuffield 12y ago

The flaw in this method is that it assumes there is only one kind of developer: the lone architect, who builds fine tents out of whatever is lying on the ground and then departs. What it won't get you is breadth of experience, operational background, full-stack thinking, or people who can look at somebody else's work and say "here are the ways in which that is going to blow up in your face, two years from now". (Anybody care to add to this list?) If all you ever do is bootstrap new projects from nothing then maybe that's the sort of people you want to hire, but it's probably not enough to build a sustainable product.

Spearchucker 12y ago
It doesn't assume that at all. You as the interviewer get to listen. You can ask probing questions to get the insight you need, or to steer the conversation. It's a great question, because it relaxes the interviewee as she gets to talk about something she knows well, probably enjoyed, and - if she's as good as you hope - has good depth and breadth of knowledge about.
howeyc 12y ago
I admit I just skimmed the article, but I don't see a requirement that the project you choose to talk about be a solo effort. I think the point of the question is to find people who are passionate about their profession (in this case programming).
iamben 12y ago
I'm not sure I agree - from reading the article, I got that the author found people who were excited and passionate about what they did, people who were excited to code. It may have been the lonewolf project that lit them up, it may have been the massive team effort where they found a novel way to help an entire team. But it was someone who really believed in something, rather than someone who was simply working for the weekend.
Goladus 12y ago
I don't think that question precludes all of those things. Anyone who is a "full-stack thinker" with broad experience should have at least one project in their past where they created something they're proud of.

reality_czech 12y ago

Everyone knows that the only question you need to ask is "how is this an issue?" http://27bslash6.com/interviews.html http://27bslash6.com/interviews.html

Goladus 12y ago

tl;dr: The question he arrived at is: “... will you please tell me about the best project that you’ve ever created?” Then watch for enthusiasm and pay attention to the details. The goal seems to be to identify someone who really enjoyed and takes pride in a program they've written.

wildpeaks 12y ago
The "project you're the most proud of" might be a more precise way to phrase it because "best project" could mean either: - created the most value for your employer even if it was a soul-sucking nightmare / merely maintenance project with no challenges. - you learnt the most from it / overcame challenges you didn't know you could / came up with moonshot solutions to issues no one even realized were there.
- spoondan 12y ago
  People can be proud of either of those accomplishments as well. Honestly, I doubt "most proud" versus "best" makes a difference at all. Candidates generally explain their answers to these open ended questions. If they (for some reason) don't recognize the implicit, "And why?" part of the question, you just follow up with it. The conversation will never be just, "Foobaz, next question." One way or the other, it will be, "Foobaz because..." It saved the company $2M/year. Or users really loved it. Or it improved the engineering process and made releases faster and lower risk. Or it was a really tough problem that required a lot of creative thinking. Or it taught me a lot about 3D game programming.

warcher 12y ago

It's always surprising how often interviewers fall back on "API Jeopardy" when trying to make hiring decisions. Maybe it's just because my career hasn't really allowed the luxury of getting deep on any technical stack and staying there, but I just don't keep the details of obscure function calls in my head all the time. And I have to wonder at the utility of testing a developer on having memorized the kinds of things that they will always, ALWAYS be able to look up when they're actually working.

coldcode 12y ago

Thank you, finally someone who gets the idea. Though I like to ask two questions, one the best project you ever worked on, one the worst project you ever worked on. You can learn a lot about a programmer by the details they relate in both cases.

chippy 12y ago
ooh, that is a good one! I wonder if some people would mention the same project?

danmaz74 12y ago

The "tell me about your best project" question is great, but I always combined it with one apparently simple programming question, like giving the quadrant from the (x,y) coordinates. Maybe the OP is able to understand how logic-minded his candidates were just from talking, but many times I was disappointed from the actual ability to write down some code (even discounting the stress of the situation).

ruswick 12y ago

The problem is that this method disproportionately hurts people who don't have the time or energy to effectively hold two jobs (one full-time position at their day job and one as an independent developer or open-source contributor by night) because of family, friends, or some other facet of life beyond their laptop. I think it's totally unreasonable to expect that everyone spend every minute of their lives coding or to have some kind of deep, personal connection to the code they write. This thinking is ridiculous, and doesn't really appear in any other industry. Do you care whether your accountant's idea of an enjoyable Friday night is sitting at home making more spreadsheets? Would you demand that your eye doctor go home and craft her own lenses in her garage for fun? Competency doesn't require fanaticism, and no employer should expect that their employees devote their entire lives to their occupation. If I want to code for 8 or 10 hours a day, go home and enjoy myself in the little free time I do have, then wake up and do it again, I don't see why that makes me an inferior employee. This just seems like more misguided, unjustified cultural absolutism that is so prevalent in the industry. EDIT: For those saying that the article doesn't necessitate spending massive time outside of work writing code, the author clearly conflates the two. "i have always been convinced that those who love code do not restrict their coding activities to their work. they take home that love and continue to create for fun as a hobby." Personally, I think passion could be a valuable heuristic in hiring, but the author seemed to imply that passion is only measured by your willingness to work outside of your day job. At the very least, that seems to be his expectation of good candidates, and his hiring process clearly disadvantages people who can't or won't code 24/7.

eps 12y ago
Accountants don't create something out of nothing. It's an inherently supporting activity. Also, the question doesn't imply in any way that it has to be an off-work project. Its only point is to see if a person actually cared for any code they wrote in the past or if they treated coding just as means to an end.
- nawitus 12y ago
  The question in the article was 'will you please tell me about the best project that you’ve ever create', which excludes most work projects, since work projects are typically not single-developers projects.

kika 12y ago

That's almost exactly what I was doing for years. Two differences: 1. I sometimes ask 1-2 technical questions, for example if the candidate claims exceptional knowledge of some important (for us) technology, but his/her resume doesn't show extensive use of it. Like: "You say you know CouchDB inside out, but you've used it only once and not for long, interesting.... Can you tell me how the _changes feed works - if I listen on this feed do I get just the changed documents IDs or whole documents?" 2. Instead of "what's your best project" I ask more aggressive question - "imagine I give you 1 million dollars right now and in return I want to be a part of what you use it for - a share of profits, credits in the movie, etc. What would you do?". Edit: ah, the almost mandatory third question: why do you want to leave the job you're currently having?

cottonseed 12y ago

The best advice I've seen on how to structure an interview came from Nick Corcodilos of Ask the Headhunter [1] fame, from his book Reinventing the Interview to Win the Job [2]. If you want to show someone you can do the job (or see if they can do the job), do the job, or as close as you can get to it in an interview setting. Anything will be selecting for indicators that will be more or less correlated with job performance. [1] http://www.asktheheadhunter.com/articles.htm http://www.asktheheadhunter.com/articles.htm [2] http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0452278015&linkCode=as2&tag=wwwonebadseec-20&linkId=OBQZTIGOSOWYFUSZ http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=...

cottonseed 12y ago
Coincidentally, the most recent Ask the Headhunter article [1] is "The Single Best Interview Question... And The Best Answer". Hint: It isn't about your hobby project. [1] http://www.asktheheadhunter.com/habestinterviewquestion.htm http://www.asktheheadhunter.com/habestinterviewquestion.htm
- lifeisstillgood 12y ago
  Absolutely love that ! Weirdly it reminds me of ramit sethi briefcase "technique" which is roughly research the prospect, come up with some proposal that shows you can as value and pull it out of your briefcase at the opportune time.
- djur 12y ago
  This is specifically about technical interviews as one of several steps, though. "What is your plan for being effective in this job" is the kind of question that, in the OP's three-step interview, should be asked by the manager. My current employer has candidates do a brief presentation about a project they are proud of. It's useful but imperfect (some people just aren't good at speaking to a group, which is okay for this job; some people aren't legally permitted to go into a lot of detail about their earlier projects).

xur17 12y ago

From an interviewee's perspective, these are my favorite interviews too. I get to talk about something that interests me, and have a discussion about the different decisions I made. If the interviewer wants, they can dig into specific details, or ask more pointed questions about the programming language. I find trivia questions off-putting, and tend to limit the depth of discussion into my skills. And to the people saying that this necessitates projects outside of work - I don't see why it does. You can talk about school projects, projects from previous jobs, etc.

recalibrator 12y ago

TL;DR Please tell me about the best project that you’ve ever created

Tomis02 12y ago

Give it a couple of months, it will start not feeling right again.

lifeisstillgood 12y ago

Everyone seems to have missed the most important part of the article "this was in France, and you can't just fire someone so if you hire badly you are stuck with that person forever" The US has the most liberal/right wing/psychotic labour laws in the Western world, and as such the best approach is to hire anyone not an idiot and fire them once on the job experience teaches you if it's a good fit. This results in massive turnover, and little incentive to improve the interview process I'm not sure where I am going with this but I am amazed that the local labour laws are not mentioned on this three (afaik)

Renaud 12y ago
Even in the US, where labour laws generally don't favour the worker, it wouldn't make much sense to set the bar too low and count on being able to fire people to eventually get the right one. Hiring people is resource consuming and is always a large investment for a company. Unless you are hiring low-skill workers who can easily be replaced, a high-tech worker will require time before she's productive on the job. Those weeks/months, cost money and figuring out that someone is not working out after 3 months of investing in her could cost a lot more to the company than just the cost of re-hiring someone else. It's always a better strategy to be diligent early and avoid wasting company resources just to shorten the hiring process. That being said, being able to easily part ways with an employee is important for a company since the cost of taking a risk is much lower. In France, employers are very reluctant to take risks as they can get stuck with people who are either bad or don't fit in. There is a middle ground between a system where you can fire people for any reason, whether related to their work or not, and a system where you can't even fire people who don't work out.
- lifeisstillgood 12y ago
  Tokenadult has a regular post that has grown to the size of a small essay which basically says the only way to tell if someone can do the job is to give them the job to do. How long does it take to become obvious someone is not a good fit? A couple of hours? No, if humans could not fake it for a couple of hours no one would ever go on a date again. A couple of days - maybe. My own pet theory is when I hit a new contract is to commit a bug fix by the end of the day and push to production by the end of the week. But no one sane is willing to give a week to an interview, and few a whole day. I think in the end we judge people by their public output - in other words GitHub reall is going to be our CV

randomfool 12y ago

In these free-form discussions I find it really important to politely disagree with some technical decision of their project to see how they take the feedback and defend the decision. Red flags are when they either cannot accept disagreement or come up with questionable justifications. Correct answers include clear explanations of what the trade-offs would be and clear rationale for their original decision process.

clairity 12y ago
this is a good point. one developer i hired had the spark but not the maturity to deal with disagreement objectively. he has trouble communicating and working with others. he has potential, so i'm hoping he grows out of it over time.
bubblicious 12y ago
Yes, those open questions could tell you a lot about how the person communicates as well, even though I was very careful as the context of an interview is always biased towards people who are extraverts.

crazygringo 12y ago

On the one hand, this resonates with me... the last time I was doing a round of interviewing (being interviewed at several companies), one person asked this question -- and it was the one point when I really "lit up" and really enjoyed being interviewed. On the other hand, I wonder if it really produces results that are any better. At least, with a quiz, you can give it to current employees who work great, and discover the quiz turns out to be worthless. (As the author described.) But with a open-ended question inviting open-ended answers, how can you tell if it's really working? Of the many coworkers I've had before, I can think of one who certainly would have aced the question -- a programmer through and through -- but who was fired after a few months due to poor work ethic and sloppiness. Because while he had enthusiasm for programming, he had no time for "standards" or "teams" or "business needs" -- things like commenting code, communicating well with others, following through on commitments, etc. So I wonder if the author is going to discover, after a few more months, that there are a few more questions than just this 1 question that also matter just as much...

Kaivo 12y ago
I recently went through an interview where they asked me somewhat similar questions, where I was able to talk about my personal projects and let them see how much I love doing that. Before the interview, they told me they went through my Github and looked at my projects, and actually called me for an interview partly because of that. My Github served me as a portfolio. Artists have to hand in example of their work, and I believe programmers should do as well. That should be enough to see most of those who don't comment enough, don't follow rules and standards, etc. It still comes back to the issue of having time to work on personal projects and having it displayed somewhere, but the same could be said for Artists.
bubblicious 12y ago
To answer your question, I worked for another year for that company and must have done about 100 interviews with that method. It wasn't perfect, but I found that it gave better results than the other stuff I had tried. Also, I found that the more I would bring the person in his comfort zone, the better appreciation I had for their qualities as a programmer. Also, that one question would always lead to a 30 minute discussion about their project (hobby or work). I would of course ask a bunch of other questions, but it was on the things they were the most comfortable with. I didn't have to ask them if they knew this or that, they would tell me all that they knew and we would discuss it. And wherever there was excitement, there was an indication of a good hire.

nwhitehead 12y ago

If you are limited to one short question, a better choice is to ask them: "Teach me something technical you've learned recently." You can evaluate their answer on technical depth and correctness, communication skills, and timeliness of the topic. And if they can't think of anything they've learned recently, that tells you something as well.

dpark 12y ago
I suspect you're largely filtering for people who are aggressively interviewing. When I'm deep into a meaningful project, I spend less time learning interesting technical bits. When I'm looking for a new job, I spend a lot of time learning random things that might be useful as a clever answer in an interview (because that's what so many interviewers want).
fillskills 12y ago
Thats a neat question. Will keep it in mind for the next interview in addition to the OP

sheepmullet 12y ago

My best project was 12 years ago and I hated it at the time. If you had asked me about it while I was working on it, and I didn't sugar coat, I bet you would have said no hire. Secondly, it has just taken me 10 minutes to remember the details in enough depth to have a proper conversation about it. Again that would probably be "best work behind him...", or "doesn't seem to know the details....insincere" etc. This question is easy to game and disadvantages people who aren't prepared for it.

sumedh 12y ago
If you know body language you can figure out if the candidate is honest or lying.

zeroonetwothree 12y ago

It seems that every week there's a post on HN about the "right way" to do interviews. It's too bad there's never any research done to actually test these strategies. I don't believe that you can get a good answer just from personal experience.

rdtsc 12y ago

Ok this is good. I have been facing the same problem. I did fizzbuzz, we have the quiz I also often ask about he "favorite" or most challenging "project", but I don't dwell enough on it. But now I think I should. I like this, I will have to steal this idea.

fiatjaf 12y ago

I see this kind of passion about personal projects and excitements about doing something only in the programming field, maybe some other fields, but never fields like dentistry or civil engineering. Am I missing something? What prevents people from other fields from having "personal projects" to be excited with?

rbobby 12y ago

Shows up to the interview and then spends 5-10 minutes quietly reading the candidate's resume and making notes. Not very courteous and makes for an awful first impression.

vehementi 12y ago
Said commenting, not silently reading. "Ok you worked here... and here... you worked on this? Ok..." without saying "explain your work here" etc.

chazu 12y ago

Great article. Despite the comments decrying this 'one question' as unfair, I think we can all agree that having a real passion for programming is the single most important thing in making it from nooblet to competent and confident developer.

ScottBurson 12y ago

I like to ask a variant of this: "what's the most interesting project you've done?" If they come back with something that impresses me, I take that as a good sign.

dj-wonk 12y ago

I really hope that the magic question is useful, and I agree that many boilerplate Java-specific questions are misguided and less useful. Still, but I find it unwise to bet everything on one question. Did the author collect data once he perfected his technique. Is there data? In my experience, the best tests have many questions, including "experimental" ones, because you want to be able to test your hypothesis against various data points. I'm also not saying that everything needs do be quantified. Open ended questions are very useful. But why not at least collect the data and tally it to the best of your ability.

kabdib 12y ago

One of my favorite questions is, "Tell me about the best bug you've ever found." It's a great touchstone. Sure, it's subjective, but it gives valuable insight into someone's level of skill, how they approach problems, how they do diagnosis, and so on. Are they scientific? Do they hate on people and their code? Do they follow through with testing? I've gotten answers ranging from "I don't know" (which is a fail, by the way) to full-stack expositions that boil down to bad code generated by the compiler, to someone finding and solving a fundamental design problem in a years-long project. Any sufficiently senior engineer will have a tale of a bug that they tell in the circle around the campfire when the kids are tucked away (and probably still listening anyway). And if you're not a seasoned vet, I'd still like to hear about the race condition / double free / syntax error that took you a while to find.

YZF 12y ago
I think when you're just starting that first race condition or memory management issue are exciting. After a while it's not that exciting any more. I got asked that question and the first thing that popped to my mind was a very unexciting bug I was chasing in legacy code I was maintaining. I don't think the interviewer liked that answer because it was mostly grunt work and not some some amazing feat of engineering. I don't think it's a particularly good open ended question for more experienced developers and an interview is not a camp fire circle... It could be part of an investigation in some past project, e.g. what problems did you have and how did you solve them...
halisaurus 12y ago
I've had this question asked of me before, and it seems valuable for the same reason as the question on the article: It's an opportunity to show passion/enthusiasm for programming work. I think even novice programmers who love to code will have that one bug that got them. Even if the story is anticlimactic ("I missed a semicolon"). iMo, explaining how they got to that conclusion in a logical, positive way, didn't give up or just copy/paste the answer, and ultimately moved on in the project with a new lesson in syntax is the real "passing answer."
trentnelson 12y ago
> One of my favorite questions is, "Tell me about the best bug you've ever found." I've started an initial push at Continuum to open source our interview questions... and this is the first question :-) https://github.com/ContinuumIO/interview-questions https://github.com/ContinuumIO/interview-questions

gregwebs 12y ago

Others have noted that the best way to interview is to see if someone can do the job is to have them do the job or the closest thing to it. For the typical developer not available for freelance I combine this approach with the approach in the article. Show me some code from a project of yours and I will ask you to add a feature, fix a bug, or maintain it. The project can be something really simple. It is hard to learn new technologies without creating some kind of simple project. This is a second interview, the first interview is by Skype to figure out the logistical/cultural fit, go over resume, and then spend some time talking through a technical issue. This worked very well for my first hire. The downside of this approach, and a big reason it is not done is it requires an hour of preparation time for the interviewer to understand the candidate's code, run it, look for bugs, and figure out what to ask about. I think it is a much less arrogant way to conduct interviews though and a much more rewarding process for the candidate: they get to delve further into something they already have interest in.

capkutay 12y ago

With all the APIs and frameworks that make churning out good looking, usable apps a relatively simple process, I don't think this is a good question by itself.

dzink 12y ago

To add on to the "Tell me about a project you are most proud of?" question, having gone through different stages from burnout to re-kindling of the hacker within, I can see it measures attitude well, which is crucial. For aptitude, however I would go a few layers deeper. "What was the toughest problem you have worked on or solved?", "How did you solve it?", "What did you learn?" the choices of problems tell you as much if not more than the answers about where the candidate's passion stands. Are they vague or specific? Do they use industry terms or are they self taught? What types of issues make their eyes spark? etc. If you are hiring entry level people, passion is most important, but if you need to have people who hit the ground running in an area, nothing beats a nice rigorous interview, with some code writing involved, in addition to your question.

fillskills 12y ago

In addition to hiring people passionate about coding, I have found out that anyone who is really passionate about something (music/surfing/rock climbing etc) is a good programmer. Some of the best programmers I worked with were either crazy about programming or passionately followed through with something else in their lives. The key being that they followed through with their passion. Has anyone else seen this? Or is my data too limited to my personal experience

nardi 12y ago

The real problem with this style of interview question is that it is good for those who talk well, and bad for those who don't talk well. I have seen my fair share of candidates who are great talkers, but can't code for crap. The interviewers who didn't ask coding questions loved them, but those of us who made them code knew they sucked. You should have stuck with programming on the white board. That's the right way to find good programmers.

falsedan 12y ago

I like a more structured technique called GRASS, described in Ovid's 'Agile Companies go P.O.P.' presentation: http://www.slideshare.net/Ovid/a-14058644/22 http://www.slideshare.net/Ovid/a-14058644/22 The basics are: ask the candidate to describe a project they worked on (that they enjoyed, listed on their resume, or anything). Ask follow-up questions until you find out: the Goal of the project; their Role on the team; what Actions they personally took to reach the goal; whether the project Succeeded or not; and Speculation on what they would do differently in hindsight. Repeat until they run out of projects to talk about, or you run out of time.

netforay 12y ago

My interview question was similar "What is the biggest program you have ever written" (As I hire only freshers). Problem is, not even 1% seems to pass this test. For those who are talented but lazy till now, I offered another choice, or "Can you do me a small Snake game now"?