A common rhythm of my career is to catch-up on emails over the weekend. I’ve been appreciative of scheduled send, so that folks don’t get an email from me during non-working hours and assume they need to respond immediately.
However, this might be a new record: 14 emails queued up to go out first thing Monday.
That total may go up depending on how much progress I make on one additional task, which subsequently depends on what Olympic events are on TV this afternoon.
I get that weekend work isn’t for everyone, but I don’t mind it. It’s quiet. Usually no new tasks come up, so I can meaningfully shorten the queue. And finally, it helps alleviate pressure during the week. I’m much more comfortable signing off for the day come Friday afternoon knowing I can knock out a few lingering tasks before Monday ramps up.
Add this post to the cacophony, I guess. Today I want to cover a number of common interview mistakes, and approaches both interviewees and interviewers can take to mitigate them. That’s right, it’s a both/and responsibility. I know there have been times I’ve come to an interview unprepared to give the candidate my best, and the result was possibly missing out on a good hire. Don’t do that.
Mistake 1: Regurgitating resume content
As an interviewee, if you’re asked to introduce yourself, give an overview of your background, or describe the projects you’ve worked on, be sure to bring something unique to your answer beyond what’s on your resume. Otherwise you’re just wasting time that’s better spend on other topics. One idea: have an elevator pitch for yourself.
And interviewers? Avoid this by 1) reviewing the candidate’s resume ahead of time, so you don’t feel the need to ask for an overview, 2) gently interrupting if an answer veers into rote regurgitation, or 3) avoid these kinds of questions altogether. Better to just jump into the meat of the conversation, because interview time is precious. Speaking of…
Mistake 2: Wasting too much time giving introductions
While there’s value in easing into a conversation that’s high-stakes, it does no one any favors if a big chunk of time is spent on introductions that are not data-rich. That goes both for the interviewee and the interviewer. When I led interviews at Amazon I had a script so that I could get through my boilerplate in a crisp 60 seconds. Say hello, set some ground rules, describe the objective of the interview, and then jump in.
Mistake 3: Too much “we” and not enough “I”
Interviews are not the time for false humility. We know doing anything of reasonable complexity requires a team, but what was your role specifically? It’s easy to fall into this trap; if you’re giving the interview, don’t let your candidate go too long before redirecting them to talk more about themselves. If they struggle to give details about their own actions, that’s a concern! Closely related to this next mistake:
Mistake 4: Talking in generalities
This is a fatal mistake of which I’ve written before. Twice. Seriously, tell real stories that actually happened. As an interviewee, this is where preparation is key. Stories are much easier to tell when you’ve captured the details ahead of time. The sorts of behaviors employers are going to ask about aren’t rocket science (unless you’re interviewing for NASA, I suppose). Do a bit of research on the company’s values and prep stories that align to them.
As an interviewer, this is another case where’s it’s totally okay to interrupt and redirect if you think a candidate is drifting into theory. But help them along by phrasing questions effectively (i.e. “tell me about a time when…”) and perhaps even setting expectations in your intro that you want real examples. If you actually do care about a theoretical answer, say so explicitly.
Mistake 5: Telling the same story twice
Good interview teams are going to talk about the stories they heard during a debrief, so there’s no reason to tell the same story to two different interviewers. This gets easier if you’ve done your prep work. At absolute worst, if a story is rich enough to answer multiple questions, make sure you tell it from different angles.
And interviewers, coordinate ahead of time on the questions you’re going to ask. It’s a waste of time for there to be duplication between interview sessions. It’s a completely avoidable but all too common error that doesn’t speak well of your company when it happens.
Mistake 6: Telling stories not aligned to the level of the role
Candidates should understand the requirements of the role, especially as it relates to the degree of seniority, and be able to give examples that illustrate the required complexity and significance. If you’re asked about a time you failed, and you’re interviewing for a leadership role, you better be able to share a situation that involved real consequences. And if you’re aiming to be a senior engineer, I need tohear about more than just the cool code you wrote… how did you lead?
Interviewers, you need to be familiar with expectations for the role as well, so you can identify these “weaksauce stories” when you hear them. Sometimes follow-up questions can save them, but often I find that it’s better to step in and ask if the candidate has another example.
My favorite way to suss out the significance of a story is to ask a candidate about the people they were talking to at the time: only other engineers at their level? Related roles like product managers or salespeople? Managers? Directors? What about people outside their company, were they interacting with customers directly? Vendors? Other stakeholders? Answers to these questions will tell you a lot about where a person fit in their prior organizations and if they’ll be suited for the role you’re offering.
Mistake 7: Focusing too much on technology
Obviously having the technical skills required of the role is important, but just as critical is the leadership you show in applying those skills. So be sure to talk about those parts of the job too. Keep your stories balanced.
Interviewers also have responsibility here, to keep the questions they ask balanced between technical and behavioral. Amazon did a great job of this; in my experience they put more weight on behaviors aligned to their Leadership Principles during their interviews than any other tech company. Having done over 150 interviews during my tenure there (about half as a Bar Raiser), it’s a lesson I won’t soon forget.
Mistake 8: Failing to discuss results
I love the STAR method for structuring stories: Situation, Task, Action, Result. But each of these parts of the story are not equally important: they grow in significance from left to right. Results are the most critical parts of a story to tell, so make sure you don’t spend too much time describing the situation alone. What was the outcome? If you can share specific numbers, even better (you did prepare your stories, right?)
Interviewers can easily help their candidates here by always asking about results if they’re not shared proactively. Don’t commit this next common error:
Mistake 9: Rushing too quickly to the next question
Stories have layers; take the time to dig into them (10 minutes per story is my rule of thumb) with good follow-ups before moving on to your next prepared question. Sometimes the perfect follow-up emerges organically, but if it doesn’t, keep these classics at the ready:
Also, don’t be afraid of a bit of silence to be sure the candidate is completely done with their story. In graduate school I was trained to pause for 8 full seconds, a practice I still use today. Especially don’t fill silence by doing the following:
Mistake 10: Leading the witness
Interviewers, keep your questions open-ended, and resist the urge to prompt candidates on the “correct” (from your perspective) answer. Let them give the answer they want to give, because that’s what you’re there to evaluate. I recognize this can be difficult, especially if a candidate is struggling; human nature is to want to help. Gentle nudges are okay, but it’s easy to give too much.
Full disclosure: I’m bad at this one. It goes against what are normally healthy collaborative impulses. At least be aware of the tendency. Speaking of fighting against otherwise healthy tendencies:
Mistake 11: Providing too much real-time feedback on answer quality
This last one might be controversial, but I stand by it. Candidates sometimes want to get feedback on how they’re doing, but doing so is tricky territory. For one, it’s not a good use of time. Second, off-the-cuff judgments on candidates are rarely as helpful as thoughtful consideration, so an answer given in real-time might not be a good one. Finally, you don’t want to give a false impression that you might have to go back on later if you decide not to proceed with them.
I’m not saying being completely stoic, nor am I saying not to give some gentle redirections if you’re not getting what you need (as I’ve said throughout this post), but if asked directly, keep judgments on answer quality to yourself. Depending on the situation, I either use some version of “I heard what I needed to” and move on, or ask a specific follow-up if I think there’s more to discover.
I’ve advocated for story points plenty of times, but I do see the article’s point. Estimation is hard. And I like the notion that in absence of other data, just having a count of tasks yet to be completed is a decent approximation of remaining work.
And perhaps it rightly centers the definition of the tasks themselves as the important part of estimation, versus the assignment of a numeric value to said tasks? A question well-asked is half-answered, or something like that?
It also made me think of a tension I’ve seen for much of my career. Product folks tend to think in terms of features and user outcomes. As they should, for outcomes is what ultimately matters to a customer. But estimating “features” is a fool’s errand. Engineers need to think in terms of tasks: add X, build Y, modify Z, etc. The latter are (generally) easier to estimate. And, as the article argues, if sufficiently broken down, don’t really need to be estimated at all, just counted.
Making the above work, though, requires that engineers own that translation of user stories to tasks (and consequent planning thereof). That takes work, no doubt, but probably less work in the long-run than arguing about numbers.
While his material is worth reading for anyone in the software industry, Ryan Peterman’s work is especially valuable for mid-level developers looking to take that next step. The Tech Lead’s Playbook, for example, captured the responsibilities better than my own thoughts despite being half the length.
He jumped 3 levels in 3 years at Meta, which is an insanely-fast series of promotions. He knows what he’s talking about! That being said, I bet it took a decent amount of luck too, so don’t expect similar results even if you follow his advice perfectly.
Common leadership advice is to avoid making failure out to be a bad thing. “Failure is good,” well meaning folks will say. They’re not completely wrong, but they’re not absolutely right either.
Failure can only be good in moderation. Of course repeated failure of the same kind is bad. Absolutely learn from mistakes so they’re not repeated. But continually making new kinds of failure isn’t great either. No endeavor, professional or personal, can sustain that.
Eventually there need to be successes to offset the setbacks. So I’m not keen on over-celebrating failures, or treating failure as something that ought not have consequences. Maybe in the case of this CrowdStrike fiasco no one deserves to take the blame? But I doubt it.
While it’s not an absolute guarantee, there are a few ways to get my attention when applying for an open role for which I’m responsible.
First, read the job description and the minimum requirements. If you don’t meet them but want to take a chance anyways, don’t shy away from where you fall short. Address any gaps head-on in your cover letter and how you can mitigate.
Speaking of a cover letter, you should absolutely write one. Yes, actual you, not an LLM. I value engineers who can communicate effectively, especially in writing, given the realities of remote work. This isn’t about nitpicking spelling or grammar (though in 2024 there’s little excuse for stumbles here, given the tooling available), nor is it about quantity. It’s about concisely communicating what you value in a job and what excites you about the role enough to apply.
When describing what you value, show don’t tell. I love to see an example of work you’re proud of in a cover letter, because the way you discuss what’s important really matters: are you enamored with technology as an end in itself, or do you value impact on a customer? And what kind of impact do you value?
Finally, be sure to follow the instructions in the application process. Employers may have specific reasons for their requests; deviation does you no favors. For example, RIPL asks for an email to a specific address that goes to a shared inbox. If you send your info directly to an individual it might be missed. And if you DM me in LinkedIn instead, well, I get a lot of DMs, so don’t expect a response.
Look, I remember what it’s like to be on the other side of this equation. Reaching out to anyone who will listen. Sending your resume far and wide. Waiting. So much waiting. It sucks, no question about it.
But right now, with so many technical professionals on the job market, it’s been a little overwhelming to sort through all the interest in open roles, especially for an organization that’s not big enough for professional recruiters. I like to think I’m a pretty responsive guy, but it’s simply impossible to review and respond to every single email and LinkedIn message, let alone include personalized details about exactly why we made the decision we did.
I wish the above weren’t true, but it is. And I’m not willing to “solve” it by handing the reins over to AI. At least not yet, because hiring is not a formula. Like much else, it’s a human process, and in general, everyone is doing their best.
