I’ve been an Android user since the original Motorola Droid was released back in 2009. However, last month I finally broke down and made the switch to iOS.
I didn’t buy new, though. Because I don’t like big phones, I found myself a refurbished iPhone 13 Mini. It’s perfect. Sure do wish Apple would acknowledge the ongoing market for small devices, but it seems they’re well and truly dead. Maybe I should get a second Mini as a backup, especially since I’m case-free?
We’re all pretty big Lord of the Rings fans in our house, both books and movies. A few months ago we rewatched Return of the King, and I was struck by a couple moments in the dénouement that are worth talking about.
The first is one I’ve loved for a while. The hobbits have returned to the Shire and are together enjoying some well-deserved ales. Their reflective mood is in stark contrast to the conviviality around them, in particular one fellow who is showing off a massive pumpkin he’s grown. Our heroes don’t seem to mind the attention he’s getting; they’re content to sit in silence, apart from the crowd, with nothing more than a toast and some knowing glances.
No one else in that pub understands the grave danger they, and the whole of Middle-earth, were in. No expressions of thanks will come to Frodo, Sam, Merry, and Pippin. But that’s okay. It’s how it’s supposed to be. Leaders make the sacrifices so that those in their care can enjoy their pumpkins, and they seek not the credit. Fellowship amongst a small circle of friends who know the story is enough.
But even within that circle, there’s layers to the levels of awareness. It wasn’t until this most recent viewing that I realized that only Sam knows the full story: that Frodo had fallen at the last to the power of the ring, and its destruction was only completed through earlier mercy shown to Gollum, and some luck.
What Sam chooses to do with this knowledge is worthy of especial praise. When the fellowship is reunited in Rivendell, joy and celebration surround Frodo. Even the wizard Gandalf smiles in approval. Sam is late to the party, but catches Frodo’s eye from across the room.
In that moment, I wonder if Frodo is briefly afraid that Sam will interrupt with a tale of how he had to carry Frodo the final stretch, and that Frodo essentially failed, claiming the ring as his own. It would be the truth. But Sam doesn’t do that, and his expression says he never will. It’s as if he said, “I know that you aren’t a perfect hero. That at the end you did things you’re not proud of, even to me. But you gave everything you had, and the job got done. That’s worth celebrating. Fear not, my friend. Some things are just between us.”
I’m not sure if this is canon, but I imagine no one else, not even Gandalf, ever learned what really went down on the slopes of Mount Doom. That too is okay, because Middle-earth survives regardless. And that’s what ultimately matters.
Nothing thrills quite like launch day, and this time, it was nearly literal. It’s been a privilege to have been involved in this work, and fun that I can (finally) talk about it in public. I mean, when it’s on the news that’s gotta mean something right? You can check it out right here if you’re so inclined.
Hopefully the above partly explains why I’ve been pretty quiet here. As I said last month: crunch time. It’s certainly not for lack of ideas; sitting on 95 draft posts as I type. Someday I’ll get through the backlog. Or not. But it’ll be okay regardless.
I don’t use that title lightly. Not sure how I’ve never heard of git worktrees before, but I’ll definitely be giving them a spin.
Speaking of git, I don’t normally do a lot of coding in my day job, but crunch time is crunch time:
If nothing else, it’s cathartic to stretch those muscles.
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.
Amen and amen. Intellect is great, and willpower is helpful, but what fuels anything truly worth doing is emotion. It’s not an accident that a particular emotion tops my company’s list of guiding principles.
My Gmail account turned 20 years old today:
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.
I’ve done technical interviewing for more than 10 years now. And apparently I write about it a lot:
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 spent 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 to hear 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.
A great example of “you don’t know until you know” is being responsible for hiring. It’s a non-trivial task, hard to get right, and absolutely essential to running a successful organization.
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.
I’m curious what sort of email templating mixup resulted in this beauty I received today. Probably some combo of Left Hand, Meet Right Hand and Slip Of The Finger.
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.
