A Refactoring-Coding-Challenge Checklist
The Challenges of the Challenges
“Thanks so much for your time,” the interviewer says, the call ends, and the whirlwind of doubt and self-recrimination begins. Did you really leave that value hard-coded into 4 different places! Don’t you think you should have created an abstract class for that other thing…probably. Was that strategy pattern a bit too much?
Completely competent engineers do things (or leave things undone) in refactoring-coding-challenges that they would never put in a commit. In a typical coding challenge, you’re asked to refactor existing, poorly written code, so a substantial amount of focus is spent early-on just answering the question, What is this code supposed to do? Once you know, the next step is usually to start picking the low-hanging fruit: the triple-nested if statements, the mega functions, the variable named thing1.
To some extent, this is the right approach. You’ve got to address the most glaring issues. But at some point, when you’ve addressed the worst offenses, this approach will leave you hunting and asking, OK, where else does this code go wrong? Wouldn’t it be better to ask, What would this code look like if it were done right? That’s where a checklist can help you.
