Technical interviews are basically the process of conducting an interview for a person applying for a technical position. You need to make sure you ask questions in the interview that will help you determine if that person will be a good fit for the team, and if they have the correct technical skills for the position. While this seems easy, the problem is made difficult by reading a couple of hundred resumes and having to interview all the qualified applicants while you are also holding down a full time job.
In this article by Nicolas Bize, we learn how his interview process evolved.
The one question to rule them all
I can remember exactly when I first started programming. QBasic was shipped with MSDOS 5.0 way before windows 3.1 came out. It contained its own help screen with all of the functions and keywords of the language, like the perfect offline man page. To this day I distinctively remember the feeling that grasped me every time I hit F5 and saw my programs execute before my eyes. A single printed line, a prompt for a name, some colors, a puzzle… I was in heaven. I remember putting line numbers before each command, filling my code with horrible
GOTOs, learning with excitement and fascination something new everyday. I loved programming. I would spend hour after hour creating games, solving problems, showing stuff to my parents and friends. Years went by, I went from qbasic to pascal to vb, wrote games for our BBS “Atomic BBS” that we ran from our home phone line through a 2400bps modem. I wasn’t really good. Well in fact I really sucked and my code was pretty horrible! But man did I love it!! I just couldn’t let it go… I guess some people feel that type of adrenaline the first time they fly a plane, sail a boat, smoke weed, eat at in n out… For me it was programming, compiling, executing. I gained that feeling 25 years ago, and it has never left me since. I was born for this. I’ve always been a programmer.
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. How many times have I felt frustrated at work because of a struggling eclipse, only to find relief and joy when writing ruby on rails code back home!
And so it was, that after 1 year of trial and error, I completely stopped handing out technical tests. I would sit down with the candidate, read and comment his resume without asking him any questions for a good 5-10 minutes. And then I would flip over the resume, look at the candidate in the eyes and ask: “we have about 30 minutes left. Will you please tell me about the best project that you’ve ever created?”
That simple, unique and nonjudgmental question was the key. Some answered vaguely about their previous work or school project. And then some others became suddenly alive and excited, even those who appeared to be the shyest. They would talk passionately about the game they were creating, the website they had made, the open source projects they had contributed to, the utilities they made after being stuck in the middle of nowhere without any internet access. They were proud to show me. I was always fascinated by what I heard and would ask about all the details of the project they had treasured. They opened up and talked about the technical difficulties that they had overcome, about the little personal touch they added. It was their baby. And as they talked it was impossible to miss: I could see that light in their eyes, the excitement of a child that compiles and runs his first
hello world. I would know right then that we had something in common. They were programmers too.
Most of them didn’t have a clue about struts or some other specific framework we were using. Yet once they got the job, they always ended up being golden developers. They learned faster, they produced better code, they inspired others with their creativity and positivism. They were coders at heart.
And in the end that’s all that matters.