Category: Practices

In the technology space, the allowing remote work has become default — you’re going to stand out if you don’t allow it. Remote work simply needs to be on the table for you to hire the best people. And allowing the flexibility provides huge payback: the benefits are well documented.
What I’ve learned in my current role is that remarkably simple tweaks can completely change the remote experience. It really comes from a simple rule that I can claim no credit for whatsoever:

whenever someone is remote, we treat all meetings as if everyone is remote.

This results in an office that sometimes looks a bit silly, as two engineers sitting next to each other might have a conversation back and forth while staring at their screens and wearing headphones, but the impact is enormous. We’re not allowing remote work, we’re finding ways to make remote work no barrier to working and communicating effectively.
The practice for the team has been to notify everyone on our team slack channel at some point in the morning when you’re working from home (if that’s not your default). No need to check in advance, just let us know. In fact, there are many people on the team who let everyone know in the same channel when they’re in the office. The early morning conversation is largely “WFH” or “WFO” posts.
Although there are some reasons that working remotely is difficult for me personally (mostly that I have pre-school-aged twins) I’ve found now when I work from home I’m able to communicate and collaborate just as effectively as I can from the office. Sure there are some exceptions — meetings with other teams is a big one — but overall, I’ve found that working from home is suddenly easy as a leader — I don’t have to cancel or move meetings or 1:1s around. Even if I was in the office, there’s a good chance that anyone else in a given meeting will be remote. And I’ve started to discover that there are certain types of work (catching up on email, bureaucratic tasks, writing or preparing presentations) that work much better for me when I’m at home, even with the twins periodically stopping in to see what I’m up to.
I’m reasonably sure that there are other simple tweaks that can help just as much, and I’ll keep looking for them. What works for your team?

n.b.While I would imagine a good bit of this applies outside of the realm of interviewing software engineers, what follows is specifically written about software interviews. If you’re looking about other types of interviews, read on, but, proceed with caution.

I’ve had positions open under me for pretty much all of my career as a technical manager. And so I’ve spent a lot of time interviewing, and given a recent focus on hiring a more diverse team, a lot of time thinking about interviewing. And what I’ve become more and more convinced over time is that no one (really, no one) is good at interviewing. Sure, lots of us point to the teams that we work with and say, “Look at all these amazing people! We must be doing something right.” And that’s probably true, but I’m reasonably sure that the thing we’re doing well is not interviewing. Even more terrifyingly, as I’ve looked at it closely, I’ve become convinced that it is not possible to do well.
Does that sound crazy? I don’t think it is — under the very best conditions as an interviewer, you can only ever have one side of the story. If you should be so lucky over a long career of hiring to hire no one that you view as a mistake on any level, that’s fantastic (if somewhat improbable), but also only tells you 1/2 of the story. Have you ever been talking with someone who was doing really well in the interview process, only to suddenly choke and bomb a segment of it — eliminating themselves from consideration? Do you think that was a fair representation of their skills? Have you ever interviewed someone and wondered at their evident career success v. their inability to perform the simplest tasks in an interview? Sure, some of those folks may have completely misleading resumes; but I’ll bet more than one of them simply choked under the pressure, and your assessment told you that they were no good.
And why is that? How good is your assessment? Let’s take a look at a few common tech interview gotos.

• Whiteboard coding has taken a well deserved beating over the past few years, but that’s only a sample of the awful things we do.
• Stupid questions. What do you expect to learn by asking someone how they would keep from being eaten if they were a cucumber in a salad? Or how they would escape from a blender if miniaturized? Do these questions tell you anything about a candidate? Is this an ice-breaker? Do you expect these questions to put a candidate at ease? Puh-lease! Best case scenario, they give an interviewer an opportunity to feel smug. That’s not going to help anyone.
• FizzBuzz and other well-known interview problems. Congratulations, you’ve just learned that your candidate can memorize some stupid code from a programming interview questions web site. Do you know if they can actually code? This category of simple question may have some value as a screening question, but I’m unconvinced it tells you anything you need to know on an on-site. And if you find yourself questioning whether someone who struggled a bit with FizzBuzz is worth hiring, because the last 3 candidates aced it in seconds, shame on you. You’ve got one candidate who just thought on their feet and got where they needed to be against 3 who read one of the 892 books that currently come up when you search for “programming interview” on Amazon.
• Have you ever been in a good panel interview (on either side of the hiring equation)? I’m pretty sure it would be possible to prove the exponential relationship between the number of people interviewing and the terribleness of the interview. Add 3 interviewers to an interview, and at least one of them will get distracted by their laptop or mobile. Four? Then you’ll have at least two with a conflicting agenda. Five? Someone’s going to start monologuing (and everyone else will check out). Your focus quickly becomes about group dynamics, rather than the candidate. Meanwhile, you’ve wasted a significant chunk of multiple peoples’ time and increased the stress on your candidate. Are you testing for endurance?
• Pair programming? I’ve talked with a lot of strong advocates for this, but this technique can be a great way to eliminate anyone who hasn’t spent a lot of time pair programming. (Remember how uncomfortable it felt the first time you paired? And I’ll bet that wasn’t with the added pressure of being on an interview.) Also, as much as I just beat up panel interviews, having a second interviewer in the room brings a valuable second perspective to the table, and there’s just not much room for a 3rd in pair programming. If you’re not looking for someone bringing a specific language skill to the table, this can get even more complicated — you might have to switch interviewers depending on the candidate, and now you’re going to lose any reasonable chance of fair evaluation across a set of candidates.
• Looking for someone that “clicks” with the team? That’s a great idea, but it’s also almost impossible to make this an important factor without guaranteeing a monoculture. Are you looking to increase diversity on your team? (hint: you should be) Are you competing to hire in an increasingly candidate-friendly market? (hint: you are) Then you need to monitor this carefully. It’s also too prone to eliminating candidates who are too nervous to let their real personality through in an interview. (Relevant: how often have you let your real personality through in a job interview? )
• Post-interview analysis meetings. sigh Here’s an area where I’m especially ashamed of my own once-valued previous practice. My last team would wait until everyone was available, gather around an open section of floor, kick a soccer ball (oh, hai, rest of the world, that’s a football to you) back and forth, and discuss a recent candidate. Chances are, minus the soccer ball, you’ve done something similar. There are a few problems with this approach. First, by the time we all got together for that conversation, no one’s perspective was fresh. But the biggest problem with the let’s-all-get-together-and-make-a-decision approach is that the first member of the team to voice a strong opinion will generally carry the conversation. If you’re feeling slightly positive about a candidate, but the first person to speak says, “Oh, that candidate was terrible!” are you going to argue? What if everyone was reasonably positive except that first speaker? What if someone at the table has a very high opinion of the candidate but doesn’t like conflict? How will you know?

Given these practices, which have all been at least considered in the various iterations of my interviewing process, it’s not really surprising at all that I’m terrible at interviewing. And if you’re a hiring manager and somehow the logic of all of the above hasn’t convinced you (and honestly, even if it has), then you really, really need to go read Interviewing.io’s article on the arbitrary nature of tech interviews. Seriously, go read it. At the very least, scroll down to the interactive chart titled “Standard Dev vs. Mean of Interviewee Performance” and click around till you understand it.

Seriously, go do that.

Okay, back? “Only 25% of candidates are consistent in their performance.” I’d also like to take a brief digression to point out the realization that got me in this mess to start with:

The dark side of optimizing for high false negative rates, though, rears its head in the form of our current engineering hiring crisis. Do single interview instances, in their current incarnation, give enough signal? Or amidst so much demand for talent, are we turning away qualified people because we’re all looking at a large, volatile graph through a tiny keyhole?

With those horrifying, all too believable figures as context, go back and think about past interviews. I’ve definitely had the experience in the past of rejecting a candidate based on a teams opinion, while remaining somewhat sure that the team had eliminated someone with a tremendous amount of potential. I’ve also pushed back against a team decision to reject a candidate only to make one of the best hires of my career.
After thinking through all of the above, I came to what seemed like an obvious conclusion: I am terrible at interviewing. And given that the practices I’ve followed are widely accepted interview standards, I’m pretty sure the rest of the world could use some work on this too. In fact the only convincing evidence I’ve found that there’s a useful way to hire for actual skill in any field is a blind listening technique for orchestra members. I think there’s some interesting potential in applying more techniques like blind resume (or code) reviews, and I’d be in favor of experimenting with fully blind hiring. But unfortunately, I don’t think most organizations are ready for that yet.
So where does that leave us? Are we all just in an impossible situation with no hope? After all, I started thinking about this with hopes of identifying the best hiring process in the world and then implementing it and collecting all the benefits and privileges pertaining thereto. Instead, I’ve spent months staring at various revisions of this post with my head in my hands, wondering “what now?”
Here’s my conclusion, at least for now: hiring well is simply not possible yet. At least not for me.
Hiring better? That sounds like something I can work on. I’ve definitely got some ideas for that. Working with the candidates I hire through an imperfect process to help them realize their potential? Now for that, I’m definitely in.

Do you take the time to properly introduce yourself to new team members? I’d like to suggest that a simple practice can help set new team members at ease and let them quickly settle into their new jobs and start focusing on the work at hand.

Hopefully by now you should know the importance of creating an environment where your team can form not just professional relationships, but real friendships. As far as whether a leader should try to be friends with their team, there are arguments on both sides. I personally say that the power dynamic is not going to allow you to be close friends with your employees. This shouldn’t stop you from building a relationship of trust, support and openness that is, in many ways very similar to friendship.

I’ve stumbled onto a simple onboarding practice that helps kick-start that relationship. I’ve not met any other manager who does this, and I’ve received positive feedback from every employee I’ve subjected to this exercise. But before I get into it I’ll explain the two main factors that led to my doing this as I onboard employees.

First, an experience as an employee: I’ll change the details to protect the innocent, but the heart of this is a true story. I worked for a manager named (ahem, not his real name, see above) Charlie. In almost a year of working for Charlie, I managed to discern the following details of his personal life: he had served in the Navy, and his son fenced competitively (again, not actually true, but close enough to give you the idea). Yep. That’s all that I had to show for a year of reporting to him. As someone who knows nothing about fencing and has never served in any military branch, this is a remarkably thin bit of information on which I would try, and generally fail, to base a conversation when we were say, in an elevator together. (It would require an altogether different post to discuss the reasons that I let this happen, but for now I’ll sum it up under the category of “mistakes I have learned from”.)

Flash forward a few years, when I found myself inheriting an offshore team of 10 or so employees. I scheduled a trip to meet them in person, but I had one week and a lot to accomplish. I had to quickly get to know the team — well enough so that I could reasonably ask them to work with me on significant changes to the way they worked. In short I needed to show up in a foreign city, earn the trust of 10 people, and move on to solving problems, in less than one week. I knew that this had to start with a one-on-one conversation, where I could introduce myself and ask questions to get to know each member of the team. And I wanted them to know me, not to be in a position where they where trying to think of an interesting question about fencing. To shortcut this process I built a presentation introducing myself and the things that matter to me. Basically a slide show introducing myself, my family, my interests and a bit about my work history, approach etc. This let me get through the “me talking” part all up front, to the entire team, so that during my 1:1s, I could jump right into asking questions to get to know each member of the team during our time together. This in turn meant that by afternoon of day 2 of my visit the entire team could jump into real discussion about how we could work together.

A few weeks later, I found myself getting to know a new employee in my office. As I started to introduce myself and talk about my family, I realized I could use those same slides to show pictures of my family, and I called it up. And then a slide about my favorite books came up, and I answered a question about that, and before I knew it, I had gone through the presentation on a one on one basis. I’ve done it ever since. It’s a bit awkward, but it does actually help keep me focused, and time-boxes what would otherwise be a rambling monologue about myself. Of course that’s not the end of the conversation — it’s just as important for me to try to learn a bit about the person sitting at the other side of the desk, which generally involves some questions as we go, followed by “tell me something about yourself”.

So give it a try, and see if your new hires like it, then let me know in the comments!