Just finished Marianna Bellotti’s excellent Kill It with Fire (thanks Kate for the recommendation!) If you do any work with legacy systems, give it a read post haste. You’ll be equal parts informed and inspired.
This quote jumped out at me in particular:
Feedback loops are most effective when the operator feels the impact, rather than just hearing about it.
I’m fairly certain it’s the only technology, hardware or software, that I’ve used continuously over that time period. That’s an impressive accomplishment; tip of the hat to the Gmail team. May we all be so fortunate in our endeavors to build something that lasts.
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.
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.
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.
The real task that requires immediate attention is for someone to do more testing of their notification system. I appreciate the chuckle AAA, but c’mon, you can do better.
It may not seem like much, but you never know the lives you touch just by always showing up, even on the days you feel so small. Turns out it all matters after all.
– Derek Webb
Want an easy way to be perceived as good at your job? Set aggressive goals for being responsive across all your communication media, and especially strive to avoid failing to respond or missing messages altogether.
My own personal targets are the following:
Slack / Text: 5 minutes ideally, 1 hour median, never more than 24 hours
Email / Voicemail: 4 hours ideally, 24 hours median, never more than 3 days
Even just an “I got it, will have you a better response by X time” goes a long way (assuming of course that you do indeed follow-up). Liberal use of tools like reminders, snoozed messages, and do-not-disturb / notification settings make this achievable without completely giving up on work/life balance.
I call the approach “radical responsiveness”. In my experience, it’s a simple way to earn trust with colleagues and customers alike. It works across levels and roles, though it’s particularly helpful when being attentive is part of the job, like sales positions, and especially critical for people management. Be the boss that always responds quickly and your team will be imminently thankful.
Of course you won’t be able to meet these objectives 100% of the time, but being known as a responsive person 95% of the time usually means others will assume the best of you for the 5% of time you fail.
Never pass up an opportunity to express gratefulness, especially in the workplace. In my (almost) 45 years of life, I’ve never heard someone say “You say thanks too much, please tone it down.” Do it often, do it out loud, and do it in front of an audience.
That being said, the object of your expressed gratefulness matters. What you praise is what you encourage to happen more often. But the converse is true too, what you don’t praise you will discourage. And if your praise for a person’s work is disproportionately towards things less important to their job, you may be having the side effect of making them feel they aren’t actually doing a good job with the things that do matter.
Of course, that may literally be true. You may be using praise of the inconsequential as a defense mechanism to avoid hard feedback of what is consequential. Or you may not be. But if your praise quotient is out of alignment, the individual you’re praising will have to guess. And that ambiguity can be disheartening.
Today’s cautionary reminder to know your audience is something of a sequel to Left Hand, Meet Right Hand. It involves a cold email from a recruiter I got two days ago. Which isn’t a rare occurrence by any means, but what was out of the ordinary was that 1) it was from my former employer, despite there being absolutely no indication the sender realized I was a recent ex-Amazonian, and 2) the jobs being offered were at or below the level I’d been hired at back in 2019, a full five years ago. Needless to say, I’m not interested (and I’m not just saying that because my current boss sometimes reads this blog).
Look, I recognize that this email was probably auto-generated from a LinkedIn search, but it’s a recruiter’s entire job to not only find, but adequately entice, qualified candidates. The poor person was hoist on their own petard with the boilerplate about “raising the bar” and “becoming an industry leader.” Failing to do even a modicum of homework is not frugal nor customer obsessed.
It’s not like it would be that hard. Even if the automation was solely LinkedIn based, my entire work history is right there and it’s pretty obvious I haven’t been a mid-level software engineer in ten years. But an Amazon employee could easily do even better, given that there’s robust internal tooling for querying data on current and past employees. I should know, because I wrote some of it. In fact, from memory I bet I could write a Python script that could cross check a list of potential job candidates against Amazon’s employee lists.
Thanks for the chuckle, my recruiter friend. But do better. Open up your browser, go to https://<redacted_wiki_domain>.com/view/Jud_Neer and you’ll find all the resources and documentation you need to avoid this error in the future.
I’m sure there’s research out there that says people do better work when they’re happy. But anecdotally, it’s an obvious truth. Of course there are limits (“fun with respect to work” will almost always be “work with respect to fun”). But in general, fostering a positive work environment and encouraging employees to take care of themselves is good business.
Last week a colleague of mine was revising the spreadsheet we use for high-level estimation, and as part of her adjustments added a few splashes of color. The highlights had a functional purpose, yes, but they were also simply more pleasant to look at. It made me want to work on the spreadsheet at a subconscious level.
Isn’t that nice? I suppose the 49″ ultrawide monitor doesn’t hurt either. 😛
Another obvious example of this phenomenon is font quality and syntax highlighting. Take a look at the following “identical” code samples; which one would you rather work with?
Literally as I was drafting this blog I learned about Monaspace. Taking code aesthetics to the next level, I dig it. Describing the process of adjusting glyph widths as “texture healing” is an especially humanizing touch. Happiness matters!
