After a successful phone interview, I was given my very first take-home code challenge last week. Listening to my interviewer explain the assignment, I was pretty confident. It was to be a login page with some basic validations on a form that took an email and a password. You say it should take only 2-3 hours, Mr. Interviewer? Oh, cool. Then I'll have plenty of time to get it done in the 2 - 3 days he said it should take. No problem. He even gave me a link to his company's login page as an example to work off of. Awesome. Nice and simple.
After three hours I was still hip-deep in "research" (that is, manically perusing StackOverflow and how-tos) on form validations and only starting to realize that maybe I hadn't approached this take-home in the best way.
In the end, I did have a fully functioning login page with all the requisite validations deployed and sent within the time-frame given, but I learned a lot about myself and about what I would have done differently for the next time around. So here I impart some hard-earned tips to other junior devs just entering the wild jungles of job hunting.
1. Ask questions
I sent a response thanking them for the opportunity and restating what day I'd send them the completed challenge, but I wish I'd taken that chance to include some basic questions about the project. Of course, I'd already asked all the questions I had over the phone -- until right after I sent that email that is. And then I was too embarrassed to tail that email with a "Btdubs I'm not 100% on this one thing" after already sending a super confident email like I knew exactly what I was doing. But I can only imagine how much more confidence I would've had if I'd just sucked it up and asked the questions that I'd had.
After getting the challenge and before you do anything else, prepare some questions to ask about the challenge. Even if you don't actually have any questions, you do. Think about what you need to do and get done, and if there's any doubt in your mind about what's expected of you, ask. At the very least, it's always a good idea to ask some clarifying questions about what you do know of the project to make sure everyone is on the same page. "Just to clarify, the challenge is to have a login page that does [this thing] and [that thing] and sent to you by next Friday the 6th. Is that all correct?
Asking questions is never a bad thing. It shows that you're paying attention and can communicate well with people, which makes you look good*. You'll catch preventable mistakes and learn better*. It even helps you better connect with people by being more likable*. If you take anything out of this list, let it be this one, and apply it to the rest of your career.
2. However long you think it'll take you? Double that
I took to heart the "2-3 hours" that my interviewer guessed it should take to complete. It did not take me 2-3 hours. I was working on it up to the deadline I'd given myself and my interviewer. I severely underestimated how long it would take me, and I constantly wondered whether I'd actually get it done in the time I'd given myself.
If you think something will take a few hours, give yourself a whole day. If you think it'll take you a day, give yourself at least two. And be realistic with yourself. Don't be scared to ask your interviewer for more time; they likely know that you're busy and might not have the time to commit. And, inversely, don't give your interviewer an unrealistic timeframe because you want to impress. It'll be more damaging to your application if you're late on an early-set deadline than whatever gain you might get by setting it early. But it's great if you give a later deadline and send it in early.
It doesn't matter how confident you feel about a take-home challenge, give yourself that extra time just in case. Things happen unexpectedly, and you don't want your first impression to a potential employer to be of someone who can't meet a deadline, even if you have a legitimate emergency. I think there's a good reason why Hofstadter's law is well-known in the programming community:
It always takes longer than you expect, even when you take into account Hofstadter's Law.
3. Hold yourself to a sooner deadline
In contrast to the previous tip, make sure you give yourself less time as well. Though I was working for longer than I thought on my first take-home, I'm glad I gave myself the deadline that I did. I had to finish by that time or else end up looking uncommitted and disorganized, but it also meant that it was done and over with before the start of a long holiday weekend. Instead of worrying and trying to get it done while everyone else was enjoying their time off, I got to send it off and join in without having to think about it again.
I know, I know. I just said to double the time you think you need, but that's only with the company you're interviewing with. Tell them you'll be done in 4 days, but hold yourself accountable for getting it done in 3. Don't cancel your plans to give yourself more time. Use your own busy schedule to hold yourself to an earlier deadline. If you think something will take you a day to do, give yourself two days, but do it in one.
Just as Hofstadter's law says it'll take you longer than you think, Parkinson's law says it'll take you just as much time as you give yourself to do it.
Work expands so as to fill the time available for its completion.
So if you give yourself a whole week to do it, guess what? It'll take you the whole week to get it done. Trick your way into giving yourself a sooner deadline while still giving your interviewer a later one, making sure you're covered in case of emergency (or, more likely, finicky code) and helping you look better by getting it done early.
4. Use examples you're given - Emulate the company's brand
As an example, I was pointed to the company's own login page. It was simple enough in style that I thought I could replicate it. I then went ahead and did. It ended up looking a lot more polished in a less amount of time because I wasn't thinking about what looked good. They'd already done that for me. I just had to prove that I could do it.
If you're given an example of what they expect, then try to get as close to that example as you can. Use the company's brand colors and logos. Try to get your code to behave in as similar a way to theirs as possible.
There is the worry that maybe they want to see how good you are with styling and design, but unless the job is specifically for design or UX/UI, I don't think that'll ever be the case (and if in doubt, ask!).
5. Don't focus so much on the "correct" way to do something
I spent so much time looking for the 'correct' way to validate a form. I constantly threw out ideas from articles and guide-throughs because they were too complicated, or not right for what I needed, or used too many extra packages that essentially did the validations for you (which was not the point of my take-home challenge). In the end, I never did find the "correct" way.
Look at examples if you need it to jog your memory or guide you, sure, but don't try looking too hard for how to make this feature or that. There are so many ways to program one thing, at some point you're going to have to pick a starting point and just start. You'll never find the youtube video that will write your take-home for you. That's not the point, anyway.
Plenty of people on Stack Overflow would disagree, but I will insist, for sanity's sake, don't try looking for the perfect way to code something. There is no perfect way. With take-homes, you're in a situation where you're trying to showcase your skills by making a small, sometimes incomplete project. Sometimes that actually means using a less convenient way to code something. So trust yourself and your knowledge and do it in the best way you know how to.
6. Test your code
This was something my interviewer explicitly asked for in their requirements of the take-home challenge. If he hadn't, I wouldn't have thought of adding a test in at all. I don't have much experience with testing, so I'm grateful it forced me to practice and think more about the way I wrote my tests.
Try to create at least one or two tests for all your take-homes, if time permits. And if you don't know how to just yet, take the time to learn.
Finding a guide to get you started can have you adding some basic tests to your apps pretty quickly. Knowing how to test your code is becoming something employers commonly require, even if it's not something that's actually used on the job. Even when tests aren't expected with your take-home, it's a good opportunity to practice while working with a small project. Plus, though it might not be expected of you, it'll always look better to include them than not.
7. Comment your code
As you code, make sure you go back and leave comments on what a function or component is trying to achieve and if you want to be more explicit, how it's doing it. Be clear and concise in your explanations. Pretend you're explaining to someone who only knows the basics of programming. Things that might seem obvious to you aren't always obvious to others. Don't try to guess what people will or will not understand easily. Assume nothing will be.
Comments aren't just for whoever will see your code but for Future-You as well! This is a good practice to have always, but it's especially important for take-home code challenges. Companies want to know how you code and what your thought process is. Comments make it that much easier for them to see that.
8. Stop doubting yourself
There were so many times I wondered if maybe I wasn't doing things the right way (see #5). I wondered what it meant that I was taking so long to complete the challenge. I wondered if maybe I wasn't as capable as I'd previously thought. In the end, I saw myself struggling and made sure I actually learned how to do what I struggled with. I made it a learning experience for validations. I took it as a chance to practice making forms, something I realized I hadn't done in months. I made sure I got something out of the experience and made something I could hold up and say, "Hey, I made this neat thing", not just a code challenge that would be hidden away and forgotten afterward.
Don't overthink things. Don't doubt yourself. Whether or not your code is good enough isn't up to you, it's up to your interviewer. Don't hold yourself back by judging yourself as inadequate before anyone else even gets the chance to. All you have to do is do what you can, show your best self, and let the interview process decide what your options are. Take-home challenges are a way to judge your skills, but they're also a great way to learn and improve them. Take advantage of that chance.
9. Don't spend too much time on it
This, I definitely learned the hard way. I spent way more time than I needed to, especially considering the 2-3 hour expectation my interviewer gave me. I spent an extra hour or two on styling alone, something I'm not sure was really worth it (unless they were to say it was, then yes, totally worth it!).
Spend as much time as you can to make the code-challenge one you can be happy to send back, but don't sacrifice time on your other commitments (and potential job interviews) to spend all week on this one. Don't expect that of yourself because most (decent) companies won't expect that either.
There comes a point where more time spent on the take-home will not be worth what you get out of it. Consider your circumstances: chances are you're in the middle of the jungle of job hunting. You have other companies that you're looking at, other resumes to fill out, and other people to connect with. There are only so many hours in the day. Sending back the best code you can code is a big factor in the interview process, of course, but it's not the only one. And if a project they say will take you a few hours takes you a whole week, then that's something to consider. You might end up with a job that expects too much more than what you can deliver, or maybe the company isn't organized enough to know what to reasonably expect from someone in a given timeframe. Either way, it's a good tell that something's not quite right.
Some of these lessons are things I wouldn't have ever gotten the chance to learn before my first take-home and some are things I knew but easily forgot to put into practice. Take-homes can be difficult and intimidating and confusing but they can also be fun and a great chance to practice and flex your skills. Plan ahead, expect things to go wrong, and just keep yourself open to learning.
Happy Coding!
- Asking for Advice Makes People Think You’re Smarter
- Asking questions, testing improves student learning of new material
- Asking Questions Increases Likability
*Photo by JEShoots.com on Unsplash
Top comments (3)
Great write-up! I especially connect with not trying to make your code perfect out the gate and focusing on having something that's functional. You can always go back and refactor, but perfect code that doesn't work doesn't do anything for you. I really like the sentiment from Ryan Florence on Twitter the other day highlighting that shitty code is necessary sometimes to get your product to market,
Thank you, this is a great quote! And yes, this is definitely something I struggle with, trying to make something perfect before putting it out in the world. It usually means I overstress and take way more time than needed, time that's best spent moving on to other, more productive things. (I will ignore how long this took me to see and respond to...)
The vague requirements are on purpose. They want to see how you react when given an incomplete specification. Do you use it as an excuse not to start any work? Do you make assumptions, document your justifications and proceed?
Also, I noticed many companies giving me "2-3 hour" exercises that would take at least a day of coding to do correctly. This can be a red flag that the company has no idea what the hell they are doing with their hiring process, or that they are going to hold you to insane deadlines right from the beginning.
I think honesty is crucial so I stick to their time limit and turn in what I have. I will document what I would have done with additional time and what I wish I did differently. Oftentimes, they act shocked I didn't finish and I never hear from them again. I take that as a sign that I dodged a bullet. I've had other employers start doing a code review of what I turned in and starting a dialog from there.