> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase.

There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz.

If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things:

I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O)

String formatting

Modulus Operator

Nested-If statements (or equivalent--Matching, case/switch, etc.)

I'm not looking for production code. I'm looking for 10-20 lines of "A High School senior with a computer class could pass this."

This is not limited to programming, sadly.

I used to have to interview VLSI designers with "Draw me an inverter", and 70% of them couldn't pass.

To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent workers. And yet companies everywhere still produce software.

> What do these people do all day, if not design and build software?

Indeed this is a fascinating question, and I explored it a few times.

Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling.

An example is folks who work with large frameworks that are designed to be extended with little to no coding, such as WordPress and Drupal.

Then they want to advance to software engineering, so they recast their experience - of essentially configuring and deploying software, i.e. sysadmin - as "programming", and get those 5 years represented as "a full time programming position".

There's variants of that, basically "developers" doing very limited ant-work with large frameworks they don't understand and couldn't rewrite from scratch if their lives depended on it.

There's also a bunch of languages and frameworks invented for the explicit purpose that someone with little to no CS knowledge of programming talent could produce useful work.

Most of us here live in a bubble of startups where we often create products from scratch using lean (or no) frameworks. In reality, a scary amount of the "IT work" out there appears to be what I described above. Possibly a substantial majority.

How do I stop being a bottom feeder?

Cultivate programming as a skill.

Pick up a good introductory programming book. I recommend Think Python 2e:

http://greenteapress.com/wp/think-python-2e/

Go through it cover to cover and do all the exercises. All of them. Don't skip a single page or exercise, not even if you think "I already know this", and certainly not because it's too tough.

Once you're done, you should be able to start applying for jobs in whatever language that book taught you. If you're still not passing interviews, take on a serious - but manageable - programming project, such as some simple application for yourself or someone you know. If you're a web developer, a simple dynamic database-driven website is an excellent choice. If you want to do front-end, a simple Javascript game will teach you a lot.

You don't always have to apply for new jobs so early. Lots of tech shops have some teams where actual programming happens, even if most of the rest of the company is "paint by numbers" pseudo-programming. Often you can start to take on more responsibilities that involve actual coding if you show the necessary abilities. You won't have to change companies, or even change teams.

Good luck!

1) Selection bias

Good/excellent programmers rarely need to interview except as a formality. Consequently, you are, by definition, interviewing weaker programmers.

2) Tool use masquerades as programming

Visual Basic 4/5/6 was one of the original sins in this genre, but it continues now with other tools and frameworks. Being able to point-and-click a tool and plumb it together isn't programming--but people will claim it is. Then when someone asks for an actual program--those people fail.

This does not necessarily mean that those people are not productive. However, it does mean that they can't actually function in a position where they are expected to program.

It's because some large percentage of your time at work is spent in meetings, writing emails, discussing things, etc. where actual ability to do the core task isn't necessary.

And then some large percentage of "enterprise software development" is just hooking up buttons and text fields to a database, and doesn't require any more algorithmic complexity than a few if() statements.

And then some large percentage of the remaining work can be performed adequately by just picking some appropriate ready-made solution off Stack Overflow.

Put them all together and chances are, you can skate by for years (and actually perform acceptably) without ever actually needing to write FizzBuzz-level code for yourself.

It's not a big chunk of employees, it's a big chunk of applicants. Because the least competent apply to a lot more jobs.

"The emperor has no clothes."

It's because current tech interviews are a complete failure and none will admit it. In ten years you'll hear a new fashion and today's will be decried a failure.

The set of interviewees for a software engineering position is not really a representative sample of workers in the industry. Particularly at a company that doesn't have big name recognition, you're going to end up disproportionately getting job applications from the bottom sections of tech talent.

You may get only those questions in a junior interview. I get the optimize a graph algorithm ones also.

Now I certainly could do it in the course of a job within a week, with a day or two of research. But not under the gun.

That is the tech interview failure in a nutshell.

We always get these kinds of responses when interview testing is mentioned. This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. This is a simple test of basic competence. It's like interviewing a candidate Formula 1 driver and asking them "so which bit's the brake pedal?" If they can't tell you that instantly then they shouldn't be applying for the position in the first place.

> Please state your last exam conducted under such conditions?

University entrance exams.

University graduation exams.

Any other test that you do which you need to pass to enter or continue your career.

I don’t think I’ve ever been asked a “which is the brake pedal” level question in an onsite interview. Usually it’s more like I’m a mechanic being asked “how do you replace the water pump on a 1999 Saturn Ion, from memory, please.”

That's a benefit of the coding interview, actually. We don't ask you about that particular feature of some library from 10 years ago, which is basically a luck question: you either happen to know or you don't.

We ask you to code a simple task that you should be able to do in your favorite programming language.

Not entirely sure how the discussion of coding interviews veered towards obscure knowledge interviews - the former was expressly designed to supersede and eliminate the latter as one of its core goals!

That’s just it: replacing a water pump on a common used car is a task any competent mechanic should be able to do. But, possibly not without the repair manual. And, I certainly wouldn’t think they’d be able to describe step by step how to do it without the car or manual in front of them!

Likewise, many interview programming tasks can be are ones a competent programmer should be able to do with the tools of the trade accessible (namely Google and time to think).

Some simply are not. I was once expected to write, debug, and modify a concurrent chat server in an hour long interview. I do think that’s a reasonable programming task, but not one to be completed in an hour, under scrutiny. It’s the equivalent of being asked to rebuild a motor in an interview : definitely doable under real world conditions, but not a realistic test to determine whether to hire someone.

My last 'coding interview' consisted of a debugging a broken live VM, with a Java app waiting at the end of the rainbow.

The job was for working on bare metal provisioning using yaml and Python, but I could 'use your favorite programming language'.

Before you think this was some third-rate body snatcher, it's a more well-known name that you've heard of.

They still ghosted me, after telling me what an 'amazing' job I did.

Sounds awful. I'd be interested to know what startup it was. But it's no secret that some of the well-known names do tend to drop the ball on hiring and various other aspects of operations.

We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient.

It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then they haven’t been bamboozled by some acedemic algorithm problem, they’ve just shown that they’re not going to be able to write clean code unsupervised.

> they’ve just shown that they’re not going to be able to write clean code unsupervised.

The opposite, shown they can’t write supervised under the gun, which never happens On the job.

Exactly. I don't think they are accounting for how some people react to interviews. I've had candidates who have been explicitly nervous and stuttering, and we've consciously had to decide not to hold that against them. They turned out to be a great hire.

I think I can do okay in coding interviews, but only if I prep for that style of work first. It's definitely different. I'm perfectly (or at least acceptably) competent in my day to day.

If we’d ever had somebody crippled by interview stage freight, I make be able to take that seriously. The coding skills you need to pass our test is writing a for loop that mutates a dict. We’ve never had anybody forget how to do that in our interview, but we have had people come up with remarkably inefficient solutions to the problem.

I don’t think it’s reasonable to say that people’s problem solving skills (which is what we’re actually testing) become exponentially less efficient during an interview. But even if it was, the test is still doing it’s job, because what would we expect to happen when we give a person like that a deadline, or ask them to review a PR?

Don't need to be "crippled." Simply a shot of adrenaline is enough to shut down most higher-level thinking. At that point the candidate is just pulling things from memory at random hoping they fit.

> remarkably inefficient solutions

The first one usually is. As the problem gets clearer, better solutions become obvious. That takes relaxation and calm thought however, e.g. Archimedes in the bathtub.

> I don’t think…exponentially less efficient

Doesn't need to be a large difference. With multiple candidates, even 10% is decisive.

There's also the psychological factor of knowing something makes the "knower" think it's easy while the others believe it's hard.

I do lots of interviews as a contractor, and must say they have little to no bearing on my ability. In the real world I've solved every problem encountered, given some time. Interviews almost none, the few successes depend on whether I wrote the same algorithm in the last two weeks by chance.

A random throw of the dice at the craps table would be just as accurate and less stressful for all involved.

I’m actually on the job hunt right now. If your company is in the Bay Area, I wouldn’t mind an email.

Maybe as the first "smalltalk" question you'll get a brake pedal, but yes your Saturn-type question will be the "make or break."

> We always get these kinds of responses…

Perhaps you should start listening.

> This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you.

Happened to me just three months ago. The req is still open, wonder why?

To reiterate:

- Exams have a topic known in advance.

- Exams never have a person sitting there waiting for the answer.

- Exams are never 1 or 2 questions binary pass/fail with incredibly high stakes in unfamiliar territory.

Which is the brake pedal? If only.

We're talking about "basic fizz-buzz level coding questions". It sounds like you had a bad experience with something else that we weren't talking about.

(As for 'topic known in advance', I'd suggest that if you don't know what topics that you might be asked about in a job interview, maybe you shouldn't be interviewing for that job.)

There’s very little correlation.

You'll get bitter when the rent is due, watwat.

I had to twitch my feet to all three imaginary pedals to figure out the brake is the middle one. Even in this metaphor doing and knowing how to do are distinct skills.

You would fail anyway, because the interviewer thought it's pretty clear that automatic transmission was implied, not manual, since the job is about baking doughnuts.

One possible way to address this issue is by asking candidates to talk about some existing code you give them, rather than trying to cook something up off the bat while under scrutiny and not having access to their familiar tooling.