How I ended up conducting the most successful technical interviews with a single question 3

How I ended up conducting the most successful technical interviews with a single question

i conducted my first tech interview in 2008. at that time, the company already had a working process that i followed: interviews were 1 hour. the candidates would have 30 minutes to answer a 15 questions quiz. then we would spend 15 minutes talking about their answers plus an additional 15 minutes answering questions about the job. i quickly realized how terrible that questionnaire was.




Ryan Seifert‘s insight:

An interesting article for me; since I believe I started interviewing roughly the same time. We took similar paths (but I did not attempt to automate the process); migrating from some technical questions to a much more open ended process.


I recall one particularly rough interview; where after I started into my 10 technical questions the candidate quickly grew agitated. A agitated interviewee was a wholly new experience for me; I felt the blood drain from my face as he yelled, “I WON’T TAKE A TEST!” over the phone. Trying to regain my composure and calm him down; I let him know there was no score or grade. The questions are really discussion points to see how you code and design. The statement did little to soothe him; as I only heard a louder, “I WON’T TAKE A TEST!” in response. I decided at this point he was not a good cultural fit and started to bring the interview to a close. My salutation of “I appreciate your time and am sorry if I offended you. If you have any other questions for me, please ask.” was met with a quick “Click” and dial tone. Needless to say; this did spark a review of my interview process.


While the author coalesces on a single question, I have left mine at two:

  • What has been your favorite project to build and what challenges did you face during the development?
  • In your opinion what has been the most interesting bug you have had to locate and squash?


The follow up discussions on these questions easily leads into some technical questions on the language they used and which design patterns they implemented. More importantly it allows you to see which areas of software they are most passionate and interested in. Finding great talent and putting them into an environment where they can flourish will ensure excellent results. Switching to this open ended format took me from around a 20% success rate (ouch) to more than 80%; which have failed due to reasons other than technical prowess.


Looking back at the interview experience I touched on earlier; how much different could it have gone if I had asked my 2 questions and delved deeper into a subject near to them.

Leave a comment

3 thoughts on “How I ended up conducting the most successful technical interviews with a single question

  • Roderick Mendoza

    Neat article; I remember some of those 10 questions.

    I do have one problem with this method though; it 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 at night). I think it is unreasonable to expect that everyone spend every minute of their lives coding or to have some deep, personal connection to the code they write.

    If I want to code for 8 to 10 hours a day, go home and enjoy myself in the small amount of free time left; I don’t see why that makes me an inferior employee.

    • Ryan_Seifert Post author

      Good to hear from you Rod!

      You bring up a good point; it touches on one of the few issues I have with the article. I specifically phrase my questions to avoid implying that it must be a side project. In fact most of the responses I get are not on side projects; but team projects the interviewee has contributed in. The purpose of the question is to promote a discussion on a project that they are at best passionate about, and at worst knowledgeable about. I’ve found it puts the other person in a much more comfortable position; allowing them to better field the technical and design questions about their project.