Get a new job.

Listen, there are tons of blogs and articles out there with clickbaity titles promising you “Ten easy steps to survive a workaholic boss!” But I’m here to tell you that they’re all bullshit. You’re options are to: A) Get a new job at different company, or, B) Get a new job at the same company.

The point of this post isn’t to give you coping strategies, it’s to reassure you of what you already suspect – that old chestnut told to the family and friends of addicts is true. You can’t change other people. When those people are in charge of your career, it’s time to jump ship (or at least transfer to a different part of the crew).

Here are some assumptions: You, like me, are decidedly not a workaholic. If you are, you wouldn’t give a single shit about this advice, and probably curse those of us who do as “weak” or somehow less dedicated than you are. Of course you are correct. Workaholics are the best employees and managers. Please move on.

Now that we can speak freely, you may be wondering why my advice in this area is so black and white, when I’m normally a guy who sees things in many shades and colors. The short answer is that my opinion is borne of experience, having been supervised by workaholics many times in the past. I want to explain why I feel so strongly about this.

First, let’s talk about what a workaholic boss is. Not textbook definitions or anything, forget the psychology for now. Here are some signs that your manager lives, eats, and shits work, and expects you to do the same:

• Messages/calls at all hours of the day and night
• Does not respect weekends or planned vacations
• Views a regular workday as the bare minimum
• Every unit of work constitutes an emergency
• Consistently underestimates work and over-commits their team
• Lack of respect for personal space
• Disparages employees who can’t do unplanned weekend work due to previous plans

If you’ve found yourself nodding, or having flashbacks, while reading this list, then you know who you work for. I won’t go into detailed explanations of each bullet. If you read and feel it, then you know what I’m talking about.

Not every workaholic is a dickhead or a soulless monster. In fact, some of the worst offenders can be very personable. In a way, this is even more dangerous, as you find your life slowly being consumed by your employer. I know that sounds a bit dramatic, but hear me out for a minute.

Stop what you’re doing and take three deep breaths. Look around you and acknowledge a simple fact. You will never get this moment back. Time, once past, does not come again. You will never be as young as you are in this moment. Many of us in this field are young, or young-ish. I am middle-aged (shudder) and I can tell you for a fact that each year will fly by faster than the one before it. My friends have been dying off since I was a teenager, as have my family. You will never get this time back. You will never get your loved ones back once they are gone.

Don’t waste your precious fucking life on a goddamned job.

The company you work for does not care about you. They don’t. The larger the company, the truer this statement is. If you work for a small, ten-person startup, you and your team may genuinely care about each other. But as your company grows, new leadership will come, and they will not care. If you work for a mid-sized company with great benefits and an awesome culture, have no doubt that as the company expands, those benefits will get whittled away as the board of directors nickel and dime their way to a better share price. I don’t care where you work. You are an asset. You are a number. Treat your employment like the business arrangement it is. You employer sure as hell will.

Your boss is a workaholic for reasons known only to them. You won’t change their mind. Any advice you find on this subject will be more geared toward how you can better deal with them. Sure, if you’re stuck where you are for whatever reason, then coping is your best shot. If you’re not glued to your chair? GTFO. What I found is that we, the employees of workaholics, get caught in a sunk-cost fallacy of sorts. We’ve put so much work into the product and spent so much time with our team, that even though we grumble about getting our resumes ready when we’re sucked into (yet another) death march to meet an impossible deadline, we still don’t leave. Why?

We care about our work. We don’t want to be seen as disloyal. That’s what it usually boils down to.

You can take pride in your work, go above and beyond, and do right by your team without becoming an automaton. You can do all of these things and still get off of work at a decent time and enjoy your weekends, even planning a vacation every now and again. You can. The curse of being employed by a workaholic is that these goals are made to seem mutually exclusive. In fact, I would argue that a person who you are paying to think (an engineer) is better suited to their job when well-rested and emotionally stable.

Your job is not your life. Nor should it be. Do your best. Be proud of what you produce. But, don’t waste your precious fucking life on a goddamned job.

Cheeky title aside, this post is about a topic that weighs heavily on me, both as a person who does occasionally look for a new job, and as a senior developer who routinely interviews prospective coworkers.

I’ve been a part of many interview loops across several organizations (as a candidate and interviewer), and I can say one thing for certain: We can do better.

This isn’t to downplay how devilishly tricky it is come up with an interview process that uniformly, across the board, will always flush out the best talent. It’s a bitch. And if companies like Google, Facebook, and Netflix still don’t feel like they’ve got it completely right, that should highlight just how difficult it is.

Gaining a developer who is technically gifted, gets along great with the team, and communicates effectively is like striking gold. In fact, I think getting a hundred percent hit on all of those qualities is basically impossible. To borrow from an overused visual aid (this author is stealing from Datastax’s DB consistency graph), it’s almost as though we have a triangle with three points, each representing one of the following qualities: Technical Skills, Culture Fit, Communication and Soft Skills. Every one of us lands somewhere in this triangle, but by virtue of its shape, we can never quite reach the maximum potential of all three.

You may not agree with that, but, hang with me, because I think this is part of the reason why hiring is so difficult. We enter into the hiring process saying we want “the best” candidate without defining what that means, or, without seriously considering what that means in context of the vacancies we’re trying to fill.

For example, if you already have a team of super-genius coders with strong personalities who disagree constantly with each other, do you really want to add another person just like this to the mix? Or do you need an engineer with excellent soft skills to bridge the gaps and get the project moving forward again?

I want to share an anecdote, with identities and situations changed for my protection.

Once upon a time, a growing product team needed more engineering talent. The team had an engineer who had went through an exhaustive architectural review process with his senior leadership, and it was time to write some code. What the situation truly called for was a couple of mid-level developers with good technical skills, solid experience, and great teamwork. People who could work together on implementing the architecture together, with direction from the senior engineers.

What the hiring process provided, however, was another two senior-level engineers, described by those in the interview loop as “Rockstars.” Engineer A spent most of his time arguing with others about the approved architecture rather than writing code. Engineer B was more interested in getting into a rest-and-vest situation, constantly looking outside of his product team for work which he could claim was stealing his time from actual development.

This isn’t to say that A and B were bad engineers. They simply weren’t right for the roles they were put in. A may have been well-suited to work on a greenfield project where he would have more say in the design. B may have been better in an architecture or consulting role at an enterprise dev shop. The end result was a lot of wasted time and money for two hires who should have been helping propel the product over the finish line, but actually dragged it down and caused further delays.

So what went wrong? This is the question we should be asking ourselves when these situations occur, and occur they do. Asking this of myself repeatedly has led to some insights, which I hope would prove useful to other engineering teams.

Given that needs will vary based on role, my observations are that the following practices tend do more harm than good:

• Spray and Pray Hiring
• Inconsistent Standards Among Interviewers
• Skipping Interviewer Training
• Lack of Focus or Goal for Vacancies
• Groupthink
• Creating a Clone Army

Spray and Pray

To borrow a term from my time in the Army, Spray and Pray was a euphemism for laying down suppressive fire. Or, shooting toward the enemy, not caring if you hit anything, just to keep them from moving. In the best case, it let your team advance. In the worst, it kept things at a standstill.

The hiring equivalent to indiscriminately dumping rounds downrange is job advertisements that don’t actually map up to a specific role, coupled with a cookie-cutter interview loop. We are looking for a generic engineer, and we will submit you through all of the generic engineer interview processes. Can you identify the complexity of this algorithm? Can you solve this coding test? You’re in.

This hiring methodology takes none of the specific skills of the candidate into consideration. It’s a tempting approach, especially from an HR perspective, as it makes the process well-documented, defensible, and reproducible.

An antidote to this is to introduce interviews as part of your loop which are designed to flush out the qualities you need for the role. If a candidate got through the technical screening just fine and you need a great communicator, why not focus on that for an hour instead of seeing how well they can solve (yet another) HackerRank challenge. Ask the behavioral questions, give them hypotheticals, ask them to explain a difficult topic.

Inconsistent Standards Among Interviewers

This overlaps a bit with skipping training, because some of these issues could be weeded out with training. Some.

Inconsistencies abound during interview loops. It’s to be expected, really, that we all value different qualities in a candidate. The important thing is to be clear about what you are looking out for, and your grading standards. So at the end of the loop, when everyone involved is on that final assessment call, we can be clear about how each interviewer made their decision.

An example of this would be how we administer coding tests. I’ve worked with engineers who cared only about the final outcome of the coding test. Did their solution work, or not? I, however, disagree with this approach, and feel the exercise is more about seeing how a person thinks rather than how quickly they can hack together a solution to FizzBuzz. Maybe they only solved it quickly because they’d done the problem before. Maybe they only struggled because they were nervous and missed a step, but their approach was basically solid. We need to pay attention to these things.

Skipping Interviewer Training

How many of us have started a new position and within a month found ourselves already conducting interviews? I’m guessing most of us. It’s nuts, right? Sure, I suppose there are interviewing fundamentals that transfer across companies; the legal stuff, mostly. But how are you supposed to fairly and accurately evaluate a candidate according to the company standard, when you don’t even know what that standard is?

A friend of mine from college told me about how after starting his first job as a senior-level engineer, he was put in this situation. His manager sent him a link to the HR interview training documents. Most of which were outdated, and none had anything specific to say about how a technical interview loop should be conducted. When he asked his manager for guidance, he was told to use his best judgement. Full stop. As you can imagine, their hiring process was a mess, where no one could seem to agree on anything, and management continually found themselves staffed with new engineers who didn’t fit in well with the team.

Groupthink

It takes a strong personality to stand up to another strong personality. Also, the motivation to do so. It’s this second part that fails over time.

At a previous job, I noticed a trend emerging at the end of each interview loop. One or two of the most outspoken managers would provide their assessment of a candidate, often speaking for much longer than their allotted time. At the end of their pontification, the rest of the votes would almost unanimously fall in line with their decision. Even if I knew for a fact other interviewers had felt differently coming in to the meeting, they’d change their vote to match the loudest voice in the room.

Why? It was something I was even guilty of a time or two. Why did I change my vote? Why did others change theirs?

After one of the candidates I really liked didn’t make the cut (and I was the lone voice speaking up for them) I decided to do a little digging. I talked to a friend of mine who I knew was also going to vote for the candidate before the meeting. “Why did you change your mind?” I asked him.

“There’s no point in arguing with that guy,” he said.

And so it goes. As in so many aspects of life, the strong personalities who refuse to give ground will find a way to brow-beat dissenting opinions into submission. Not by the strength of their arguments, but by sheer persistence.

Creating a Clone Army

Another common trap is the tendency some people have to want replicas of themselves to join the team. In a way, I get it. We all want to work with other people who share our opinions and laugh at the same jokes, but, in reality there really is strength in diverse viewpoints and skillsets.

A team of engineers with diverse skillsets and favorite focus areas will only strengthen your product by increasing the overall breadth and depth of the team’s combined experience. If you’ve got a five-person team who all specialize in Rest API design, versus a five-person team consisting of people who respectively specialize in Rest API design, multi-threading, data-modeling, microservice frameworks, and architecture – which team is going to get a better product out faster?

I once sat as co-pilot on an interview where our team’s director grilled a candidate for an hour about threads and locks. It wasn’t a helpful interview strategy, but the director stuck with it simply because that was his wheelhouse and he wanted to be an expert. But what use would it have been to hire a developer after only testing them on one area of knowledge? Our primary product wasn’t even a multi-threaded application. His default tactic resulted in hires that had the same area of expertise as him. It wasn’t helpful.

In Summary

Like many complex issues, there’s no silver bullet here. If experience is any guide, however, hiring gets a lot more effective when we take the time to honestly evaluate what we’re doing an why, while keeping a sharp on who it is we need to fill that empty desk. I hope that some of these observations will prove useful to someone out there.