Joe Says: How to Conduct a Coding Challenge

The important stuff:

Our goal is to answer the following questions:

❓ Could the candidate produce working code if they joined our team?

Observing and discussing the process during which the candidate finds a solution reveals more about whether they can write code rather than how quickly they found the solution. That being stated we do expect a certain level of proficiency in JavaScript, HTML, CSS, and general programming knowledge. Is the code produced syntactically correct or sloppy or modern or dated? Is the candidate's knowledge predominantly tied to a framework or library?

❓ Can the candidate reason about code and problems relative to the our daily work?

Mistakes will be made, how did the candidate recover? Are the mistakes common or minor missteps or WTF? When a solution is achieved and we ask the candidate to refactor are they able to follow their own code or did they stumble onto a solution they don't yet grasp?

What our role is:

🎯 To set the candidate up for success.

Discussion is great, but time wasted on poor or intentionally tricky instructions is not. The candidate should never find themselves trying to decipher the challenge's acceptance criteria. If we don't move forward with a candidate we want to be positive it was because they were unable to perform to our standards and not because we set them up for failure.

👂👀 To let the candidate drive the discussion and work:

The test should challenge the candidate, but the candidate should not feel without guidance in solving it. We are here to help, to watch closely, and to be ready to answer questions or provide feedback to help them through the problem. However, it is important that we allow the candidate to drive the discussion and to engage with us at their own pace.

🙋 To interrupt only when appropriate

We assume all candidates have the required vocabulary and experience to understand and discuss the challenge, but not that they will do it precisely as we planned. It is ok to allow the candidate to explore solutions we know or think will not work. Don't interrupt someone writing code. If you feel you need to check in or to hear their thoughts wait until they've paused.

If the candidate seems completely stuck or there is no signal that they are making progress simply ask them if they'd like to talk through their current thinking. There are some "Potential Guidance" points for each test we may be able to offer.

The practical stuff:

Before the interview

• The candidate will be made aware of the logistics of the interview, sharing their screen over zoom, etc..
• The candidate will already have access to any accounts or software required because you told them in advance.
• Whatever gets us to coding fastest...

The Interview Agenda

• n minutes intro and setup.
• up to n minutes on the coding challenge. Sticking to this is imperative.
• n minutes for any follow up questions from the candidate.

Beginning the interview

• (0:00) Introduce yourself and others on the call
• Explain the the agenda
• Share the any required info, links, etc.
• (0:05) Overview of the challenge(s)
• Step briefly through any code or UI required
• Explain your role: I'm here to help!
• (0:10) Explain any hard rules: no added libs, can the candidate look things up, etc.
• Any questions before we get started?
• (0:15) begin coding challenge

Ending the interview

(1:00) Time's up.

This can feel awkward if the candidate struggled, but "We're up on time here, so we'll need to move on to any questions you might have for us." is perfectly fine. Answer any questions the candidate may have. Be honest and gracious, but no final decisions have been made at this time.

The challenge:

As an interviewer I always have a range of challenges and I suggest you do as well. Have more challenges than could be completed ina single interview. This ensures you get enough time with the candidate. It's also nice to let them know they can spend as much time on any challenge as needed, there is zero expectation that you'll complete them all. This can act as a nice stress reliever, there is no end or middle, the focus is on the challenge at hand and nothing else. There is no end... even if there sort of is...

I have an internal document explaining each challenge; structured like this.

🤔 Challenge #3

Fix the bug: Summary statement in plain english about a bug in the code.

- key symptom of the bug
- key symptom of the bug

👉 Potential Guidance
* Doing X produces Y, why?
* Reminder: you may want to look into key symptom #2.
* The core of this problem is solving key symptom #1 & #2

✅ Solution #3

... code ...

✅ Alternative Solution #3

... code ...

🎯 Potential refactoring questions
...
...

I attempt to identify probable solutions to the challenge, usually referencing any known caveats to a likely solution. I also identify helpful guidance for the candidate. This helps both the interviewer to assist without giving away the solution and can give the candidate both a nudge in the right direction and a reassurance that the interview is here to help.