I’m not talking about FAANG-like whole day endurance test but time-limited (1-2h) talk. Disclaimer: This is an exclusively personal opinion.

It starts from (surprise) preparation.

Check his CV, public git, StackOverflow, blog, and note some key points of interest to start a discussion. Any specific technology, business domain, or scientific field. E:G:

  • Deep knowledge of Postgres. How and why?
  • Questions on HomeAssistant repo. IoT/embedded?
  • Commits to serverless.

Candidate is not an enemy, but the decision is NO by default!

Does it seems strange or feels wrong?

It would allow you to focus on “Why should we hire him/her?”. Makes you a teammate/friend in this interview process. You have an hour or two to find reasons for a job offer.

Interview

Pt1. [Greeting]

Introduce realistic tech summary.

We are doing a BigData AI-driven tool that helps people address issues and solve isseues Annoying buzzwords.

I would prefer to hear:

  1. In general, CRUD, Queues, one place is high-loaded. Building new functionality on top. No specific requirements about consistency.
  2. App idea: { save time | increase efficiency | get insights } in { whatever field }.
  3. I’m { Role }, work on { tech | app }, interested in { tech… | petproject }.

Pt2. [knowledge & experience]

TL:DR: Keep it informal, like water-cooler coffee-machine talk.

Ask tricky questions? Hell no!

Asking technical questions do not help to evaluate the Candidate. You’ll end up with two useless answers for which knowledge you have in common and in which fields you are superior. Maybe it feels good to be better than someone, but it does not give any result. And the chance of offer refusal increases.

It would be nice to start with a fair line, like:

Now, we need to somehow evaluate your knowledge & experience. Since we have different backgrounds, I would instead focus on your stories, that questions from 1st page of Google. But let’s keep it technical :).

If the Candidate struggles to “sell himself” right off, you can help him start with prepared points of interest.

  • For example, I saw your commits into serverless. Seems like some deep sh*t. I’m curious, how did you end up doing it?

or more generic ones

  • What’s was the last or maybe most memorable bug that took days to fix, which ended up to be extremely simple.

  • Can you share with me some pitfalls when library/framework, database, or other software doesn’t work like documented.

    • Hav you figured out why? <– this one is about leaky abstractions and candidate curiosity
    • What was the workaround?

It’s okay to not understand the Candidate. There is a high chance that half of the information is beyond your knowledge. Be brave and Ask for details and learn new stuff. Make notes.

Keep track of time, and change subjects, to gather comprehensive insights.

Pt3. [post-mortem] [after-party]

Right after the interview, check any new information you just learned. And with a fresh memory and notes write feedback.

Curiosity is quite important. If you don’t stop after answering “How?” (to do it), but also seek “Why?” (it was made this way), You gain more insights. And since most of the knowledge is gained outside university, It’s important to learn during a job.

Some people do a job, without even understanding how and why it works, but do it fast. You can find people who would spend twice as time looking for a root cause.