2022 10 27 Take home challenge

career interviewing

This is a more practical type of interview.
The company prepares a code challenge, that you do in your own time.
The rule is that you take 3-5 days to solve. Once you send it, the development team reviews the submission, and if your solution matches their expectations, then they invite you for a 90minute interview, to talk about your solution, do some live coding, and talking further about topis specifics to the position.

The goal of this type of interview, usually is to figure out in a practical manner how you code, and to know how much you can do pair programming, how do you solve problems on the spot etc.

Good for: * Finding in a practical manner how people code. * Have some code that allows for practical conversations to understand where the person is technically speaking

Limitations: * Setting up the code challenge, in a way that helps you find what you want to know is hard * Time investment: considering the stack is new to the candidate, the setup needs to be simple enough for them to quickly jump in and do something * Expectation management: some companies tend to expect the candidate to produce production ready code. However, a code challenge is something that candidates do in their own time, and should be solved in 8h max. Depending on the amount of work that needs to be done, producing production ready code might be setting unrealistic expectations * Room for interpretation: In some cases the ask is very open to the interpretations of the candidate. This can lead to having different expectations, the company might expect A, B and C. And the candidate might think A and B are enough and decide deliberately not to do C. The company ends up rejecting the candidate, even though they were able to do C and D. * It is still a code challenge: Some places tend to expect production ready solutions. However, this is a code challenge. They are missing the fact that what this actually helps to know, is how they solve a specific software problem within the bounds of 8h, in a setup and product terminology that is new to them. * Candidates might not be honest with regards of the type they invested on it: Many candidates will have the tendency to say that they spent less time than they actually did on the challenge. Doing this mostly comes from the desire to pass the challenge. When they do this, and you blindly trust this, without actually putting yourself on the seat of the candidate, you might end up with the idea the challenge takes less time than it does, and this might lead you to developed a flawed technical assessment. * Fluency with specific tools: Being an engineer in general is more about having the mental structured in the mind to be able to read and understand how different tools work. Many developers for example, are fluent with a specific tool, but being fluent with it is not an indicator of their understanding and fluency with software itself. So, a candidate who is not fluent with the tools that you provided, might build a less refined solution than another candidate who is more fluent with it. You might end up hiring the more fluent one, but you might be missing the opportunity to hire a good engineer who would pick things up very quickly and ultimately deliver more value than a tool-specific developer.

Challenges to overcome * Setting up of the challenge: it is important while setting up a challenge with regards to: * Delivery form: will you give and receive a zip file, a repository, a code sandbox? * Timeline: How long will you give the candidate to solve the challenge, and how you handle delays, or expectations with regards to this. * Problem to solve: What excersice will you give the candidate to solve, level of specificity of requirements, room for interpretation, etc. * Technical setup: Will you give more or less a ready app for the candidate to build upon it, or will you give a document, letting the candidate to decide on the technology? will the candidate have a command to run to install everything and just start working? or do they need to install other tooling in order to be able to start? Do they need to choose libraries to install to be able to solve the problem? or do they need to write vanilla code to solve the problem? * Documentation about the delivery: Building software is not only about writing code, it is also documenting and explaining solutions, trade-offs, and guiding others when it comes to reviewing code. In this regard, and as part of the solution of the challenge, the question are: will the developer need to answer specific questions in the delivery? not at all? fill a template? * Reviewing time and feedback giving: If the feedback is that the person didn't pass, usually is enough to just name the pros and the contras. However, when naming the contras as a reason for why the candidate didn't pass, usually what the candidate gets is a simple list with some words, but lack of explanation of why these things lead the decision maker to say it is not a fit. Communicating a rejection is part of interview experience, and this is often overlooked. On the other side, communicating why a person passed, is neither communicated. Giving this feedback might be useful for the candidate to explicitly know which items of what they did led you to find them as a good fit. * 90 min technical call: A practice for those who passed the challenge is to have a 90 min call to basically talk nerd. Live coding calls might be not intimidating, but also are time consuming for the candidate. What is the structure you will follow in this call? Will you continue putting the same skills of the developers under test? Are you trying to find flaws? Are your expectations that in these 90 minutes the developer does a production ready solution? or are you looking for structure of thinking, problem solving approach? Mentoring skills, pair programming skills, architecture thinking, etc? Basically, are you still trying to assess the same technical skills based on expectations to assess production ready quality code? or are you trying to figure out where the non-code-writing skills of the candidate are?