Unveiling the Coding Interview Mystery
Photo by Alexander Grey on Unsplash
Recently I’ve been thinking back to my history of programming interviews. I’ve been thinking about the classic which puts off many developers. That classic problem. Fizz buzz.
A Tale of Interviews
Many of us have been through the right of passage called FizzBuzz. It’s a classic test given in programming interviews.
The task is simple:
Print integers 1 through N, but
Instead, print Fizz if the integer is divisible by 3
Instead, print Buzz if the integer is divisible by 5
This is a task that dances on the fine line between trivial and revealing, especially since the candidate needs to print FizzBuzz if the integer is divisible by both 3 and 5.
A task so elementary, that it could almost be insulting. Yet amid the simplicity, the problem allows a candidate to show what they learn.
My Unforgettable Solution
Before you smirk, let me be clear: I, too, once sailed the sea of the average, where copying from the internet is a lifeline. But in the heat of the interview, I chose to walk a different path. Here’s a glimpse of my approach for one of my first gigs in the software development world:
Elegant? Perhaps. Overkill? Definitely. But your solution to a problem in an interview is to present your best possible programming skills.
It’s a pity during the coding interview, I presented this solution. I nailed the interview and got the job. However, as is typical for The Secret Developer I’ve a problem with this.
The Journey that Reveals Something More
Asking a candidate to complete the FizzBuzz challenge in an interview represents a worryingly low bar in the software development world.
We operate in a realm where the title of ‘programmer’ is both coveted and undervalued, bestowed upon anyone who can navigate the simplest of logic puzzles.
The issue isn’t about whether a candidate can solve FizzBuzz. It’s about what happens when we lower the gates too far, mistaking low standards for true competency.
Standards, standards, standards
Why Standards Matter
In the world of programmers, the line between hobbyists and professionals is becoming evermore blurred. We are all screaming for meritocracy while simultaneously lowering the drawbridge for all to enter without question - and that can’t be the rite approach.
I’m not advocating for a return to elitism. This is about recognizing the importance of our work and setting a bar that means candidates who make the grade can complete the required work tasks for the role to which they are hired.
That isn’t too much to ask, surely?
The Debate
We continue to debate the necessity of formal standards, qualifications, and associations in our profession.
Yet where the rubber hits the road we aren’t making changes. We do not have an interview process that correctly works out the competency of candidates who might work for any given company.
The Importance
How many of you Google for loops at work?
I guess this is far more people than most would assume. This is the type of stuff we need to have a filter for that catches out candidates who cannot complete the basics. We rely on quizzes at interviews and aggressive self-aggrandizement during work to mark out good coders rather than looking at their history and work quality.
Gatekeeping
Is it gatekeeping to desire a threshold of competence? If so, then let us be gatekeepers. After all, when we cross a bridge, we trust in the invisible hands of qualified engineers. Why should the digital frameworks that underpin our lives demand any less?
Let’s not dismiss the need for a foundational standard, a common ground where we can all stand, not as gatekeepers, but as guardians of a craft that increasingly shapes the world we live.
Solutions
I’ve already written a blog post about how I think interviews should be conducted.
The solution for this is (simply put) to create filters that find a candidate's strengths and weaknesses in the following areas:
Behavioral skills
Coding skills
Leadership
System design
Surely we can come up with a better solution for this than just giving poor coding questions to incompetent developers. Surely?
Conclusion
As developers, we wield the power not just to code, but to define the ethics and standards of our craft. Let’s not settle for the comfort of the familiar. Let’s dare to demand more from ourselves and each other.
Because at the end of the day, professional development is not just about what you know — it’s about what we can achieve as software development teams.