The worst part about job searching
An ode to the part of job searching that I mostly hate, but not always. Herein, I attempt to navigate my way towards a place of growth.
Editor’s note
Welcome to the first post of this brand-new publication.
Today’s topic is somewhat niche: job searching specifically within software development. These ideas happen to be presently top of mind. Also, it’s what my brain wanted to write about first, for some reason.
This publication will cover a range of topics that I find interesting and under-discussed. I don’t intend to talk about either job searching or software development all that often.
-Phil
Imagine you are a software developer, and you're looking for a job at a startup. You find one you like, apply, and make it through the first few screening calls. They seem to like you, you like them; it's all trending in a promising direction. Then you hear the following:
"We regrouped on our end and would love to move forward to the final stage of our process! This involves a quick take-home project."
This is a situation that many job seekers find themselves in.
So let's take a look at the concept of take-home projects: what's good about them, what sucks about them, and then attempt to put a positive spin on the entire situation.
Sound good?
So what exactly is a take-home project?
Take-home projects are a small assignment given by companies, to candidates, to evaluate programming aptitude. They're similar, in many ways, to projects that students are assigned while studying computer science. They usually take between 2 and 8 hours to complete.
Here are some examples:
"Make a single-page React app, in which you call a weather API, and then display the current weather condition for your present location. Include an text input field, where you can fill in any location. Make the design as beautiful as you can."
"Build a dashboard which displays the security investigations contained within this JSON file. You can use any framework you like. Make the design as simple as possible. Bonus points for adding end-to-end testing"
"Here is a codebase. We need a certain feature added. Create a pull request against the codebase which adds that feature."
Sometimes, they'll say "spend no more than X hours on this project." Much more often, they'll say "we think this should take around than X hours."
Often, these assignments will have requirements such as "you must use this framework", or "don't use any libraries - only do it with vanilla Javascript." Once or twice, I've encountered requirements like "you can only use a routing library, but nothing else."
Often, the instructions say "keep us updated, and inform us if you get stuck."
Through these assignments, companies are judging candidates how much they care; how much are they're willing to invest in this opportunity. And obviously, they want to know how good candidates are at actually writing code.
The job-seeker's dilemma
So you're sitting at your computer, reading these instructions. What do you do?
In theory, if you perform well against these instructions, putting in the time, writing good code... you'll make it through the next round. So is it worth the investment?
Personally, I don't hate it when I'm assigned a take-home project. Given the choice between one of these projects, and a brainteaser question during a live interview, I’d always take the former.
My own tendencies give me an advantage on take-homes — mostly because I’m really good at spinning up new projects — but also for the same reasons that I was good at projects in school and terrible on tests. As such, there is a part of me that relishes the opportunity to show my prowess.
However, there’s a lot more to the story.
Reasons to groan
When assigned a take-home, I do groan a little bit. Actually… I groan a lot.
So let's talk about the underlying reasons for these groans.
Unpaid labor
The vast majority of take-home assignments are unpaid. By default (i.e. unless explicitly stated), you’re not going to get paid.
I have run into a few rare, beautiful, shining-city-on-a-mountaintop companies who offer to pay. I absolutely love this model, and I really hope it becomes the norm. Sadly, as of early 2024, this is well and truly not the norm.
If our suitor company says "this should take no longer than six hours," and I (the developer) can go out and get $50 / hour in the market, the company is saying "in order to (maybe) proceed, you need to pay us $300." It's almost a tautology — just a rephrasing of the ask.
Keep in mind, this is a time when candidates usually need money. Whether we’ve just been laid off, or they were fired 3 months ago, we're desperate at this point. (Granted, many people are better than me at job searching while they still have a job. I've never been good at that.)
Not only that, this is a point in the interview process when we've already invested multiple hours into the opportunity. So, it's ever so easy for sunk-cost fallacies to start to creep into our brains.
We're grinding, hustling, broke, and desperate. That's a big part of why the entire concept of take-homes often feels tone-deaf and unfair.
However, let's be fair to startups here… they're also striving to make it; trying to survive in a marketplace of their peers, just like we are.
But, when you think about the unit economics, $300 is much more money to you than it is them, by an order or two of magnitude.
At the end of the day, this is labor. People deserve to be compensated for their labor.
Opportunity cost
Job searching is an exhausting process. I've often thought that it's more taxing than day-to-day job work, by an order of magnitude. Something about juggling multiple conversations, always putting your very best face forward, having to talk yourself up constantly, and frequently being under intense pressure to perform — it really wears on you.
The entire process of working on a take-home is similar; you need to be "on" the whole time.
But it's also time you can't be talking to other companies, polishing your resume, improving your personal website, cruising the job boards, or any number of other important tasks.
To complete a take-home assignment, you are usually sacrificing a whole day of normal job searching, and that is not insignificant.
Time limits
Remember how the company gave us a time constraint at the outset? It was in one of the following forms:
“We think this should take no more than X hours.”
“You should spend no longer than X hours on this.”
So what happens when you get to X hours, and you're not quite done? Are you going to stop, and simply turn it in?
Turning in an incomplete project is a surefire way to not make it to the next round. And you're really throwing those X hours away, then. What an “email of shame” that would be: "I didn't get to it all, but here you go."
I'm fairly certain no one does this.
Job seekers know that other job seekers exist, and they know other job seekers wouldn't do this. So what do candidates actually do?
They keep working on it, of course.
Ultimately, there's no enforcement mechanism for time limits. (I suppose they could look at the timestamps of each commit, but I mostly doubt they actually do. Also, would they really hold it against candidates for spending more time than requested?)
All of this means that the time estimates are basically meaningless, mostly serving as lower bounds on the amount of free labor being asked.
Two loud, inescapable voices
When I'm working on a take-home, there are two loud voices in my head who directly oppose each other.
The first voice says something like the following:
Let's make this as good as possible. I like this company. I'm good at what they asked me to do. Let's add a ton of polish. "Extra credit" requirements? Of course I'm going to do them — every single one. Automated testing? You bet. I'm being evaluated against a legion of other hungry candidates, and I need to stand out.
The second voice says:
Let's spend as little time as is necessary for this. The company might fixate on a superficial flaw of my code, and then use that as justification to reject me. If they do that, this time is wasted. So let's optimize for completing this as quickly as possible. What corners can I cut? I need to be applying for more jobs. We're not getting paid here. Go faster.
The cruel equation
To me, this cruel equation forms the central issue with take-home projects. It's an algebra equation — maybe calculus (an area under a curve or something?) — that causes constant stress for the candidate throughout the process.
You're being watched
Usually at the end of these, you'll be asked to share a private GitHub repo with the company.
That mean that all your commits are going to be in there. The cul-de-sacs that ended in failure, and might alert them that you're actually stupid. (And we can’t have that.)
In a real job environment, no one will look at your code until it's in pull request form, and that point, GitHub displays just the net difference.
Is the company actually going to look at your commits individually? I would say probably not, but they could. (To tell you the truth, as an evaluator of take-homes, I actually have.) And that's even more stress. It means you have to be even more careful while coding.
What are they really looking for?
There's often a question of how you'll be evaluated that borders on unknowable.
Let's take an example of dark mode. Personally, I implement a dark/light mode switcher on all my side projects. In my preferred tech stack, I can add this functionality in around 15 minutes of effort, but in other tech stacks, it can be an hour or two.
This is one things that shows an attention for detail, a dedication to craft, and a willingness to go the extra mile.
But will the reviewer give a shit? It can be so hard to know the answer to that question.
Sure, you can ask. But there's no guarantee the answerer of that question is the same person as the reviewer of the completed assignment. When you submit the project, very rarely do you get meaningful, direct feedback on your submission. It's mostly just a pass-fail.
This is even more the case with things you don't do, that the reviewer wishes you had… but they weren't explicitly stated. They just wish you were that kind of programmer who finds it obvious. And these can be very superficial things.
Maybe they really didn't like that you used single quotes instead of double quotes in your JavaScript.
That's a completely meaningless difference for the website that gets loaded, but people have feelings, and it would not surprise me if candidates have gotten rejected for things as petty as that.
I know the last few paragraphs were extremely cynical — forgive me for that — but I do think meaningless things like that are in play here… if a little less extreme.
You've just gotta get lucky on these sort of things. You can’t ask 100 questions. I’ve been on the other side of the table a lot, and a candidate who asks 100 questions is annoying and not getting hired.
In summary, the “fog of war” elements here are quite cruel, and they all cut against the candidate.
Bending the rules
In a real-life job as a working developer, you often get a chance to refine the requirements before starting. An advantage of hiring a senior developer is that they have the experience to say "Ok, you want me to do that… I can do that, but I could also give you 90% of that for 10% of the effort, if we slightly change the requirements." Mostly, you don't get to do that with take-home assignments.
Even still, you can bend the rules a little, in similar ways, but it's a guessing game whether or not the reviewer will reject your submission for such changes. A tiny rule-bend, which saves you an hour and a half of unpaid labor, which you can then apply to time spent job searching, can often be the correct move.
Still, the "black box" nature the assignment makes this inherently risky.
Ready-made resentment
Let's say you go all out on project, bending the rules a tiny bit (as described above), and submit it. A few days later, you get an email.
"While we acknowledge your effort and investment, we were looking for solutions that adhered a little closer to the instructions provided. Unfortunately, your submission did not fully meet our expectations." (That is a typical response that candidates receive.)
Reading that email, having invested so much effort, it is such a challenge to not feel resentful. Personally, I've been there more than a few times, and calling it “soul crushing” would be an understatement.
Getting over it
But dear reader, at this point, you might be saying:
"That's something you have to work out with yourself. Life is tough... get over it."
To that, I’d reply:
"Yeah... fair. Get back up on that horse and keep going. I agree with that."
But isn't the ability of a system to create such feelings — so easily — a sign that the system is broken?
Record scratch.
Spinning this around
Alright... enough bitching and/or moaning. (I actually don't hate take-homes, remember?)
How can we approach this differently, from the outset, so as to mitigate these issues?
Salvaging something good
In order to not feel like we've wasted our time, we should reframe things. What if we enjoyed the process of making the project? Would you still feel resentful if you enjoyed it?
That question that begs another question... how do we enjoy this?
Everyone will be different here, but for me, I enjoy learning. I get immense satisfaction in the feeling of expanding my knowledge — gaining another feather to put in my developer cap.
So, when planning out your project, read the instructions carefully and think to yourself:
"What part of these requirements is a chance to learn something new?"
Maybe it's a new UI framework you've been avoiding, or a new database something-or-other that everyone has been jabbering about in your timeline. Maybe you’ve been meaning to add automated testing to your side projects, but you’ve always been a little too lazy. Maybe this project is an opportunity to figure out how to set that sort of thing up.
Doing something of this sort transforms the endeavor into a win-win. No matter what happens, you won't be walking away empty-handed.
Remembering why you show up
Do you enjoy coding? Or is it just something you do because it pays well?
There's a well-known thought experiment that goes something like this:
"Imagine you have all the money you need; you don't need to work any longer for money. What would you do with your time?"
Whatever the answer to that question is, that is supposedly what you should do for your career.
I guess I'm lucky... I'm already aligned there. I love coding. I code for work and I code for fun. I just get a lot of enjoyment out of the act.
So, if that's true for you too, definitely remind yourself of that — especially after you get rejected on a take-home project.
Asking the hard questions up front
At the point you get the first email asking you to complete a take-home, it's uncomfortable, but try asking to get paid.
Perhaps you can make it clear that payment isn't a deal-breaker for you... but gee whiz gee golly… what a nice gesture that would be, don’t you think?
You can also ask for an exception:
Can your open source project take the place of this? (Being involved in open source is great optics for job searching anyway.)
Can you use a previous take-home project take the place of this? (Definitely get permission from the prior company first.)
If you’re senior, can we simply skip it? (I think take-homes already make more sense for juniors than seniors.)
Finally, ask for a commitment to be given real, meaningful feedback — as opposed to a simple pass-fail — upon completion. I mean… ask for an 8-step rubric, for fuck’s sake. Ask it however you want. Just make it clear that “nope, you didn’t get it, smell ya later!” isn’t an acceptable response to 6 hours of unpaid labor. If the company isn’t willing to do that, you might want to voluntarily pull out of the process.
Importantly, ask these things up front. (This is the part I’ve personally been bad at.)
Growing from real feedback
This can be another hard thing to deal with, but maybe you did sort of mess up on one of the requirements, and maybe they actually gave real feedback to that effect.
If that's the case, try to internalize that. Feel it in your bones, and challenge yourself to do better next time.
Advice for companies
I’ve been through this process many times both as a candidate and as a company. With that said, here are my personal unwritten rules of administering take-home projects.
Let the candidates use whatever tech stack they want.
Tech stacks aren't that hard to pick up. Once they have the job, and they know they're going to be working in your exact tech stack for the foreseeable future… only then should they be forced to adopt your own esoteric stack. Which leads me to the next rule...
Don't give candidates your own codebase, asking them to add a feature.
This requires a level of mental ramp-up which will be almost entirely wasted time for the candidate, should they not receive an offer. Which leads me to next rule...
Consider paying candidates for their time.
If you do, you can definitely break the previous rule.
Be extremely nice about superficial things in the code (or design) that aren't pleasing to your personal eye, but may just be a difference in aesthetic taste.
Give candidates meaningful feedback. Enough of the "we're afraid of a lawsuit" talk. If you're asking for free labor, it's the right thing to do.
How many lawsuits have really come from giving meaningful feedback? I suspect it's one of those "razor blades in the halloween candy" thing that happened literally one time and now everyone suffers.
This is an experimental idea I’m trying out, but… offer candidates an iterative process:
candidate submit code
company reviews code
candidate fixes code
company gives final review
Allow candidates alternative options such as open-source contributions, or reusing take-homes for previous companies.
Even better, inform candidates it's perfectly okay to reuse your take-home for other companies.
Wrapping things up
The cruel equation I outlined above isn’t going anywhere, any time soon. So, my main message for candidates is simply to make the best of it.
To the companies looking to find the best candidates, I implore you to allow candidates to make the best of it.
Job searching is stressful enough as is.