About 10 years ago, I decided that it would be a good idea if I interviewed with companies even if I wasn't looking for a new job just to keep my interview skills (and coding skills) sharp. I typically take at least 6 months after I start a new job to get settled, etc., though with my most recent job change, I waited more like 12 months just because I had so much to take care of.
(Hopefully, my boss is aware that I'm not actively looking to leave before he reads this!) So, I've had the opportunity to complete a couple of interviews in the last few months and they reminded me of my frustrations that I've experienced as a Senior/Lead/Principal Front-End Web Developer throughout my career. Those frustrations are almost entirely related to the coding exercises that so many companies have in place as a form of gatekeeping.
I've been pondering on my issues with these coding exercises for awhile now, and I've come up with 3 big gripes about them.
- Coding exercises rarely resemble day-to-day work
- Coding exercises punish non-traditional engineers
- Skills analyzed by coding exercises are a tiny piece of an engineer's makeup
Coding exercises rarely resemble day-to-day work
Let me start by stating that I can only refer to my own experience as a front-end web developer, so my argument here is largely framed in that context. 95% of the coding exercises I've had to complete as part of an interview process have been administered by a backend developer (or a full-stack developer who was certainly more backend focused). 95% of them have had absolutely no HTML or CSS component as part of the exercise. 95% of them have had no discussion of design tools or taking a design from Sketch/Figma/Photoshop and reproducing it with high fidelity in an application. 95% of these coding exercises have been tests of how well an engineer can manipulate data, typically data that should be manipulated on the backend of an API call, not data that needs to be rendered.
Why? Because with the bulk of the interviewers in the process being Computer Scientists, they want to test on what they know. In one recent exercise, the administrator actually said, "Well, I know how to solve this problem in Java, but not in TypeScript." I should certainly hope you know how to solve the problem you're giving me in your chosen language.
So, 95% of coding exercises are testing my skills in something I do less than 5% of the time in my job. How does that make any sense? By and large, coding exercises, especially live ones, are focused entirely on demonstrating that you passed your CS301 course in college, not in how you actually build functional web pages/apps. So, hiring managers, if you don't have significant frontend web experience, find someone on your team who does and have them lead the coding exercise.
Coding exercises punish non-traditional engineers
Non-traditional can mean many different things, so let me explain what I mean here. Non-traditional in this context means developers who did not follow the Computer Science standard course for becoming a developer. (I should apologize for intermingling engineer and developer as I know this raises some engineer's ire. Strangely, I've never heard a developer complain about it. ;) )
Non-traditional devs can be self-taught; they may have attended a boot camp for specific skills after graduating with a degree in a different field; they may have followed the CS route, at least partways, and then decided to follow a different path. In my experience, both as a dev and a manager, these non-traditional developers (I am myself self-taught, so I do certainly have a bias) bring a creative take on solutions that tends to fly in the face of the standard CS solutions.
That creativity is squashed and penalized in most coding exercises. In a recent exercise, I was told I was disallowed from using if statements in my solution. WHY? What does that prove other than that I know how to use alternatives to branching logic. If an if statement makes sense, why not use it??? If the interviewee wants to solve the problem in a completely different way and uses non-standard coding approaches, they are typically shut down by the proctor because they aren't doing it the right way. Don't we want some creative solutions? Don't we want at least a few people who are able to think outside the box (or the AST)?
Skills analyzed by coding exercises are a tiny piece of an engineer's makeup
Hopefully, most hiring managers recognize that the coding exercise should be a tool for evaluating a developer, not the whole kit and caboodle. There's no doubt, however, that managers for larger Silicon Valley firms are more interested in weeding out people rather than finding that proverbial needle in the haystack.
I have worked with engineers in the past who absolutely KILLED the coding exercise, but turned out to be black holes for the team they joined because they had no people skills. I've seen developers who absolutely KILLED the coding exercise who couldn't ship a piece of code for months because it wasn't perfect.
I'm going make a very controversial statement here:
For most engineers with more than 3 years of direct work experience, coding exercises are an absolute waste of time.
If a candidate has been writing code for 3 or more years, unless your coding exercise is merely there to weed out people for a specific reason, your time as a team and hiring manager would be far better spent talking about how to solve certain issues in general terms. Architectural discussions can demonstrate how well a developer can think about complex issues and break them down to solve them more easily. Find out how they keep up with technology and the new changes to languages/frameworks/platforms. Talk about open source contributions and why they do/don't matter.
Talking to a candidate for a senior or higher level position is a far better indicator of interpersonal skills, dedication to shipping code, understanding how to break down complex problems, etc.
So, I write this as both an exercise in catharsis, and as a plea to the developer community at large. Quit wasting your time with coding exercises that test a very small piece of work. If you want to see how somebody writes code before you hire them, give them a take home exercise to complete that involves an actual full solution, not just a scratchpad. Then make sure you talk about why they made the choices they did if you feel the need to challenge whether they built it themselves or not. (Let me be honest, if you feel uncomfortable that they wrote it themselves, you probably should step away anyway.)
Looking back at my experience as a hiring manager, I am grateful to have been given the leeway to interview in the way I needed to find the best candidates. Take the time to really think about what your coding exercise ACTUALLY tells you about your candidates and then evaluate if it's as big of a waste of time as I say it is.
Top comments (0)