Senior Devs - Say No to Coding Assignments
Recently, there has been widespread agitation against whiteboard interviews across the industry.
They are stressful, and the industry has already acknowledged it widely.
But apart from that, in most cases, they weed out true positives. Max Howell, the creator of Homebrew, was famously rejected by Google for being unable to finish a task in time during a whiteboard interview.
Enter coding assignments. They are sold as a panacea for every software evaluation problem.
The Obvious Benefits of At-Home Coding Assignments:
Senior devs literally salivate at the opportunity of being remotely-tested with coding assignments
#1: They are done at home, which means all the stress factors associated with whiteboard interviews (or live coding sessions) are ruled out. No one is looking over your shoulder as you code.
#2: Due to their longer (typically one-week) duration, a candidate can be tested on a much wider range of skills than boring for-loops, crammed optimization techniques, and must-do thinking-alouds.
#3: No travel needed. The candidate doesn’t need to take a day off from her day job, and the interviewing employer doesn’t have to pay for it.
Candidates, especially senior devs literally salivate at the opportunity of being remotely-tested with coding assignments by the companies they love.
They challenge devs for skills spanning all tiers of software development: UI, business logic, database, connectivity, and testing. What better piece of evaluation can see through all of it?
Against their junior peers who instagram their CFS (Copy from StackOverflow) code or tweet their latest nonsensical star-scouring Git repo, they finally got something to show. And all for their career advancement. No silly show-off tactics.
They get infinite time to prove their mettle. They have 1000% motivation to be awesome. What’s there to lose?
Wait: It’s a honeytrap.
The Coding Assignment Honeytrap:
Let’s dissect their symptoms, one by one.
#1: Asynchronous Communication:
You must act like a worker thread.
Whiteboard interviews challenge you with atomic tasks (sort an array / find the number shortest path etc). Interviewers want to see you analyze the problem during the problem, and are eager to answer your most mundane questions. Their time is at stake too.
In a whiteboard interview, the exchange of information happens in a linear way, wherein the interviewer provides an input, and you produce an output. If you are correct, good for you. If you are incorrect, you still reveal your thinking pattern, which could be a plus for you if other candidates failed in it.
In Whiteboard interviews, you must act like the main thread — always responsive to what is asked of it. Freezing isn’t allowed. You have the authority to ask though, and other threads (interviewers) must answer.
At-leisure coding assignments are exactly the opposite. You are like a worker thread who gets a task submitted to it. The main thread (the interviewer) disappears after posting to your queue.
You may be required to post your progress/result, but there is almost no input obtained from the other side.
Interviewers can be queried via emails, but their responses are mostly cryptic and untimely. Technical documentation of the problem is non-existent.
#2: One-Liners:
They are headless challenges that tempt the programmer in you to be fully immersed in themselves.
Mostly, coding assignments are 1-line requirements, with implementation details left to you. There could be 5–6 lines, yes, but they are often insufficient. They are headless challenges that tempt the programmer in you to be fully immersed in themselves. When you emerge back, rejection (more often than not) awaits you.
Without requirements or design, programming is the art of adding bugs to an empty text file.
- Louis Srygley
They are defined concisely (usually in < 10 lines), but not always precisely. As a result, Design the most efficient air traffic system can be a valid requirement statement.
Well, that’s not a problem, but this is: The ideal answer depends on what the interviewer has seen (probably on TopCoder or a similar place), not what you tried + achieved.
Remember the Sully movie? The human factor in solving an unforeseen problem is often overlooked.
If interviewers saw the solution somewhere online, they always assume you would copy the solution. You must meet/surpass that level. If you haven’t, you can’t win. For you, it could amount to reinventing the wheel, and they might not be looking for it.
No marks for don’t-know-but-can-achieve attitude.
#3: Expectation for 100% Consistency:
Sample of good code != Demonstrated capability.
Whiteboard interviews test your capabilities in symbolic ways. If you are able to show your modular approach in one place, it is not expected at every possible place. Sample == Demonstrated Capability.
In an at-home assignment, you must do it seamlessly. Sample of good code != Demonstrated capability. You are doomed to show consistency, and even past that, you are doomed anyway, because your evaluator's mental model of the problem could be totally different than yours.
#4: Infinite Scope of Assumptions:
A tree with an infinite number of branches. You can’t parse it even with the brute force approach.
If you choose a specific paradigm to solve a problem, it portrays you as incapable of knowing/exercising other paradigms.
If an ideal solution to a coding assignment could be described using a programming model, it would be a tree with an infinite number of branches. You can’t parse it even with the brute force approach.
If you choose the Object-Oriented approach, you are not functional enough, and vice versa. Since the team only knows the former (/later), and you chose to show later (/former) although you still knew former (/later), you are unfit. No questions asked, no expectations set beforehand. No second chances. Plain rejection.
Assumptions are considered part of the challenge. You are required to make the right ones. They will undoubtedly make them too while evaluating you.
The promise is that if you make the right ones, you will succeed. But it’s merely a promise. There is no way to ask, and if you do, you may be evaluated even for asking.
#5: The scope of development is momentous:
Not the size, but breadth.
The requirement is to design a miniature system, not a component. This means that you must design + develop UI, models, services (networking/file/database), and everything in-between.
Remember the scope-time-cost triangle? If you increase one side, the other two undoubtedly grow. But no one pays you for the coding assignment, and no one suffers if you miss the deadline, except you.
Any senior dev can say that such coding assignment miniature could act like a template that can very easily be monetized.
Some unscrupulous employers may rip you off too — this is possible due to the sheer breadth of features it touches upon. The better you refine it, the more likely it is for them to copy and release.
You can achieve the task output in no time, but no one submits at that stage.
But 99% of them are honest. There again, there is no guarantee you can nail it past a week’s effort. In most coding assignments, it is assumed that you have done it before. If not the problem, at least components. There are no points in trying an untried problem. No points even for achieving the desired output, or 100% passing tests. The only way to succeed is to mimic their ideal sense of design, which you can rarely know unless you are a mind reader. They never tell you the truth, even past rejection.
On paper, it is stated that it should not take more than 2–4 hours of your time. But it can rarely be finished even on a full weekend unless you did it already and just need to copy-paste.
And it’s not them, it’s you: You can achieve the task output in no time, but no one submits at that stage. It’s not greed to innovate, but fear of rejection due to presumably unstructured code that achieves all of the stated requirements.
You will rarely admit it took more time because you fear rejection for having taken longer.
If you don’t see all the components the way your interviewers saw, you missed serious lessons in design.
If you saw those parts and the interviewer didn’t, you have over-engineered the problem.
#6: Post Rejection Communication:
Among all other issues cited, this is the most crucial one.
If you can’t reach out to every senior dev, you made a mistake in the CV screening stage. You didn’t screen them enough! Why should senior dev pay for it?
Because it is through this factor that you know if you truly lacked what they wanted, or they were simply playing with your time and emotions.
Most tech teams do not communicate rejections directly. They do it via recruiters so that they don’t have to delve into the details about why the rejection happened. If you are luckier, you get a creatively drafted rejection that summarises the shortcomings in ambiguous words. If one asks for further explanation, the line goes dead.
While this could be justified in the case of junior developer interviews because of the sheer size of candidates and spaghetti code is cumbersome for feedback, it is totally unjustified for senior candidates and the time spent after coding assignments.
If you are NOT one of the FAAMG, if your candidate pool is 20+ for 1 senior developer role, and if you cannot reach out to every candidate, you clearly made a mistake in the CV screening stage. You didn’t screen them enough! Why should senior dev pay for it? Even if his code sucks, you owe him a succinct explanation, not boilerplate rejection.
Not communicating past 1-week assignments should be considered a crime in recruitment practice. Unfortunately, it is the entitlement of rejection that tech teams enjoy.
Takeaway?
Gaping inequalities can hide behind the veil of the insistence of merit.
Due to highly subjective selection criteria, the coding assignment becomes the strongest weapon in the hands of racist, sexist or prejudiced tech team, and you have no way to dismantle it from the system because it can never be proven.
Gaping inequalities can hide behind the veil of the insistence of merit.
What companies must do?
Stop molding humans into coding machines.
Senior devs play a much more vital part in a tech company’s future than just coding. A senior dev having a clear product roadmap is worth more than five junior devs who need to be told what to do.
By spending effort in pre-evaluating them based on their GitHub / Portfolio, tech companies can reduce/circumvent the amount of code a senior dev must write to prove her mettle.
Coding assignments should be replaced with one or more in-person discussions. They could be about the candidate’s past career + employer’s future direction. This is the way to ensure that the stated experience isn’t a bubble. It is also a way to see if the candidate is precise in communication — the most vital skill a senior dev should possess.
Stop molding humans into coding machines.
What senior devs should do?
If companies are less likely to abandon it (as happens in most of the cases), senior devs will do well by saying No beforehand — to all sorts of at-home coding evaluations.
Unless they are doable in 4–6 hours of time.
You should only spend more than that if you could monetize the assignment past rejection: For example, you could see a potential portfolio project that could be uploaded on your GitHub (or made into a side gig).
Refuse to give away your time to noncommittal tech teams. And self-respect.