Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We do a fizzbuzz-like question, but one we created ourselves so it's not easily google-able or memorizable.

Anyone with basic coding chops should be able to solve it; it would be equivalent to a CS101 quiz.

It is still shocking how many people fail it. Yes, we have to test for it. My wife is in digital marketing, her -boss-, who insists on being involved in every decision, and will override her knowledgeable subordinates based on her own feelings, knows nothing about digital marketing (and is the reason my wife is looking to change jobs), but nevertheless managed to impress people above her (who also know nothing about digital marketing, but to be fair, don't have marketing related titles or roles) with her resume. Imposters in jobs are super common; it's just that in development we have easy ways to check for basic understanding. Unfortunately we try to scale those up to look for expert level understanding, and that fails (because we're really bad at testing for expert level understanding in areas we actually care about. That 'implement a red black tree' is probably appropriate if your company builds a data structure library as part of their core product, and probably inappropriate for almost anything else).



I wonder what would happen if you asked those that failed the fizzbuzz question what they DID know and wanted to demonstrate. The idea that there are flat out imposters who cannot code that have held coding jobs for more than a few months is ridiculous. Right out of college with no experience, I understand.

Have you considered that:

1. People have imposter syndrome, all the time. They're stressed out about being able to code, when running up against code interviews having nothing to do with the actual job they're doing. 2. People have anxiety, and they know how tough code interviews can be. They crammed and crammed and crammed, and 10 years of coding is now all this big amorphous blob in their heads. They're ready for some big systems questions. 3. People have bad days. The environment might suck. Their dog just died. You're a very adversarial interviewer, and they only work well and creatively when someone isn't going to come in and bully them about the response (or maybe they just imagine this)

Of course, you have no way of knowing this as an interviewer. But FFS, we need a way to inject some fucking empathy into this process. I'd say 99% of the time people aren't in interviews demonstrating what they know or can do, they're being asked to demonstrate what somebody else thinks INDICATES they have things that they know or can do.

I know the response to this is going to be, well yeah, but its Fizzbuzz! And I'd like to ask those people if there's ever been a point in your life that you wouldn't be able to write Fizzbuzz. To dramatize for effect, if someone came up to you and said they have access to your bank account, and for them to not take every bit of money you've made over the past year, including the money for your daughter's braces or something important, and in order to get it back you needed to make as concise and clean as possible an implementation of his variation on Fizzbuzz, you will not be thinking just of Fizzbuzz. Your brain is going to be churning at 1000 miles a minute, and you'll be trying to pull out every trick you know (out of hundreds) to get it as concise as possible, while thinking to yourself this is my future on the line.

Thats how I feel in interviews at least. I've always passed Fizzbuzz tests, but I've crashed and burned in interviews due to any of the above popping up on interview day. If we all could have a bit more humanity and understanding hiring would go a lot better.


"I've always passed Fizzbuzz tests"

You just negated your entire point there.

Yeah, you can have a bad day. I get it. We all fail interviews; I certainly have. Some I feel we really weren't a match (they were looking for a kind of developer that I wasn't, and don't want, to be), others I felt were unfair (for instance, interviewing with Microsoft years back, I had a C/C++ interviewer asking me questions that I had been told I was allowed to write in Java, and then disbelieving me when I told him (String).length is constant time so it didn't affect the Big O complexity that I had 'for (int i=0;i<(String).length;i++)', and clearly mentally checking out at that point). Obviously I don't feel any were because I wasn't, legitimately, good enough, but I also recognize I am very biased. But the thing is I also am in a place where I don't need an interview to justify my confidence at this point. I know I can deliver value. But I also know I will never convince the Googles of the world that I can, because I am neither a researcher of note, nor am I going to jump through the hoops of prepping for weeks on end for an interview; I have a wife, hobbies, and other, better ways to spend my time (even typing comments on HN! :P)

We first give people a take home. It's at their own convenience, we tell them it will be an hour and a half, coding, simple questions, to do it at a time they're comfortable. We don't stay on the phone, we tell them to use whatever resources they want (except, obviously, please don't try and google for the answers directly, or get help from others; it's simple enough that those who have tried to cheat have ended up with it being hilariously obvious, like leaving source comments that said it was by someone else, or variables for 'cat' when we never asked for anything related to cats, or being caught out during the whiteboard).

The interview is mostly a conversation. It starts with conversation. We talk about the position, the company. We ask about what the candidate is looking for, their resume, that sort of thing. Only after thirty minutes or so do we get to anything technical. We ask a few questions, and they're intended to be placeholders for conversation; plenty of right answers, we mostly want to see that the person is knowledgeable enough to discuss things. Even when we get to questions that have a right answer, it's mostly to gauge knowledge, and for the more complicated, even if a person gets it wrong, we'll tell them what the right answer is, and then ask them for a rational as to why. If they can figure out the rational, that's just as good as having known in the first place. Then we have a whiteboard question. It, too, is not hard. We tell the candidate "If you think there's a library function that will help, but you just don't remember it, you'd need to Google it, that sort of thing, talk it out with us, we'll give it to you". We try to help suggest things to get candidates unstuck. Etc.

Really, it's -not- a particularly antagonistic process. We really, really do want people to succeed (because, frankly, we want the position filled so we can stop interviewing and go back to work). So, yeah, if the interviewer doesn't manage the trivial coding tasks...we're going to pass. We -aren't- saying "this person is a bad developer", we -are- saying "this person could not demonstrate that they passed the bar of our interview process".

But there have also been some who have flat out said, even on the take home "I can't do this". Or those who have admitted when faced with the whiteboard question that they don't know how; that the take home had been done by someone else. Etc. Given those situations, yeah, our candidates are being given a take home, and a whiteboard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: