Start a discussion.
- How do you usually prepare?
- How do you make decisions around the candidates?
- What’s the most complicated for you in this process?
2 Likes
When I did tech interview as interviewer, we did take home task. I would check out the project, run it and analyse. Write down good and not so good approaches, write down questions I wanted to clarify on the follow up tech interview. I could search the candidate to see their experience and contribution, but at the time it would not influence decision that much as potentially it does today.
To make a decision we have some scoring system and template to help us out place our evaluations. It would go around principles, design patterns, architecture and how clean, clear the code was, scalability, how easy anyone can run it, does it have a good readme file, naming conventions, etc. Based on those areas we can evaluate the candidate against competencies for role seniority. We also looked at how candidate was technically engaging, their knowledge, critical thinking and collaboration. We wrote extensive technical feedback with specific examples and potential suggestion for improvements if applicable. That feedback was meant to be ready to be sent to a candidate, not only having it internally. We were trained to recognise and avoid biases, personal judgments, our personal preferences. I always run interview with someone else for diverse feedback, but we were discouraged to discuss interview in private on Slack not to influence each other decisions. Later on, all interviewers would vote in person and final interview decisions would be made on number of positive or negative votes.
The most complicated part not to fall into bias, be fair, be completely present on the interview in between busy days, context switching. But so far unconscious (or any) bias, is my most tricky one. You have to work on your self-awareness all the time.
I do not have direct tips. The more you practice, the faster you figure your way. Ask for training if there is a chance. Ask if you can be a listener when someone runs an interview. Always prepare, spend time deliberately reading assignments, writing notes or questions, run mock interview with colleagues or community people. Read, learn about biases and how to recognise them. Do interview with someone else. We were always 2 people.
2 Likes
Thank you for such a thoughtful breakdown 
I strongly relate to what you said about scoring systems and written feedback. For me, having a framework reduces emotional or “gut-feeling” decisions and makes the conversation much fairer.
The bias part is probably the hardest one. Staying present, switching context between daily work and interviews, and still being objective takes conscious effort.
Recently, I actually built a small GPT-based assistant to help me prepare interviews more structurally. It doesn’t replace judgment, but it helps with:
-
generating role-specific technical questions
-
aligning them with the project context
-
mapping questions to competencies instead of random theory checks
It was born exactly from the need you described , to make interviews more consistent and less intuition-driven. Still evolving it, but it’s already helping me prepare faster and more systematically.
Also, speaking about training, I realised there’s rarely a safe space to learn how to interview.
I never had the chance to observe real interviews when I was growing into a lead role. I learned by doing alone, and I always wished I could see how experienced interviewers actually run the conversation (not polished YouTube versions).
So now I invite colleagues who are interested in growing as managers or tech leads to join my interviews as observers. It gives them real exposure, practical examples, and a better understanding of how decisions are made. And sometimes I can even get feedback from them 
Still evolving the process, but combining structure, shared evaluation, and small AI assistance is helping make it more mature and transparent.
Recruiting the right person in my opinion is a mix of objective and subjective assessment that I embrace. I welcome the fact that, there is a risk I will get it wrong. It is so much more than skills in my opinion, especially if you are building a high performing team. That gets more and more complex the bigger the team gets. So here’s my thoughts:
- How do I usually prepare?
- Be clear what type of person you need to add to the team and what type of person the team needs to raise the level.
- Be clear what their day to day will be and what they will be working on.
- Think about what exercise you would for them to prove it that most importantly is realistic to how they will be working your team
- What will be your interview structure? Be clear of the objective of each interview?
- Be aware of the mistakes you can make and mitigate against them. My most common one is if I’ve been struggling to fill a role and someone comes along with the skills and think “they’ll do”. That will usually backfire.
- How do I make decisions on the candidates?
- We talk through the candidates as a team and come to a collective decision. We’ve already talked about what we need as a team and I find we work hard as a team to give new starters the best onboarding experience possible as a result.
- Whats the most complicated part of the process?
- The initial candidate selection. CV’s in my opinion are a lousy tool to communicate about a candidate. Alas, that is still to tool that we have to use. I have no doubt that I have rejected brilliant candidates because their CV was a mundane tick sheet of skills
Hope that helps a little 
2 Likes
I really like your point about embracing the risk of getting it wrong. Hiring is never purely objective, even when we try to structure it.
The part about being clear who you actually need in the team resonated with me the most. I’ve made the mistake before of focusing too much on “skills match” and not enough on team context and growth impact.
Your comment about interview structure is also key. I’ve noticed that the clearer the objective of each stage is, the fairer and more focused the discussion becomes.
And I completely agree about CVs. They’re often a very poor signal. Some of the strongest engineers I’ve worked with would never “win” on paper.
Thanks for sharing such a structured view , this is the kind of thinking that actually improves hiring quality over time.
1 Like
I try to ask questions that get the interviewee to provide examples of their experience. Too often, the response can be stuff read from a book etc that can make them sound knowledgeable but they don’t have hands on experience.