This content originally appeared on Level Up Coding - Medium and was authored by Jimmy Ho
The biggest mistake I see as a veteran tech interviewer
I’ve been doing behavioral interviews at Yelp for five years now, and one consistent mistake I’ve seen in this style of interview is when candidates get too technical.
I know, I know! Like, what are engineering interviews for but to test your technical expertise, right?!
Well, yes, and there’s space for that in other interviews, but a behavioral interview is not about solving coding or technical design problems or proving your knowledge. We’re much more interested in teamwork, ownership, business insight, resilience in the face of adversity, and other skills of that nature.
While we definitely want people who can write working production code and design robust systems, no amount of technical virtuosity will help you get hired if we aren’t confident in your communication skills or ability to work with others.
It’s Not About Deep Knowledge or Expertise
For our behavioral interviews, literally nothing about technical expertise is in our instructions to candidates or grading rubric. We’re not trying to evaluate if you’re a Python expert or know AWS inside and out.
We definitely want to know about your “technical skills,” but it’s more about your ability to make tradeoffs between deadlines and technical debt, or knowing the importance of production monitoring, for instance.
Sure, when talking of your experiences, go into enough technical depth to convince us that you’re actually a software engineer, not a fraud. But you don’t need to go deep, deep, deep into a technical topic.
Lastly, your interviewer may not even be in your exact field, so we might not be able to verify your statements anyway. Since we aren’t planning on evaluating how well you know a specific technical subject, it makes sense that you don’t usually get an interviewer who aligns precisely with your skill set.
Examples
Let’s say I ask you to discuss a technical challenge you faced at a prior job.
Example 1 — Unnecessarily proving your expertise
This is a typical response I might get from a candidate (and I’ll compassionately cut them off at some point because the answer isn’t helpful):
The team installed a new Framework that caused crashes in the iOS app … some long digression into framework geekery, listing every tradeoff of dynamic versus static frameworks … runtime consequences if not done right … anyway, we fixed it by auditing the environment variables … list every, laborious step to fix said environment variables.
:: sigh ::
This kind of answer only tells me that you might have a lot of knowledge about a particular domain. But, as I mentioned above, this is not what we’re evaluating at my company in these types of interviews. You’re not “scoring any points,” so to speak.
Of course, you need to provide technical details to set up your story, but you should give only enough information to prove to me that you didn’t make up the story. Structure your answers so that any ‘generic software engineer’ with any cultural and school background can understand. And for the love of god, don’t overdo the jargon.
Let’s look at some better examples.
Example 2: The well-rounded engineer
The team installed a new Framework that increased crashes in the iOS app… just enough details about the problem and resolution to prove to me that you didn’t make up the story… I’m so grateful we had production crash monitoring in place, and I volunteered to make it even better… however, we should have caught it sooner; I updated our app store deployment runbook to double-check this part until we put in automated checks for the long term.
This tells me that you:
- Understand the importance of production monitoring and automated tests
- Feel a strong sense of ownership because you volunteered to improve production observability
- Know how to make team- or org-wide engineering improvements via changing processes
- Have a mindset of wanting to continually improve things.
Example 3: Another well-rounded engineer
The team installed a new Framework that increased crashes in the iOS app by 100x!… just enough details about the problem to prove to me that you didn’t make up the story… realized it was an emergency and organized everyone into a Slack channel to coordinate the response… paged the right experts, kept discussion on track… kept higher management updated at regular intervals… fixed the problem (environment variables! Gah!), volunteered to write the lessons learned doc to avoid future incidents.
This shows me that you:
- Have leadership skills and a strong sense of ownership
- Can keep cool in a crisis
- Have experience communicating with non-engineers (higher management, in this case)
- Know to document learnings to prevent future incidents
Example 4: New to the industry (e.g., college hire)
This example is for those of you with limited industry experience. Let’s say you did a large group coding project in school or at a boot camp:
School project, team of 4 students… just enough background info to prove to me that you’re not making this up… clearly articulates success criteria… clearly articulates division of labor and coordination between team members… OMG, the bugs! I invented a good mini-bug triaging process, though… “Guys… GUYS! Why are we arguing about variable naming?! This is due in two hours!!”… we got only a B-, mostly because of me, but we discussed what went wrong and got an A on the next group assignment!
From this, I understand that you:
- Know how to be accountable for the work through knowing exactly what needs to be done and by whom
- Can work in a team
- Know how to prioritize and have the leadership skills to keep a team on task
- Own your mistakes, be resilient, and know how to reflect on your shortcomings and continually improve.
Additional notes on these examples
In all the examples above, I’m giving unrealistically long answers to pack in a lot of example insights. In practice, it’s okay if your answers are much shorter and don’t “check as many boxes.”
When I say, “just enough details to prove to me that you’re not making this up,” lean towards keeping it short. You risk wasting valuable interview time (and frustrating or boring the interviewer) if you give lots of extraneous information.
Your interviewer will ask follow-up questions if they want more information about any of the above.
Maybe They Do Want Expertise?
I personally think that behavioral interviews in our industry are generally about all aspects of a software engineer except coding, technical design, and deep technical expertise. That said, all this is much more art than science. You may encounter interviews out there labeled “behavioral,” where they do indeed evaluate your expertise in a specific area as part of the interview. In that case, the signs may include the following:
- The recruiter explicitly tells you they’ll evaluate your expertise on that specific thing.
- Your interviewer is clearly an expert in that specific thing.
- You’re asked specific, probing questions about that specific thing.
Finally, many companies combine behavioral elements with coding/design elements in a single interview, often out of efficiency. Adjust accordingly.
Conclusion
When I give behavioral interviews, I want to know that you understand how to be a software engineer beyond just being handed a Jira ticket and writing some code.
Let go of proving yourself as an expert in [insert tech stack/tool/language here].
Instead, sell yourself as a well-rounded engineer who’s passionate about engineering.
Feel free to drop a comment if you’ve had related experiences!
Good luck!
Please check out my other related articles:
- Think Before You Speak: How To Improve Your Behavioral Interviews
- Want To Ace That Tech Job Interview? Please, Please Explain Your Jargon!
Disclosure: Yelp reviewed this article before publication. That said, I was not paid or solicited by Yelp to write this article, and the opinions expressed are my own.
Want To Improve Your Behavioral Interviews in Tech? Be Less Technical was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Jimmy Ho
Jimmy Ho | Sciencx (2025-02-10T14:03:47+00:00) Want To Improve Your Behavioral Interviews in Tech? Be Less Technical. Retrieved from https://www.scien.cx/2025/02/10/want-to-improve-your-behavioral-interviews-in-tech-be-less-technical/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.