Tales of a Non-Unicorn: A Story About The Trouble with Job Titles and Descriptions (and a rant about FizzBuzz)


(Daniel Hollands) #1

I wanted to share with you an interesting article by Lara Schenck on her experience of a job description vs the interview:

At one point in the article she discusses the FizzBuzz test. This is something that I’ve encountered during a job application, but was part of a pre-interview test I had to pass. What upset me the most about it was I was told I’m not allowed to just use the “standard solution” found via Google, but would get brownie points for coming up with my own.

I remember having a very firm opinion on this, because to my mind, the standard solution - which looks something like this - exists because it works. Sure, the link has a couple of variations, but the code boils down to exactly the same thing at the end of the day.

Maybe I’m wrong, but I don’t see the benefit of something like FizzBuzz, especially not in the role that Lara went for, but not for any role. It seems to be the equivalent of trivia knowledge.

What do you think?


The proliferation of The Exercise when applying for a job
(Matt Andrews) #2

I saw this on reddit earlier – I think it’s too easy to give her a beasting in the comments (as reddit did) but I have to admit I was surprised that she says she’s got experience with complex JS frameworks like Angular but wasn’t sure how to format a timestamp etc.

That said, I’m no stranger to imposter syndrome even as a developer of seven years and given I came to it from messing about copy/pasting jQuery code and self-taught (eg. probably wrong) PHP, I know I’d struggle with some of the more traditional algorithmic problem-solving we sometimes get asked to do. I hope Lara doesn’t get discouraged from some of the replies this is getting.

Anyway, I’m definitely in favour of code interviews asking you to write stuff you’d actually do on the job. At my current place we have front-end devs write a JavaScript tab widget from scratch. There are almost no constraints/requirements so it’s very interesting to see how they approach it – some people go off and load Bootstrap/jQuery, others start installing bower/node modules and go from there. It still tells you if someone can program or not but also puts them in (hopefully) familiar territory, eg. building stuff for the web, not solving “classic” computing problems which non-traditional candidates may not have encountered.


(Daniel Hollands) #3

Hi, welcome to the community, why not come and introduce yourself.

It’s where I get all my best stuff :smile:

This is true of me, and probably a lot of other developers.

Me too. I’ve done several tests like this, and I think they’re a lot more useful as they’re closer to real world experience - where we do get to use Google to find out how to do things. Right now I have no idea how I’d produce a PDF using Ruby, but give me a couple of hours and I’ll find out (or, depending on what the PDF is for, possibly argue for a better solution to the problem being solved)

Here’s a tip, if anyone finds themselves completing such a task for an interview - use git. For one of these tests I used git to track my progress in solving the problem, to which the interviewer said he was impressed at being able to see how I tackled the issue from the outset (and simply the fact I was using git at all), scored me some major brownie points.


(Michael Brett) #4

I’m a little bit torn about this.

On one hand, I think FizzBuzz is one of those ubiquitous problems that you kind of, should have, at least heard about even if you don’t have a pre-prepared solution to hand. And even if you hadn’t, your solution (when you figure it out) could give an interviewer an indication of the depth of your JavaScript knowledge (as your link indicates).

That being said, does it really help an interviewer out? I have never interviewed for a position that needs JavaScript, but if I did - them getting me to do FizzBuzz for them would make me think the interviewer was a bit lazy. C’mon. FizzBuzz? Really? At least re-brand it.


(Max Woolf) #5

I have mixed feelings.

I’ve had a handful of job interviews in the past, everything from full-blown algorithm on a whiteboard tasks to literally no code at all.
The feeling I get in job interviews where they force me to write algorithms against the clock: Fear, anxiety, large amount of imposter syndrome. (“Why can’t I do this? Obviously it must be possible or they wouldn’t be asking me to do it?”)

There are much more important skills a developer needs imo. The ability (and hunger) to learn new technologies is a far rarer and valuable quality in a potential candidate compared to raw knowledge. Everyone can learn stuff, some of us just learn quicker or better than others. Questions like “What is a linked list?” or “Explain the concepts required to solve FizzBuzz” are more useful than watching me sweat in a job interview situation.

I think anyway. I might just be bitter since I’ve never been offered a job anywhere where I had to write algorithms against the clock. :wink:


(Philip Wattis) #6

In terms of FizzBuzz, I suspect they were looking for the ‘smart alec’ solution shown here:

http://rosettacode.org/wiki/FizzBuzz#JavaScript

But I prefer the version Daniel linked to. Why? Well the smart alec solution does appear more elegant, but from a maintainability solution I prefer the solution Daniel linked to. It’s far easier to see at a glance what it is doing. As a rule of thumb, the less code you write the easier it is to maintain, but not if the maintainer has to sit there scratching their head figuring out what it is meant to do.

The question that asks you to take a timecode string and return a number of seconds is just silly. I’ve written hundreds of lines of JavaScript over the last few weeks but I’d have to look this up, because I just don’t memorise all the functions of all the languages I happen to use. I suspect I might become the smart alec and simply present a function that returns zero. After all, he didn’t state what the reference point was and I didn’t hear the magic word ‘epoch’. Now there’s some lateral thinking!

Isn’t this normal across jobs of all types and sectors though? Publish a ‘junior’ role, attach a list of skills implying they are after a demi-god, and combine with a salary which I’d attribute to someone who knew nothing about anything.


(Daniel Hollands) #7

I think it’s less important to hire someone based on what they know now, and more important to hire on what they’ve got the ability to know/learn in the future.

That’s what got me my current job as a ruby developer - as a then PHP developer that had not written a line of ruby in anger.

(Ha, jokes on him, all I do these days is sit around drinking coffee. *slurp* :coffee: )


(Richard Cunningham) #8

I think the point of FizzBuzz is that it’s just a simple test to see if someone can code or not. It’s very easy for someone to “talk the talk” in a interview. It’s not good for either side if they get hired and aren’t suited to the job.

On Lara’s post, they shouldn’t be expecting her to do development for a UI/UX job, most likely they don’t know what they want and everyone involved the hiring is a developer already.

In my experience people are either a developer, who does a bit of design or a designer of does a bit of code. It’s hard to be an expert at both, because they are very different skills.


(Andrew Porter) #9

Maybe there’s something wrong with me but the ‘smart alec’ version is what I would have come up with and I genuinely thought I was missing something when I looked at all the solutions that did it with three conditions.


(Michael Brett) #10

Baader Meinhof effect - just saw this in my Feedly:

Pure CSS FizzBuzz


(Ben Paddock) #11

I think regardless of the role on offer, both candidate and interviewer should treat the process as day one on the job. After all - that’s what the person is being hired for - to work day-to-day with the team. With this in mind, I’m in favour of things like a pair programming exercise and/or show and tell of some prior work (where possible).

I think coding puzzles under a time period can put a lot of good people off - it’s not how anyone would work naturally.

I have to admit I have bias based on my previous experiences of what works well and what doesn’t. Different things for different personalities?

Whilst on the topic, I stumbled across a blog post that kind of related and may be of interest: https://medium.com/javascript-scene/why-hiring-is-so-hard-in-tech-c462c3230017