A brilliant slacker is still a slacker
but a hardworking sheep delivers results
When I enrolled in my first computer science course in college, I did so with zero prior coding experience. Most of my classmates had prior experience, so I immediately felt behind and dumb. Not only that, these people were smarter than me in terms of IQ. I was a sheep and they were lions. They’d raise their hands in class to answer questions I didn’t even begin to understand. But as final exams rolled around, I got an A in the class (barely) whereas some of them didn’t. Why? Because I spent every waking moment working my ass off to understand the concepts and finish projects while they played video games and ate Cheetos into the late hours of the night.
A strong work ethic in this industry is more useful than a high IQ. A high IQ slacker isn’t useful at all. You should avoid hiring professional slackers.
In my previous post, I focused on the first of two questions that every interviewer should seek to answer for a coding role.
Can the candidate code?
Will the candidate code?
In this post, I focus on the second question. We’ve all worked with that guy who doesn’t actually do anything. He is akin to that other guy in your college group projects who didn’t contribute but got the same grade as the rest of the group.
But somehow that guy got the same job you did. How? Often these people are great at coding when they code they just choose not to code very much when on the job. When you pass by his cube, you might see that he has Reddit or Twitch open more often than his Borland IDE. In the remote world of today, you really don’t know what he’s doing. He often isn’t easily accessible via HipChat and tends to miss standup meetings more often than the rest of the team. Sometimes he has his codebase that he’s suspiciously protective over. There’s no contribution guide, and all the commits are from him. His stories are usually centered around that codebase, and stories almost always get punted multiple sprints before getting completed. Maybe when his work gets punted one time too many, he announces that his special code base needs a lengthy but necessary refactor before any additional feature work is done on it. He then spends several months changing around a few lines of code. Oh, and usually this guy is a senior engineer. He can hold his own in meetings, so people outside the team don’t necessarily know he doesn’t do anything.
If you’ve ever had him on your team as a fellow engineer, perhaps you’ve grown mildly frustrated with him but are willing to deal with it for the sake of team cohesion and because you have no control over it. But he is hell for your manager. Your manager probably realized he isn’t actually doing anything long before you did because your manager is directly accountable for his lack of work. So what options does your manager have? Often, none that are great…
Pretending the slacker isn’t a problem is probably worst course of “action” for your manager. It will cause other engineers on your team to learn what they can get away with. It will also bring down your team’s performance and doesn’t deal with the problem. You’d be surprised how many managers take this route though. It is the simplest to take. There’s no guarantee that your manager will be able to replace the slacker and the other options are difficult. As you’ll see…
Coaching the slacker is often a futile (but legally necessary) effort for your manager because the slacker isn’t in need of actual coaching. He needs to pick up his keyboard, pull the code from Subversion, open Notepad++, and get to work. He just isn’t doing that. No amount of coaching is likely to change that.
Putting him on a performance improvement plan is a good step for your manager, but it will often backfire. Why? Because this guy is actually a good programmer. If you give him a project that he has to complete or else he gets fired, he is going to be able to do the bare minimum to prevent himself from getting fired. This can draw the pip process out for months.
Transfer the slacker to a different team. This is good for your team, but this is how your manager makes enemies. It isn’t fair for the new manager, and it might allow the slacker to “start over” in his slacking ways at your company. Don’t do this.
Fire the slacker. HAHAHAHA. You think this is easily possible? Perhaps at very small companies this is possible. However, slackers avoid startups for this very reason. They choose positions where they can slip under the radar on purpose.
Most of these options will shift your manager’s time and focus away from your effective team members and toward the ineffective team members. This hurts you more than you probably realize. Do you think you are deserving a promotion? Too bad, your manager has been too busy writing PIP documents/reviews for HR about your slacker teammate.
Ideally, this guy should have never been hired in the first place. But how do you identify slackers during the interview? I am making an assumption here that the slacker is intelligent enough to pass a coding interview because many are. So, it is during the other parts of the interview where you must identify troubling behaviors. Here are some ideas.
Don’t let trivia style questions be the focus of your interviewing. I’m talking about questions like “what type of garbage collector does Java use” or “compare dynamic and static typing”. These are not bad questions entirely, but any intelligent slacker can perform well on these types of questions. You won’t identify laziness with these. You might use these to find people who didn’t pay attention in school, but let’s be honest plenty of coders with low GPAs are high performers in the workplace.
Ask behavioral questions and dig deep into their response. These types of questions require the candidate to explain their past actions. For example, “tell me about a technical achievement you are proud of” will get the candidate to talk about their most important projects or features they have worked on. A professional slacker will often make mistakes on this type of question. Here are some of them…and ways to deal with them.
He explains work that his team did that he wasn’t necessarily involved in. This is a potentially honest mistake that any candidate can make. To deal with it, ask specifically what his contribution was. Did he write any of the code? What patterns did he use? What about testing? How did he perform end-to-end testing on the new feature? What impact did the feature have for the stakeholders? If he’s unable to answer these questions in a meaningful way or his answers are hand-wavy, then that sends a signal that perhaps he wasn’t quite as involved as he wanted you to believe.
He doesn’t actually test his code. Professional slackers hate writing tests because testing is boring and sometimes really difficult. Tests also have the additional “undesirable” effect of proving that his codebase doesn’t actually work. Most software these days interacts with numerous other services (aka dependencies). If a candidate can’t explain their strategy for meaningfully testing these types of services, then perhaps he didn’t write any tests at all.
He talks more about what he would do and less about what he has done. Just because a candidate knows the theoretically correct answers doesn’t mean that they’ve actually put these proper practices into place at work or that they will do so in the future. If a candidate starts explaining theory, ask them about a time they’ve actually used that theory. If they don’t have any examples, ask them why. They might actually have a valid reason, but this still would be an area of concern.
He’s “never made any mistakes”. Someone who doesn’t work much probably hasn’t had much opportunity to fail. Once a team identifies a non-performer, he usually gets placed on projects with low impact and scope. A project with low impact and scope probably has low accountability. In other words, there won’t be others who care to catch his mistakes. So ask about failure. Was he able to provide any concrete examples of failure, and how he changed his behavior in the future?
He’s overly opinionated about technology he is comfortable with. In his perfect work environment, the slacker only wants to work on projects where he is 100% comfortable with every piece of technology in the project. He will be strongly opinionated and biased in favor technology he likes and totally against things he’s never used. Things like programming languages, databases, frameworks, etc. Remember, his goal is to avoid the difficult trouble of having to learn or step outside his comfort zone. He’d prefer work where in a 10 day Agile sprint, he can finish all of his stories on day 9 while doing no work on days 1-8. So if you hear a candidate say things like “always use Java” or “NoSQL databases are a fad”, these are potential indicators that he won’t step outside his comfort zone.
His resume may contain clues. Professional slackers tend to float from job to job every year or two. They tend to not take positions at true software companies but instead choose large organizations that happen to have large software teams. Think banking, finance, insurance, etc. Alternatively, they picks roles where work is difficult to measure in traditional ways. Think of Site Reliability Engineering positions at companies that don’t actually know what Site Reliability Engineering means. Instead of listing their work achievements under each job, they simply list the technologies they used. Of course, this is a mistake anyone can make, so don’t lean entirely on these. They are simply clues.
I don’t pretend that these methods will catch 100% of non-performers. Remember, these people are intelligent and capable. They just choose not to be. However, if you use a coding interview to weed out incapable candidates and the methods in this post to weed out slackers, then I think you’ll come pretty close.
Unless of course you are an entire team of professional slackers. These exist and will be the subject of a very distant future post.
If you are the type of slacker I discussed in this post, then fear not! All hope is not lost. Anyone can change, but you will have to take it upon yourself to change. My recommendation would be to first identify whatever it is in your life that is causing you to underperform. This could be anything from alcohol or Gacha addiction to lack of sleep. Whatever it is, seek help from friends and consider professional therapy. Once you’ve addressed whatever is holding you back, it would probably be best to start fresh with a new company and a new sense of purpose. You’ll probably have trouble getting referrals though…