All blog articles

5 Questions to Ask in an Interview

I’ve already written a post on the ten shittiest questions for job interviews. Today, let’s look at the bright side of the interviews. 🙂

I won’t tell you about any widely-known tricks or common questions like if a person is stressed, talk about some everyday stuff first, or the importance of allowing the interviewees to ask you questions and so on. Instead, I’ll only tell what I consider essential and a little less well-known. Here are the 5 questions to ask in an interview to learn useful things about a potential employee.

evil director

5. Outlook vs. knowledge depth

Very often, a smart tech lead comes to a job interview with a list of questions in their head and starts shooting them out at the job seeker after just one glance, storing the answers somewhere in the hippocampus. This kind of interview is sluggish and boring.

It’s much better to ask some cross-disciplinary questions, a tough question here and there, and then move away from the topics the interviewee is not particularly good in. Now, dig deeper into what the potential employee takes to like a duck to water. The more well-versed a person is on a topic, the deeper you must dig.

Say functional programming is a job seeker’s passion. Start with common interview questions about functional programming. Ask about higher-order functions first, smoothly move to monads and stop somewhere at ​​category theory. Or the person says to be really good at algorithms. In this case, start with bubble sort, move to expression trees, and state machines.

In brief, it makes more sense to focus on technical strengths: this gives you a better understanding of potential colleague’s capabilities, which is a must in a hiring process. Asking about the areas where the person is confident and taking it from there is a great beginning. Otherwise, at the end of the talk, you might ask something like, Is there something else you’re great at that we forgot to ask you?

4. “No idea!”

Your ideal employee must say this challenging phrase every once and again. Clearly, we all want to sound extremely smart and quick-witted at an interview. But being unable to admit you don’t know some things might as well be a cover-up for banal vanity and a reluctance to recognize one’s mistakes.

So as you get deeper into a topic, hearing an “I don’t know” when the person is at the very bottom of their knowledge is a must. Of course, if you reach the bottom of your knowledge sooner, that’s great! Hiring this person will do lots of good.

3. What is the most difficult task that you’ve worked on?

This question quickly reveals what a difficult task means to a person. It might turn out quite a trivial thing for your company, like a web application. Or maybe the interviewee will enthusiastically describe a mysterious bug that they’ve been chasing for several weeks and localized somewhere in the depths of .NET, having filed a hopeless fix application to Microsoft.

You can vary this question and replace the word “difficult” with “interesting”, “unusual”, “unpleasant”.

2. Finding solutions and presenting them

It’s almost my favorite interview question. To be a good fit for my company, a person should be able to find solutions and adequately convey them to others. As a potential employer, I like to go in-depth here. Do they pick the first solution that comes their way, or do they carefully evaluate alternatives? How do they choose the best one from several options? What are the criteria?

Now, how do they talk about the decision made? Is it clear communication? How do they react to clarifying questions? How do they perceive criticism? Are they annoyed when others try to understand an idea and hammer the same point over and over again? How do arguments go? Does this person argue at all?

Finding this all out isn’t easy. To get some answers, we give a person some exciting architectural problem and a couple of hours to work on it alone. Afterward, they show us the solution on a blackboard (at least it was like this before we became a fully remote team). It’s not a perfect simulation of an actual workflow because everyone is hyper-aware that it’s just a short interview process and not the real team dynamics. But it’s close enough. You can get loads of insights out of it.

1. Interviews are all about fact-finding

It’s not about your speculations, but facts, really! If a candidate claims to have created complex architectures, I ask them to sketch one of these complex architectures. If they say they love to read, I ask them to tell me about the awesome books they’ve read lately.

It’s very easy to settle for the generalities and move on. However, generic answers rarely provide you with any info at all. Why then ask a question at all?

— Have you ever written unit tests in Javascript?

— Yeah, in my last project.

You simply can’t stop asking at this point! You need to dig deeper!

— What test framework did you use?

— Jasmine.

— And how many tests were there in total?

— About twenty probably.

If they say there were 400 tests, you might want to ask more about the problems of its organization, launch, and support. How were the problems solved? If there were twenty, you’ve got your info and can move on.

Facts are the most rewarding thing you can get from an interview. Dig deep till you get some, don’t haste or stop halfway.


📢 Btw, we are hiring an Educator.

Psst... Wanna try Fibery? 👀

Infinitely flexible product discovery & development platform.