I’ll jump right into it: As an interviewer, ask all your questions strictly in the past tense. That’s simply all what’s there to it. Convert all your questions about technical knowledge, work experience, team work, attitude, even those IQ tests and hypothetical questions. Convert all of them into the past tense. Almost every single aspect of the interview should be in the past tense.

Think about this:
We all know that stupid question “Where do you see yourself in five years?“. What if you asked it in reverse? “Where were you five years ago and what got you here?” Do you sense the difference already? It’s all about facts, no fluff, just good old facts.

Now your main task as an interviewer is to find creative ways to form your questions in the past tense. Here is an example to get you started…

Instead of asking “What do you know about Web Session?”, ask: “Have you ever had to maintain user information across visit?”, and then follow-up with in-depth questions that will get you to the boundaries of their knowledge. Things like:

• Why did you do that? (What’s wrong with HTTP that made sessions a necessity?)
• What was your first intuition?
• What was your first solution?
• How long did it take? Did you build it iteratively or in one big chunk?
• What options did you have initially?
• What options did you explore?
• Did you want to do it differently?
• Was there a better way to do it?
• How did you learn about this subject?
• What compromises did you make?
• What ways did you try without working?
• Did you collaborate with anyone else on this piece?
• What was their role?
• Tell me more about your teammates’ contribution.
• For example, for data science positions, I always ask:
• How long have you been interested in data science?
• What did you do about this interest? how did you develop it recently?
• What was the last technical book you read? and when?

One series of questions about a single project will give you insights on their technical knowledge, learning ability, work experience, problem solving approach, and even their team dynamics.

But… why does this work?

• Because people are more comfortable telling stories than imagining things.
• Because interviews are meant to measure existing knowledge, not hypothetical one.
• Because you want to ask about their problem solving skills, instead of imagining problems and imagining their solutions, why not tap into the tens of problems they’ve already solved (or at least tried to solve)?
• Because asking about the past allows you to watch their reactions, tone and body language. All of those are great indicators of honesty, confidence and excitement and/or pride in what they did.
• Because being a fast thinker isn’t really relevant in the workplace. (Unless you are interviewing for a pursuit car driver, the candidate will have a day or two to solve the problem).
• Because, in some rare cases, you can ask them to solve a puzzle in front of you, but again, what does that prove? they’re good at puzzles? they memorized it well? they’re geniuses? or that, to put it bluntly, they’re just not stupid.
• Asking hypothetical questions is confusing and absurd. Things like “How many tennis balls fit in a school bus” or “How would you react if a hurricane hits right now” might give you information about who does this person want to be, but not about who this person is right now.

What about fresh graduates?

If you have a fresh graduate that has spent four-to-six years in university and has nothing tangible to talk about (not even a graduation project, an online competition, a contribution to open source, not even a classroom project), you really don’t want to be in that meeting room in the first place.

What about programming skills and the real stuff?

The best way to measure code quality is to ask them to write code and then review it. I’m preparing another blog post on post-interview mini-tasks that I’ll publish very soon. Stay tuned 😉

What do you think? Do you have any good interview tips to share? Did you try forming questions in the past-tense? How was your experience?