Hacker News new | ask | show | jobs
by maehwasu 2588 days ago
+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them.

Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.

4 comments

I used to give a whiteboard coding interview (for a QA engineer position) that started with "swap the values of two integer variables. Yes, you can use a temporary variable," then went on to find the highest element in an array, then implement any kind of sort for an array, then implement depth-first-search.

People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it.

It is very true that you need to qualify someone's ability to write code at all.

I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program.

There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."

The best coding challenge for a hiring process I ever had happened, of all places, when I applied for a PHP development position at Fender.

At the time, their marketing department did all of their web development in-house. I don't recall all the specifics; there was a round table meeting between the manager of the unit, the team lead, and one of the senior developers. At the end of it, they sat me in the cubicle area with their other developers, gave me an MBP with MAMP on it, and a piece of paper outlining what they wanted me to code - a simple CRUD app. It didn't have to have any fancy styling, but it had to look ok, and it had to work. It was "open book" otherwise; use google or whatever other resource as you needed it. Also, all this happened while the other devs were in the area; it was basically a time slot from 2:30pm to closing time...

I'm thinking - really? Something this basic...

But given what you had to do - essentially from a blank slate, including the database, set up the tables, build the SQL, code the PHP, integrate the form to talk to the PHP "backend" and update things, refresh and show the updates, etc...

...well, isn't that basically what most software dev work is, at the core? And if you can't do any of that...

Of course I got the position, and worked there for a couple of years; not the easiest environment I've ever been in, but certainly very interesting.

During it, though, I got to experience, from the "other side" what I went through - and I was amazed and dismayed to see how many people were interviewed who couldn't do it. Who had what seemed like great resumes who couldn't even start. Who'd sit there for 2+ hours, and not type a thing. Who didn't even google up something, or ask a question, or...

We had one guy sit for a while, then just got up and walked out without a word.

As I read comments like yours, and others elsewhere, I can see that this is more common than not. You are right to believe that there will be those that will "memorize" fizzbuzz, which I why I think a challenge similar to what Fender asked for is a better test. I know that some developers would balk at it, but I think the time invested may be worth it, to show you are able to do the job, and can come up with your own solution to a problem, and not just some regurgitated answer.

Interesting aside:

A colleague of mine I had worked with prior, unknown to me, applied for the same position at Fender and was given the same laptop as I did. But they had forgotten to wipe it! He saw my code, and didn't know if he was supposed to expand on it or what; he told them "hey, this looks like my friend's code...?" - and they realized what they forgot. They thanked him for his honesty, wiped it, and continued on with the process. He also ended up getting the position as well.

>then implement any kind of sort for an array, then implement depth-first-search.

How have you not grokked how useless those questions actually are when it comes to knowledge about writing software? Those are both trivia in the same category as "implement the TCP acking mechanism".

Not my experience, as long as you're prepared to accept that people may need some prompting, and won't necessarily find the optimal solutions.

Someone who knows the 'trivia' may remember how to implement quicksort without actually being any good.

But someone with even a little bit of understanding and some prodding to not worry about efficiency will be able to come up with some sort of solution, even if bubblesort. If people appear truly petrified, it's easy to give them a chance by breaking down the problem and see if they can reason about it. E.g.whay if you start with a two element array? Then how about 3? How do you generalise that?

Someone with both the trivia and the smarts will give you a good solution and be able to muse about tradeoffs of different implementation methods, pivot selection and the like.

It's usually fairly simple to find out if people understand the solution they offer up and can reason about it, and that's often a lot more important than whether they come up with a great solution.

Re-implementing bubble-sort is, I think, a pretty reasonable fizzbuzz-style question. Can people think in loops.

Depth first search I would now be a little less eager to do (I was asking these questions ten years ago), but there were a few things that I felt came out well from it: if someone wrote something like:

if (DFS(node.left) || DFS(node.right)) return true else return false

That seems to me like it demonstrates at the very least some immaturity of how to write professional code. If the person doesn't know how to do recursion, that stands out. If they fundamentally don't know how to deal with a stack, that stands out.

If someone has never encountered DFS and just gets fundamentally stock on what the algorithm is at all, then that's, I agree, not wildly meaningful. But that was not, in general, a reason why people didn't get the DFS question.

EDIT: I will also note that I've had a couple of people on HN react with horror at the notion that someone might be asked to impelement DFS or BFS. While I agree that these aren't perfect questions, I think they're pretty radically different than some of the puzzle-y or impossible-to-re-derive questions that you sometimes hear about. The algorithm for DFS is:

1. Check to see if the input is null. If it is, return false. 2. Check to see if the input's value is the searched operand. If it is, return true. 3. Return DFS(left) || DFS(right)

Breadth-first is a tiny bit harder, but it's still a while loop on a queue and just test equality and push the children onto the queue. It's about ten lines of code and it's far from rocket science. If nobody ever taught you about binary trees at all, you might still be a great programmer. But if you're a good programmer, and you ever got taught about binary trees (which most people who have traditional backgrounds have), then you should be able to recreate those algorithms from first principles in, I don't know, 15-30 minutes.

In my experience, the sweet spot is anything that involves recursion or pointers, preferably in combination. You get some false negatives, but not tons if you don’t disqualify non-elegant solutions.
a series of easy-medium-hard to gauge where someone is at might be that 'sweet spot' - there's not one question that would cover enough, although I think fizzbuzz tries to.
What do you mean by Fizzbuzz? Normal fizzbuzz or the pointless overengineering fizzbuzz?
This is incredible to me. How can one get to senior or middle software engineering positions without the ability to write such trivial code?
It does seem incredible, but it happens.

One place I worked at, the company hired a developer who claimed to have a CompSci masters.

He was completely unable to code anything. I thought it strange.

I started to ask him some basic questions that any actual CompSci degree holder should be able to answer (and I don't have a degree in CompSci at all - everything I know I've learned on my own, from other sources, for the most part); I didn't make it like a grilling session, just polite conversation about a shared interest - but he either had difficulty, or couldn't answer at all.

He only stuck around a couple of weeks.

I've often joked that an interview question should be asked akin to "What basic logic function is needed to implement a computer? Show it's truth table, then design one in 2-dimensions on a whiteboard as a virtual 'rope-and-pulley' system."

Couple that with a random-style fizzbuzz-like challenge, and maybe a more difficult open-ended programming challenge (ie "build a simple CRUD app") - that would give you a good idea on their real skills.

Note: That first question I wouldn't expect many to be able to pass the last part; even the first two parts many perfectly capable developers would have difficulty with. But I would be disappointed if they claimed to have a CS degree and weren't able to at least tell me what it was and the truth table for it.

I once worked in a place where they wanted to hire a few contractors to help out, and I had to help phone-interview a few. I remember one guy whose resume claimed he was an expert in C++, so I simply asked him to tell me what a "class" was in C++. He couldn't answer.
shit, I'd have to look up NAND gates. also: that's EE, not CS.
There's actually two acceptable answers for the question...

I should note that my statements below may be FOC; I do not myself have a CS or EE degree, so take what I say with a modicum of salt...

But first, note that I wrote "function", not "circuit".

It could be argued that CS, on the whole, is a subset of mathematics, particularly that of boolean algebra and logic. As such, the functional equivalency between the abstract of boolean logic/algebra, and its implementation on a physical substrate, could be considered among the most important of CS concepts.

One could also argue (maybe?) that Turing's "equivalency theorem" might be related to such as well. Consider the case of an emulation of hardware done in software; one could consider that - at a base level, it is boolean logic expressed physically, being expressed equivalently as boolean software functions.

The opposite it also true, of course - that it is possible to express software boolean functionality in the equivalent physical form.

What form it physically takes does not matter (other than speed of course), which is why I also didn't ask for an implementation/representation in electrical terms or schematic form, but rather a diagram of something that could be expressed as a physical and mechanical object. If the person were so inclined, they could express it as a series of levers and marbles, or in LEGO, or Meccano, or any other similar option.

EE knowledge is not needed here, I don't believe (Martin Gardner might agree).

> One could also argue (maybe?) that Turing's "equivalency theorem"

lol wat

did you talk like this to the CS masters, no wonder they left

TechLead said it best IMO. If a developer cannot understand basic concepts like recursion, then they are in the wrong industry.
I think some just have outdated skills and don't know how in the environments they're faced with.

Sometimes people move between senior eng. and management positions and back depending on organization sizes. I certainly have had engineering manager positions where I went several years without needing to code for my job. If I'd stayed longer and not coded for fun, and then gone on to the type of positions I did next, which were much more hands on, and using different labguages I can imagine I might have found it hard.

Thankfully I've always enjoyed programming on side projects too, so staying up to date has never felt like a chore.

I think some people's typical coding is call one API, and then send the result to another API, or just print it out. They never need to write anything like a loop or logic.
It was incredible to me too. But it’s reality.

As another poster said above, best guess is some version of copypasta and navigation of bureaucracy.

Are there a lot of senior people who don't interview? Fortunately most of my candidates have been at least marginal, but the first couple of useless ones years ago were all it took to convince me that we can't ever skip coding questions.