I’m in a bit of a situation. I have about 3 years of experience in data science and machine learning, but I’ve ended up being the most experienced person in my team. Now, I have to plan and lead the interviews to hire a team lead for us. How do I make sure I’m doing my best, especially considering the skill gap between me and those I’ll be interviewing? Should I include system design questions, even if I might not fully understand some of the answers or miss things that a more experienced person would catch?
Oral technical exams aren’t a great interview method and honestly should be phased out from tech company culture, so the fact that you might struggle with them isn’t a big deal.
There are really two main areas to cover: what the candidate has done before, and what they could do for your team in the future. Even if you aren’t an expert, your curiosity will help you out. Think of how a child keeps asking “why” about everything; if you ask with enough curiosity, you can dig into their resume and projects. It’s fine if you don’t understand every detail—just ask them to explain more.
This type of conversation is also useful when discussing the actual work they’ll be doing in your company. Treat it like a real chat you’d have with a future coworker, using their experience to guide the discussion. This helps you gauge their skills, and it’ll also show if they have good interpersonal skills.
And to me, that’s the key. If you have to choose between a super-skilled person who struggles with communication, and someone with solid but average skills who’s great at working with people, pick the latter every time.
@Hart
Just curious, if we move away from oral exams, what would you suggest instead? Serious question. I always thought interviews would be like a resume review, but maybe there’s more to it?
Zyan said:
@Hart
Just curious, if we move away from oral exams, what would you suggest instead? Serious question. I always thought interviews would be like a resume review, but maybe there’s more to it?
By “oral exams,” I’m talking about those technical quiz-style questions with fixed answers that the interviewer knows, and the interviewee is expected to guess. The kind of thing you might find in a college test.
I’m all for discussions based on the candidate’s resume. These should be guided by curiosity and the desire to really understand their skills and experiences. If someone is good enough to be hiring others, they should be able to assess skills in this kind of conversation.
It’s also worth having an open-ended talk about your company’s current projects and needs. It’s a great way to see how they’d approach real problems and collaborate on solutions. It’s not as straightforward as a resume review, though—it requires a bit of tact to keep the conversation from feeling like a test.
That’s a tough spot to be in. You’ll want someone who’s not only technically sound but also has good mentoring skills. You might consider getting a respected manager from another department to join the interview and focus on the mentorship aspect. Like DGW mentioned, interpersonal skills often matter more than technical skills.
I like to ask about past projects because it’s more grounded and gives insight into how they handle real-world scenarios. The downside is it can be harder to compare candidates unless you’re experienced with this interview style.
If you decide to do a systems design interview, go for something simple—like the systems design version of a basic coding problem. The aim would be to quickly filter out those who might be overstating their abilities. Then, you can dive into other topics. Just remember, this will mainly help you catch candidates who aren’t being honest but won’t necessarily help differentiate between those who are genuinely skilled.
And keep in mind, you won’t catch every bad hire. The hiring process is just about improving your odds of finding the right person and minimizing the chances of bringing on the wrong one.