Over the course of my job search, I've had a number of experiences with technical challenges, ranging from a phone call where I was answering questions and not writing any code to a self-directed project that took me about a week (not full-time) to complete (and many things in between). Most of my technical challenges have been as part of a phone/video interview (which is actually my preference), but I've also had some take-home assignments, and because of the variety of experiences I've had, I've developed some thoughts on what I think makes a good technical challenge (or at least what I've enjoyed about completing technical challenges).
Relevance
My favorite technical challenges have been ones that were clearly relevant to the position for which I was interviewing. For example, I had an interview where I was asked to parse a string and compare the string to known keywords. Based on what the company did, which involved an AI chatbot, it made total sense to me that work like this could be part of what they do on a regular basis.
While I love building a to-do app as much as the next person, unless I'm interviewing for a to-do list company (which actually seems like a great fit for me...), I don't see how it's a good test of whether or not I'm a fit for the position. And don't even get me started on any question that has anything to do with binary trees. I'm sure they're relevant in some situations ... but not for the positions I'm interviewing for.
The Right Format
To me, a good technical challenge is one that is given in the same format as you would expect to use to solve that problem on the challenge. If you're architecting an app, yes, a whiteboard makes sense. If you're writing an algorithm, I honestly don't understand why you would want someone to do that on a whiteboard when in reality they'd be doing all of their algorithm-writing in their favorite code editor.
Personally, I've never enjoyed a technical challenge or interview that involved coding on a whiteboard. All of my favorite challenges have been ones where I was coding either in a shared code editor or in the code editor of my choosing. Part of this may be because (thankfully) most of my whiteboard questions have been architecture-related, and I don't like architecture questions, but part of it is also that if I'm asked to write an algorithm on a whiteboard, it feels unnatural to me (because no matter how much I practice whiteboarding, I still do most of my coding on the computer), and that makes me nervous. I know that a number of companies favor whiteboard challenges, and I honestly wonder if they are getting an accurate idea of how candidates would perform on the job based on that interview.
Achievable Time Frame
Timing is a tough concept to address. The timing consideration for a technical phone interview is completely different than the timing consideration for a take-home challenge. All of the technical phone interviews I've done have been in the 45 minutes to 1 hour range, which I feel is very reasonable. For some interviews, I was given a task that I was able to complete in that time frame, while for other interviews I was given a larger task and told to see how far I can get. I'm a bit of a perfectionist and I don't like to leave things unfinished, so I tend to prefer tasks that can be completed in the given time frame, but I do understand the idea behind letting the candidate get as far through the task as they can, and I don't mind being given those types of tasks.
Timed online assignments are one of my least favorite types of technical challenge, but they're also not uncommon, so it's something I've had to get used to. For one company, I was given a 3-question, 135 minute test - and that was way too much for me. If I'm taking a timed test, I'd prefer for the questions to be smaller, more manageable parts, and I much prefer tests that are scheduled for no more than 90 minutes. I tend to break all of my tasks into 1 hour blocks (and often take a short break between tasks to grab a snack or stretch my legs), which I think is a reasonable amount of time to work on a task, but I think that up to 90 minutes can be reasonable - to me, more than that in one sitting is really asking too much from a person.
Take home challenges are a whole different animal. I've had take home challenges that I was asked to complete within 3 days and challenges with no deadline. I very much dislike challenges that have no deadline, if only because it gives me the opportunity to invest more time than I should into the challenge. At the end of the day, I'm not being paid to complete these challenges, and it doesn't feel fair to be asked to invest a lot of time when I could be doing other things that I am being paid for. My preference is to spend no more than 4-5 hours (aka half a day) on a challenge, but I'm too much of a perfectionist to submit a challenge incomplete, so I do reluctantly spend more than that if I think the challenge calls for it. While I'm not a huge fan of take-home assignments in general (I much prefer to code during an interview), the best take home challenges I've had were ones where I was told how much time I should expect to spend ("this challenge takes candidates an average of 2-4 hours") and given a clear deadline for when to submit my work ("please have something back to us by the end of the week"). I always set aside an hour more than the higher end of the expected time (just in case I'm extra slow), and try to have things done by a day before the deadline in case anything comes up last minute.
Part of The Interview Process, Not All Of It
I believe that technical challenges can be an important factor in the interview process - but I don't believe that they should be the only factor in the interview process. Yes, you need to know that the person you're hiring has the technical knowledge (or the ability to obtain the technical knowledge) that's needed for the position. But being a developer, particularly as part of a larger cross-functional team, is about so much more than just writing code - and you need to speak with the candidate to determine how they will perform as a member of your team and how they will work within your existing culture and change your work and your culture for the better. If you have a candidate who does really well on a technical challenge but doesn't seem comfortable with the way your team works, you may have to weigh that against a candidate who struggled with the technical challenge but will integrate well with your team - sometimes it makes sense to hire the candidate who struggled with the technical challenge and invest the time in bringing that person up to speed.
A Considerate Relationship
The interview process can be a huge time investment for the company, but it's also a huge time investment for the candidate. Both sides of the process should be considerate of each others' time. For the company, that means reasonable expectations for the amount of time the candidate should spend on a challenge. For the candidate, that may mean putting in the effort to complete the challenge to the best of your ability and in the time frame given to you by the company. It's also important to be up front about any delays - if the candidate had something come up that means they will not be able to complete the challenge immediately, they should notify the company, and if there's a delay in grading an assigment, the company should notify the candidate. I recently was given a challenge with no due date, but since I wasn't sure I'd be able to complete it within a week (which seems like a good maximum time frame to me), I emailed the company, and not only did they thank me for the update, they let me know that there would be a delay in the next steps if I submitted right away because someone was going on vacation and they'd prefer if I took my time and didn't rush to get it in before the vacation, which helped take some of the time pressure off of me. Consideration and open communication can make the process less painful on both ends. Whether you're the hiring company or the candidate, remember that there's a person on the other side of this challenge, and treat them with the respect and consideration with which you would expect to be treated.
Technical challenges and interviews can be terrifying. Over the months that I've been interviewing, I've learned that the best way to survive a technical challenge is to take it one problem at a time, trust yourself and your knowledge, and be willing to ask for help (whether that's from your interviewer or from Google) if you need it. Some technical challenges are more difficult than others, but at the end of the day, the company (generally) is not trying to trick you - they just want to see how your technical skills will fit in with their needs. Don't worry about being perfect or being the best - just do the best you can and present your best self, and if you're the right technical fit for the position, the company will see that from your work.
Top comments (0)