At a previous job, one of my management mentors always took umbrage when someone asked me a question and my response was “I don’t care.” It took me a bit to understand that, when he heard me say that, he understood it as “this isn’t important, why are you bothering me?” He’d remind me that I did care about the results of the decision.
Thinking about it again recently, I started to clarify the situations where I use that phrase as shorthand for what I really mean.
I Don’t Have a Strong Preference
I’ll often see developers get locked in a heated, extended debate over the best way to implement some feature. Often times, when I’m asked to weigh in as the “tiebreaker” I’ll ask each person how much they care about the decision. If one person is passionate and the other is only playing devil’s advocate, the person who cares a lot should move forward with their idea.
I Trust You to Handle the Details
As a manager, I shouldn’t be making day-to-day decisions about implementation details. If I ask one of my directs to write a job posting, I’m not effectively delegating if I then nitpick their output or require them to ask me specific questions about every bullet point. That doesn’t mean I don’t review their work — I just remember to ask myself “is this important to change or just my preference” before asking for revisions.
I Don’t Own This Decision
There are times when someone will ask me my opinion on something and I don’t want to give an answer because it isn’t my decision to make. I want to avoid people later saying “but Jon said we should…” when in was only spitballing. An example might be the best way to design a user experience for our newest app. I’m happy to brainstorm with the team, but the product owner is the ultimate decision maker and should be present.
Communication is about the listener. Sometimes you might use a terse, flippant-sounding phrase as a shortcut for what you really mean. Take the time to articulate; people will appreciate the insight.
My team is always looking for ways to improve the interview process. We want to avoid the perils that come with whiteboard coding but still evaluate the candidate’s coding skills. Usually during the process, we come away with a clear “heck yeah!” or “no”. But occasionally we just can’t tell. After reading The One Method I’ve Used to Eliminate Bad Tech Hires, we decided to add a paid, take home exercise as part of the interview for these candidates.
We added this step last in the interview process. It seemed fairest to answer all the candidate’s questions about the company and the position before asking them to spend four hours (albeit paid) writing some code for us. Rather than trying to reinvent the wheel, we used the exercise from the article:
Create a single page app that lets me enter movies in my home movie collection, store them in offline storage and search through them. I want to search by Genre, Title & Actors.
We also made it clear to the candidate that we didn’t want them to force themselves to use the programming language, frameworks, or libraries that we do. We wanted to see their best work made with the tools they were comfortable with.
And for the first full year after we added this to our interview process, no one was able to complete the exercise and ultimately get hired. In most situations, they simply didn’t implement the functionality as requested. Other folks didn’t follow the technical requirements. One person went so far as to tell us that they couldn’t get their environment set up in four hours to even begin. We were starting to worry that the exercise was more flipism than anything else — we already knew we didn’t want to hire the candidate and were just using the exercise to back that up.
Then someone completed it.
Not only did they meet all the functional requirements, but they completed the “offline storage” technical piece in a way that it would be easy to refactor to use a database later. We hired them and they’ve quickly became a strong contributor to the team. They later asked what was the “trick” in the exercise because it seemed so simple.
There’s no trick. As I’ve previously discussed, some people have degrees or jobs in programming but simply can’t.
Back when I started interviewing, I read many articles including Jeff Atwood’s describing the now ubiquitous FizzBuzz. My team and I all thought it would be a good thing to add to our interviews because the truth is always in the code, right?
I’ll be honest, the first ten or twenty times I asked a candidate to complete FizzBuzz during an interview, I felt sheepish about it. It seemed too easy and a bit like we were going through the motions. Sure, everyone has a slightly different approach and a few of them felt wrong, but everyone completed it. My colleagues and I began to question whether or not it was worth it. Were we learning anything about the candidates by having them complete it?
Then we ran into our first candidate that simply didn’t know where to start. He assured us that he understood the request but couldn’t see that a loop was the answer. And then it happened again. And again. The most notable example was from a candidate who was a referral. A member of our team recommended that we hire this person and yet they couldn’t complete FizzBuzz. We let the candidate take the code home and they ultimately still couldn’t send us a working example.
I’ve always tried to give people the benefit of the doubt in terms of nerves during an interview. This has grown into my general disdain of whiteboard programming. On a day to day basis, we all have time to consider a problem, write some throwaway code, Google a few ideas, and then implement a working solution. All without being judged every step of the way. This is why my current hiring process involves a small take-home coding exercise instead. It isn’t much more complicated than FizzBuzz and yet it continually manages to filter people out.
I highly recommend you include something like1 FizzBuzz in your technical interview process. It will be easy for most people. But when it filters someone out, you’ll be happy to have spent a few minutes up front.
1. FizzBuzz is too well-known now. I’ve had candidates tell me they learned it in school as part of interview prep. Additionally, if you use a popular example like Uncle Bob’s bowling kata, you’ll find that people will submit code copy and pasted from GitHub. Instead, write your own exercise and test it with members of your team. Code Golf is a good place to find inspiration.