Ask HN: Why is FizzBuzz more important than actual experience?

It's Joel Spolsky's fault. In his blog post on interviewing (http://www.joelonsoftware.com/articles/GuerrillaInterviewing...), he says:

> You’re going to see three types of people in your interviews. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions. At the other extreme you’ve got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever.

That one essay seems to have spawned a major fear in the industry of hiring someone who you might have previously taken a chance on. In an attempt to prevent what Joel warned us about all those years ago, the interview ritual has increased in complexity. We've since been advised that the coding homework and the whiteboard implementation of FizzBuzz are mandatory, and they've swept the industry.

> who write lisp compilers for fun, in a weekend

Ironically I've got that one covered in spades. :) But I may or (more likely) may not be able to do your puzzle on a whiteboard in front of you.

Perhaps suggest your concerns with the puzzle questions and maybe offer to talk more about your personal projects. I often have candidates talk about architectural decisions and challenges in such projects to gleam their effort and level of interest in the projects.

I attempt that but the line you always get is "well we have to do this so that we can compare all candidates equally".

That is unfortunate. Some of us do try to be accommodative.

I don't understand how fizzbuzz weeds out the maybes. It seems more like it weeds out the unwashed masses.

Yeah, it's designed to filter out the unwashed masses, though it should really be asked during the phone interview rather than during the onsite. A person who cannot demonstrate Fizzbuzz during a shared screen coding session doesn't need to be brought in for a half day.

But the point I was trying to make is that we've added a bunch of extra questions and tasks to the interview process in order to eliminate anyone who might not fit perfectly into a role. There is very little opportunity to realistically get hired into a role into which you can grow into. The fear mongering tells us that every new hire must be a perfect fit both technically and personally, or else the entire engineering department is imperiled.

Not every new question or task we've added to the interview process is very high yield. My recollection is that the advice to administer the Fizzbuzz question during an interview came along when there was previously no advice to establish a minimum competency in coding at the whiteboard.

Previously you might show up to an interview and one person would ask you to implement a linked list, another to ask you to reverse the words in a sentence, and yet another to traverse a binary tree. There was no standardized question to ask a candidate.

Then somebody came along and observed, "hey, y'all are asking pretty complex questions as your first question, but you can eliminate half your candidates with Fizzbuzz. Reduce the amount of time you spend watching awkwardly as a candidate tries to implement a random data structure! Just give 'em the ol' Fizzbuzz and watch the chaff your manager brings in wash out in the first 10 minutes!"

So, pretty quickly people started asking Fizzbuzz in interviews, and it's become as ubiquitous, annoying, and dehumanizing as open office plans.

But the overall trend over the last several years is one of fear of hiring someone who is not a good to perfect fit for a job. It's gotten to the point where a candidate must fit every bullet point on a checklist to even get a call from a hiring manager, must correctly answer every question fashionable question du jour, and now must be someone you would like to hang out with and have a beer with after work. Fizzbuzz is simply an imperfect tool for helping make sure you only hire the 10x day one it crushers.

Because all of us have worked with a ton of engineers who had a lot of experience but weren't very good anyway.

But companies insisting on quizzes instead of looking at free software projects you have is complete bullshit. It means they are not interested in your coding skill but instead are looking for something else.

It could be that they want to see you under stress and think that they can deduce some valuable information from that. Like if you lose your cool it means you are unstable. If you don't talk through the interviewers while solving the puzzle it means you are not a "communicative" person.

Or it could be that they have no idea if the test they are handing out is working or not. They need to calibrate it by running it through a hundred candidates so they can see what the mean and median scores to even know if someones test result is good or bad.

Just to be clear, I think everyone should be able to pseudo code FizzBuzz or strlen() in an interview because it is very simple and every engineer should be able to solve it in 10 minutes. But the tests I've been subjected to have been much more contrived. Like long multi-choice questionnaires or take-home coding projects that took many hours to complete.

If interviewers insist on me doing such tests I now refer them to my github profile instead. If they don't accept that as substitute for taking the test then the job probably wasn't for me anyway.

I would guess that searching through github profiles to decide how good someone is would probably take a while. Without understanding the context of the code it always takes some time for me to tell the actualy quality of it. Also some of the best engineers I've met haven't had much work in public on github. I think these sorts of gimmicky tests while terrible exist mainly because they are a one size fits all solution that doesn't take too much work and will filter out the really bad applicants.

I'm in a similar position. I get what I call interview fright. As soon as pen or marker touches paper or whiteboard. My mind goes blank. Literally my mind is scrambling how do I do a loop.

On the flip side I can sort of understand. I actually interviewed today. They had from what I saw 5 people interviewing today. 30 minutes a candidate, with 6 employees screening. Imagine how much source code they would have to review. In addition correlating that to a specific candidate.

Interviewing is an art. I think we're still ironing out the best way. The first person a director had marked the heck out of my resume and highlighted it. He knew what he wanted to ask, yet he let me lead the conversation.

When I lead interviews I asked basic syntax questions. Then what data structures you would use. Then the bulk was whatever was bothering me. I would treat the candidate like a co-worker. Come to them for a sanity check, am I insane is there a better way. I'll denote this only works if they're comfortable with you, they need to feel like your team mate. People hated me because id go over time limits....

I have been searching for the past four months. I get home I hit hacker rank or study. To say the girlfriend is unhappy is an understatement.

So these coding tests, are not fun. A lot of people have trouble with them. But you can work on them. After one phone screen, the interviewer asked are you done. I said hang on a sec. I reviewed my code and added exception handling, and fixed several syntax errors. That mindfulness helped alot.

Today I got to the ux ui director. They asked to see a prior project. Then engaged me about my design decisions. I essentially got a free consultation and it was amazing.

I'm long winded sorry :/. I'll close with this. I do dance improv, poetry slams, and open mics. I have to practice for each. It took ages to memorize a poem, and choreograph it. The interview is your audition. You have to know their script. Know their lines. Your going for the lead role, and you have got to know how to mesh with your partner. Bust your ass, it sucks but get the role and enjoy yourself.

I had that recently. I have 15 years of experience, and my brain completely blanked on explaining a left join.

It's embarrassing even to type it out, but it happens. Very rarely I also lose my train of thought. I think it's just being a human though.

I'm probably taking the question too literally, but do people really use FizzBuzz as a hiring test?

I only ask because until recently I'd never written a FizzBuzz program. I've seen it mentioned so many times that I thought I'd better give it a try.

Even for a mediocre JavaScript developer like me, it was trivially easy and took about 5 minutes. I would be astonished if it was used for hiring anyone other than the most junior/trainee roles.

I think you're probably using "FizzBuzz" as a euphemism for abstract coding challenges. Could you give some examples of the problems you are being set?

> a euphemism for abstract coding challenges

Yes. People seem to like to come up with their own "clever" versions.

Out of curiosity, I tried literally FizzBuzz on a couple of new grad candidates (my job is software, but we attract a lot of computer engineers). About half were able to do it without help. I no longer use FizzBuzz, but I'll use other very trivial questions to end an interview early if I suspect a resume has been significantly exaggerated.

This is fascinating. How close did the unsuccessful candidates get? Did you give them any hints?

Did you let them run their code to test it, or was it a pure whiteboard exercise?

For the successful ones, what did you ask them next?

  > I tried literally FizzBuzz on a couple of new grad candidates
  > About half were able to do it without help

So, one could do it, and one could not?

I work in embedded systems. We mainly write C. We ask candidates to implement strlen() in the phone screen. A surprising number are not able to. It's a very low bar, but still a useful filter.

Wow that is a low bar.

I've also asked similar questions for embedded roles. Lots of candidates can't implement their own strlen function. Most of my coding questions need 3-5 lines of basic C and lots of them struggle even if I give a couple hints.

It's very common. You can sit there talking yourself blue in the face about a legitimately difficult piece of work, and I can almost guarantee, one or more of the developers they roped into attempting an interview will default to it, or something similar.

Your typical developer has no business interviewing anyone, in my opinion, but there you go.

I think on a phone screen (which is typically something that is done in order to not waste everyone's time) something like fizzbuzz is fine.

It's very easy to lie about projects and to have some friends back you up - verifying all this takes time.

Simply having something that takes five minutes to be sure you are talking with someone who can actually code is worth it from a phone screening point of view.

I have only once asked this question in an actual interview. I had a "senior architect" in who told me he had led all kinds of projects but something just seemed off with him - he was very very good at steering the conversation away from the technical details of what he had actually done and instead talked in lots of generalities. The guy was supremely confident and likeable.

Sure enough, he couldn't actually code for shit. When I later asked how he got past the phone screen, it turned out that he managed to intimidate the (junior) engineer giving the screen enough (by implying it was beneath the architect to even answer such a question) that he managed to get a "pass" even though he didn't actually do the task we asked.

Some people are REALLY good at bullshitting.

> It's very easy to lie about projects and to have some friends back you up - verifying all this takes time.

If I were presented with a candidate (already somehwhat vetted) who claimed authorship of an open source project, I would definitely take a look at it, and then ask them detailed questions about it in the interview. If they hadn't actually written it, I don't think they could fool me for very long.

An example of what the OP is probably talking about (to make a huge assumption here) is an example I've used alot on HN:

> At an interview for a non-senior backend developer job on a CRUD app: "Traverse this binary search tree and provide the Big-O time complexity of your implementation"

OTOH, I haven't done too many interviews being young myself, but If someone claimed to have SQL knowledge, and I were hiring for that role, I would simply draw out two-three tables in a dB and have them do basic-intermediate tasks such as INNER JOIN. Or add an index to a given table.

Because there are too many really low skilled programmers who apply for mid- and senior-level positions. FizzBuzz is just a filter. We never asked FizzBuzz specifically at our interviews, but we asked to write a function to return a reversed a string. You wouldn't believe the amount of crazy that comes out of that one simple request.

FizzBuzz is not a puzzle. It's a very straightforward question, there's nothing tricky about it.

Your references are nice, but in many cases there's no easy way to verify that you wrote that code.

In our line of work and in our economy, there is no low-risk, low-cost way to legitimately match people and jobs. The standard is just a brief all or nothing interview process. You and the company are each taking a chance on immediately making a big commitment and marrying a stranger without ever dating or getting to know each other first.

Ideally, as a candidate, you'd go and work at a company for a short period, and once you can evaluate what it's actually like there and they have a chance to evaluate your work, then you would have a followup interview to determine whether to go ahead (and if so negotiate terms) or call it off. But that doesn't work well in our economy or with the way our companies are structured. So we're stuck with speed-dating.

Due to limited interview time, they throw puzzles at you and try to throw you off guard to see how you react to an unusual situation, and whether you can handle it. How you handle a crisis or bizarro unexpected situation is more important than knowing what you can do under normal circumstances or how you are normally. Not a pleasant answer, but one way of looking at the why.

As an interviewer, I don't trust references one tiny bit. I've literally asked you to cherry-pick a handful of people to say that you're good. I don't know who these people are. They'll either say you're good (which I expect, because you picked them), or they're stabbing you in the back (which I can't ethically tell you about).

Then there's the internal referral. These candidates are pretty rare. The first month you're hired you're likely to suggest anyone you can right then. After that if you're proposing them, you have a vested interest in them being hired.

Then there's the agency candidate. This person has been groomed by the referral agency to answer your questions. Once when I was hiring, we were asking candidates how to build a priority queue (a queue, where higher priority items were processed first, equal priority items in order). We interviewed 50 candidates, and 47 of them answered quickly and confidently that they'd use XML with XPath to find the next item. o.O

There's the open-source committer. I could spend a few hours reviewing your code, but that's time that I could be interviewing someone else, or actually getting work done. But then I need to make sure you didn't plagiarize it from somewhere. It's too easy to run a search and replace on a git history and slam the whole thing up on GitHub. I mean, I guess that shows technical chops, but poor ethics.

There's the long coding challenge. I wouldn't trust that. I've had coworkers actually ask me to do the coding challenge for them, because they didn't have the knowledge. I assumed they ended up getting someone else to do it for them.

Last is the credit-taker. This was me when I was young (we all have a past). I would over-state my involvement in the project, but because I did have a sizable role in the project and I was insatiably curious, I was aware of how the product worked and why design decisions were made. So I was able to answer any question asked by the interviewer. But was I actually able to build what I claimed?

On-the-spot coding challenges suck, but I don't see a better option out there.

I wish we could move to application screening based on portfolios, like architects, graphic designers, and copywriters. "Show me the soource code of at least one application you've written --- preferably two or three." I would pore over it (not necessarily reading every line) and I would know what I'm getting myself into. Unfortunately there is still too much fear that you would be divulging company secrets. Moral: Post some personal projects on GitHub or something, at the very least.

I have no portfolio. Almost every line I've written for the past 5+ years has been paid for. When I do code for fun, it's never my best stuff because I'm mostly either trying new technologies or it's not a particularly complex problem. This approach would seem to select for pretty specific set of candidates.

The current system is really easy. I prove to you I can code, we talk about technologies I like and things I've done, we talk about work style and bing-bam-boom I either get the job or not. And if I don't like the question you asked me in the interview -- why would I want to work for you anyways?

edited, if I could show prior professional code that he fine. But the level of Mon competes is staggering.

I've seen this mentality and I hate it. I have GitHub and a number of personal projects. But the projects that have full quality are private business ventures, in private repositories. Not to mention I have other hobbies. Before I give my GitHub I always stress it's a scratchpad.

My code on GitHub in a grade rating scale is under 50℅ an f. I get it running and that's it. For documentation, unit tests, that's on my private repositories.

I couldn't fathom approaching an interviewer with an NDA. I get enough flak for wanting to run my own business. Saying I'll show you my quality code, but you can't talk about it. That won't fly. I'd have less apprehension if so many companies didn't claim anything developed, on or off clock, is said companies property.

I wish we had an option to move more towards how other engineering disciplines handle a lot of these problems: standardized training/college course work (ABET accreditation being a major deal), licensure boards and procedures and certifications (EIT [Engineer in Training], PE [Professional Engineer], certifications in various specialties).

To a general (classical?) engineering firm (like my current employer), my two ABET accredited degrees mean a great deal. To most software companies they don't seem to mean anything, but at the very least I wish they meant "can handle a FizzBuzz". (A recent derail for me in an interview a couple years back was someone scoffing at me when I said "Oh yeah, I saw problems like this back in college" as if I couldn't possibly have... It is quite frustrating that the default seems to be that academic background and resume experience are "lies" compared to ability to run a puzzle gauntlet.)

In my current job I could get a small favor/title bump if I did all the hard work to get an EIT/PE after my name (and there is a Software PE now; unlike back when I graduated), but all that hard work would probably not be worth it because it wouldn't be recognized by most software jobs.

There's a chicken and egg problem here with jobs not trusting certifications because the certifications aren't common enough, or comprehensive enough/well suited enough for that particular businees, because no one gets certifications if companies won't hire them or won't privilege them at least enough to skip interview shibboleths like FizzBuzz and some of the puzzle gauntlets.

I recently hired a couple of people for the first time in my life. It was an eye-opening experience. Resumes are almost worthless. It's so easy to take credit for someone else's work on a resume. Write about all the cool stuff the product did when you actually just implemented some trivial feature. It's pretty easy to figure this out in the interview, but it takes time and sometimes you have to ask pushy questions.

Skill lists are almost meaningless. You wouldn't believe how many people claim to know C++ but start writing Java syntax on the board when you ask them to code something.

Basically, the problem isn't you, it's other people. It doesn't matter how good your open source portfolio is; the only 100% reliable way to judge someone's coding ability is to put them on the spot. There are too many "embellishers" in the world.

(OP): To be more clear, it's not FizzBuzz per se but the general idea. In reality it's always more complex than the original FizzBuzz problem (I've never actually seen something that simple.) It usually goes "solve this puzzle". "OK, now can you do it faster?" "I see you have a syntax error, what is it?" (Two minutes later, oh crap I forgot a semi-colon.) And then repeat all of that with three other people, each with their own puzzle.

It's easy, for me at least, to freeze up at any time in that process and stop being able to do anything at all, even if in a normal work setting it wouldn't be a problem. It seems rather ridiculous, or at least frustrating, that the job hinges on that process.

I've heard that FizzBuzz style challenges weed out a huge number of seemingly-qualified candidates. Interviews don't do that; it is easier to talk about being a good programmer than to be one.

Having a simple challenge (ideally less than an hour) seems appropriate under those circumstances. Ideally you use the simple challenge as a replacement for hours of stressful whiteboarding.

It's one thing to have a simple challenge to see if the person can write code but it seems that places put more value on that than anything else technically related.

It's only the first step in the interview. If you get past Fizzbuzz (a lot of people can't), they go more in depth about things that actually matter.

I've been past that step many times. It only means facing the same thing with multiple people while being stuck in a room with someone demanding to hear what you're thinking as you try to actually think and then hoping you don't freeze up at some point.

It is a sniff test to determine if you lied on your CV.

I personally suck at "whiteboard" coding too. I'd prefer they leave me in an empty room with a text editor and no internet connection for 10 minutes. But part of the exercise is discussing the problem and or showing your interpersonal skills.

Hopefully you'll find a different employer who interviews in a way better suited to you.

This. "Anything you've actually done or experience you have" is meaningless until you demonstrate it to someone I trust. I thought this was what Linkedin was going to do until everyone started adding random strangers.

I'm not sure failing FizzBuzz means you lied on your CV. I suspect that many programmers go straight into an environment where they never have to think about algorithmic problems (even algorithms as simple as FizzBuzz), because others have already developed the platform and all the low-level fiddly bits (like containers, string types and functions, etc.), and they just spend their days plugging them together (query this API, update this database table, call this method on the view class).

I have interviewed candidates like this (not web, embedded systems) who talked a lot about the in-house frameworks of their previous employers, and could sketch how they would solve a problem in that environment in hand-waving terms, but couldn't implement strlen() (which would be much closer to the kind of coding they would have to do in our environment).

I've no issues with challenges during interviews. The problem is that it is hard to make good ones, so you usually get a question with poor specificity. The more advanced the role, the more this is an issue.

For example, you could explain a problem involving database lock contention and ask the candidate how they would handle structure, indexes and queries to maximise throughput and avoid deadlocks.

Or you could give them an example schema and get them to "spot all the errors" without explaining that an error is anything that isn't in 3NF or higher.

One is going to give you a good understanding of the candidate's knowledge of the subject, the other is going to give you a noisy true/false signal.

FizzBuzz itself is not more important than actual experience.

What happens is in some cases people take it too far.

The point of FizzBuzz is a sanity check.

It's like asking a dental surgeon "How many teeth do humans have?".

If they hesitate before answering you don't want them performing surgery on you.

But I guess sometimes people bump the difficulty up step by step until it loses that ability.

As in, a really simple dumb question like FizzBuzz is more valuable because if they fail to do it that's a strong signal that you can depend on.

Sometimes people get greedy and make it more difficult so it loses its value.

I've never used FizzBuzz during an interview, but I see it as a "weeder" question, and I'm a big fan of weeder questions. I always start off with really easy (IMO) basic questions, and pose progressively harder questions as the interview goes on. I want to see at what point the interviewee starts the reach the limit of his or her knowledge, rather than lead with something really difficult that I don't expect more than half of the candidates to successfully answer.

The first few questions are weeder questions. I won't stop an interview if they blank on one, because I'll allow for nerves or a general brain fart. But if they blank on say, the first three really easy basic questions, the interview is over. It doesn't happen often, because those people are likely to get weeded out by the phone screen, but it's happened a few times. And it might not be 100% reliable, but it's good enough for my purposes.

First up, it's very hard to judge someone's experience from their resume. E.g. they might have participated in a project that seemed very difficult, but maybe their own personal contribution to the project was a net negative.

I know this is not PC, but coding is not a craft where once you reach a certain level, the rest is polish and experience. Good programming requires a certain virtuosity that not all programmers have (not implying this is genetic, please don't assume I am). People who lack this may produce ok code 90% of the time, but will invariably reach a point where the problem is too hard for them, and they come up with a bad solution.

This applies to working at a big tech company, where all sorts of interesting problems crop up. At an ordinary company or startup, I accept that this might not be so important and maybe these companies are copying the tech company's interviewing style for no good reason. Again, this may not be PC, but people at big tech companies get paid more (even given the location) so I think it's fair to assume their skillset is rarer.

When I interview candidates, I try to mix hard challenges with general coding, design and communications skills. My problems don't usually have a trick that you need to see, and sometimes, like fizzbuzz, they intentionally don't have a clean solution. But my problems are algorithmic in nature. You can see there are some interesting data structures lurking in the background even if they aren't directly applicable.

My reasoning in using these questions is that if a person can't solve a difficult, messy, but well defined problem, then when they encounter such a problem they will be stuck. I know there is a kind of dogma on HN that says that complex problems tend to be a result of programmers not doing the straightforward thing, but my experience is that 10% of the time the straightforward solutions don't work and you need something complex. That is, the flipside of "don't write clever code" is "be clever enough to write the code that is needed". If this sounds arrogant, please bear in mind that it's not usually considered arrogant to say that social skills are important and vary across individuals, so why should coding ability be different?

What has happened to this post? This was posted 3 days ago [1], and suddenly it's posted 1h ago? The same with the comments. For a second there I was freaking out because of deja vu.

[1] - (see this for proof - https://hn.algolia.com/?query=fizzbuzz&sort=byPopularity&pre...)

Short answer: It's not more important than actual experience. However, if you can't do FizzBuzz, that shows not only a complete lack of ability and a complete lack of preparation, in most cases it shows intentional deceitfulness. I will remind them that there exists a modulo operator and I will explain what it does as I understand that interviews are an inherently stressful process, especially for your first position.

Everyday HTML/CSS has problems that are more difficult than FizzBuzz. It's not a gotcha question, it's mostly there to see if you have actually written any code or if you are submitting a false resume.

Side story: I have witnessed someone with absolutely no coding experience get hired. He not only lasted, he was considered pretty good. His secret: he used Fiverr and some other services to outsource his work. I have to complement the guy. In the end, he completed his tasks and added business value. He wasn't looking for a career, he was just looking for a job that paid well so he could buy a car and move across country. In the end, no one was hurt and both parties got what they wanted.

EDIT: I'm assuming they literally asked about FizzBuzz. It is literally the apocryphal interview question and just beginning filter to see if the rest of the interview is going to be a waste of both of our time. I would assume that if you hadn't come across FizzBuzz that you have never coded before and/or it that you did no preparation for an interview. It isn't all about the difficulty, but FizzBuzz is almost as ubiquitous as "Hello, world."

EDIT Whiteboard Challenge: That said, I loathe whiteboard challenges during interviews. In the past, I've been asked how would I design a Mars Rover and control it from Earth so that it could complete its mission. I didn't know much about AI or computer vision at the time. However, it was for a mid/Senior level full stack position. I had no idea if this were an actual coding question or if he simply wanted to see how I approach problems. I went on about how I would first upload the most precise map data that we have on Mars for the days journey. Then I would make sure the navigational system was accurate by using onboard cameras. The cameras would be looking at certain topological features and how far away they were. If there were a major sand storm that changed the environment, we'd have a problem Houston. I went on about how the Rover would only be given instructions to move as far as can be seen from the original position since the camera feed was not live, but had a delay due to the speed of light. Next, it'd have sensors to know to go into clamshell or whatever mode if it detects a major sandstorm to protect the fragile instruments onboard. He still said he wanted more, so I totally bullshitted something about whether Mars was in its perihelion or not, I'd make sure the Rover only moved during the day etc.

After about 15 minutes of this, he said he was looking for the Rover to be implemented as a RESTful API and Houston would represent the client. I looked at him quizzically, said that was the worst interview question I've ever heard, and I think we're done here. When I got home, I did some googling and found that he ripped this as an interview question: http://stackoverflow.com/questions/185740/would-you-architec...

Now, I know that Microsoft Robotics Studio uses REST and, although I am well past whiteboard challenges, if anyone asks me to do one, I will politely tell them that its unrealistic and never the way I would first approach a problem since I never write code freehand. I frequently draw diagrams, concepts, actions, etc. on a whiteboard. I would be more than happy to actually sit down in front of a terminal, load up an editor and write code that I can get an actual output from. If you can't, then, from my perspective, you're basically asking me to code with one tied behind my back while blindfolded. If that's what you want, I hope you find it, but I am not the right fit.

I'm sorry, but your comment wasn't implemented in the form of a RESTful API and is thus invalid.

Man, that story is quite possibly the best example of why brain teaser style challenges during interviews are awful. I personally thought your answer was excellent and much better than I'd likely give on the spot.

I've had glowing references for candidates that turned out to be utterly and irredeemably unsuitable. References don't mean a darned thing unless you have at least some familiarity with the qualifications and motives of the people giving the reference _and_ are willing to talk to them in depth long enough to get the whole picture about the candidate.

I'm sure you'll be okay, but don't worry too much. If you couldn't solve the question in front of the interviewer under pressure and with their expectation that you'll be able to immediately code out the solution without thinking for a minute, then that doesn't mean you're not a good programmer.

It's not that I don't know I'm a good programmer it's why is a coding challenge more important than actual experience?

There are a lot of people who have actual experience, who can't code.

From the interviewer's perspective, how do I know that the code you present as experience is actually yours and not copied and pasted from elsewhere

At least in my case it's trivial to prove it's my code. (Or possibly I'm _really_ good at photoshopping videos of myself and have also spent a ton of time coming up with elaborate answers to every potential question covering tens of thousands of lines of open source code.) But for any sufficiently large project it's not that hard to figure out if the person actually wrote it just by asking a few questions.

I have a question. I've been learning to code a short time and I'll I've really taken a liking to sites like CodeWars that are based around coding challenges. Do you think I can honestly and successfully get a job through this? I'm located in the bay area

You should pair it with building personal projects as well, but I absolutely attribute my confidence in interviews to the time spent working up the ranks on Codewars.

Why not have some sort of standardized test like the SAT? That way you have a score that is valid for x years and you don't repeat the coding test every time.

Unfortunately, that's what academic credentials are for.

Only, you have to take several years off your life and get into debt if you're in the U.S.

And, not every company will value your credentials anyway (if you're an MIT or Stanford graduate, sure).

Many companies, from Microsoft to Oracle/Sun have tried to generate valuable credentials, and there are always people gaming the system.

Why do they make you do the coding exercises if you went to MIT or Stanford?

Maybe for regulatory aspects in the U.S. (deflect lawsuits or something)

Outside the U.S., my only experience with MIT graduates was them being hired on the spot. Almost no interview.

> I also have numerous open source projects with high quality code and actual products with actual user

Sounds like you've got a professional network that you can use to get you a new job instead of going through the front door with everybody else.

True but they also seem to enjoy watching you solve puzzles anyways.