I have interviewed many people for programming positions. Some could write apparently reasonable pseudocode, but never actually convert it into working code, even in the language of their choice. A worryingly large number couldn't write the simplest routine to perform trivial tasks, even in the language of their choice.

Some of the above claimed to have 10 years experience in the field.

There's a lot of push-back against requiring FizzBuzz, and I understand that. So the approach I took was to say - "Let's start with a simple FizzBuzz routine and we'll discuss some issues that arise from it."

But you get complete jerks in recruiting, just as you actually get complete jerks everywhere. If you don't like the atmosphere the recruiters/interviewers are creating, would you want to work there? You need to assess how representative these people are of the company as a whole.

In the end, it's up to you. Sometimes to accomplish something you simply have to schlep[0], put up with the tedious and annoying for the sake of accomplishing your goals.

[0] http://paulgraham.com/schlep.html

I code screen everyone on a laptop using their favorite tools - I want to see how they work, how they debug, how they solve problems.

Some engineers can talk a good game and can't really code at all, or they're cut-and-paste programmers who can only solve a problem by finding 80% of it on Stack Overflow...

Coding tests give the appearance of an objective interviewing process, but I haven’t seen evidence that such tests have predictive value. People who don’t perform well don’t get hired, so their possible contribution remains unknown. I have not seen companies track coding test skill and correlate it to job performance. Mostly these tests give the subjective and often irrelevant hiring process a veneer of rigor and objectivity.

In many, if not most, interviewing and hiring situations the candidate’s personality and presentation will have more effect than technical skills — we form impressions of people in a few seconds. Coding tests look like the main decider but human nature tends not to work so rationally.

The proliferation of books, web sites, classes, and bootcamps for technical interview prep demonstrate Goodhart’s Law: job seekers optimize for the interview rather than honing job skills and learning business domains. Interviewing well has obvious value for getting a job, but doesn’t necessarily predict adding value to the business.

Companies want people who can (at least appear to) immediately write code. Employers rarely invest in training or mentoring, there’s no apprenticeship path into programming for most of us anymore.

In 40 years programming I can’t recall ever having to invert a binary tree, or find a cycle in a linked list. Understanding basic data structures and algorithms has value, but companies don’t lose money or go under because of those kinds of things.

Sadly I find that trivial tests like FizzBuzz continue to work at weeding out a shocking number of people who simply can’t write working code. That says something about programmers at all experience levels: an inability to translate requirements into code. Employers should focus on identifying that ability, rather than mastery of technical arcana.

Thanks for your post I found it really helpful.

I had to do a coding take home test after 15+ years of experience.

The market is what the market is. You could turn down any interviews that require you to take a coding test and see what is out there.

I appreciate that going through hiring process is challenging, and it is stressful and time consuming to need to prove or demonstrate yourself again and again in a process that can be rather artificial and seem unrelated to the job, often while getting negative feedback.

On another hand, think about it from a company perspective: maybe 100 people apply for an advertised role. 25 might be excluded based on CV. Remaining 75 are phone screened and given coding tests online. 35 might be excluded based on that. 40 invited to proceed to on site to interview. 5 out of 40 candidates might demonstrate reasonable ability during on site interviews in terms of actually being able to write code, and demonstrate some problem solving ability, and some familiarity with common data structures, and not have obvious red flags about how they relate to people. Two of these 5 candidates who gave a strong performance drop out due to competing offers, one runs into visa issues, remaining two offers are made and accepted.

Some candidates will apply for roles with no relevant experience, some candidates will demonstrate no ability to program in their preferred programming language during on site interviews after doing well during an earlier remote coding test (e.g. they got a friend to sit the test for them), some candidates have 10 years commercial experience but cannot assess when to use an array versus a hash map.

This might boil down to something like 150 - 200 hours of human effort, much of this engineering effort required to assess engineering ability, to identify a single candidate who is a strong fit and goes on to accept an offer.

From the company's perspective, the company has an imperfect hiring process. Sometimes candidates have a rough day, freeze under stress and don't perform well during the interview- even if they could be a good fit for the job. Sometimes the hiring process emphasises measuring things that aren't necessarily the most important things for the role. But it costs the company a lot more money to hire the wrong person versus missing hiring a person who's a great fit, so it's probably the right tradeoff to bias the hiring process to reject more often than accept, and risk rejecting a number of candidates who could have turned out great.

You are taking a coding test because the recruiter cannot evaluate you based on a conversation. Even if they were talented enough to be able to, they are not trusted enough by boss / client. The money they make is so good for recruiting a person, it drives a lot of people to push for people who cannot do the job, just for the commission.

<Story Time> A few years back I was looking for work without much luck. Finally I get a call from a head hunter that wanted to place me in a contract. It was short duration, only a month, but as much OT as I wanted. Pay was also very good. They wanted a DB guy. Although I am mostly coder, I do love DB and am more talented at DB than you typical coder. Digging deeper I found out they wanted someone to work at hardening (defense) the DB from intruders. Well that was well outside of my skill set. I refused to take the job as I knew the actual customer would not be happy, and I did not want a reputation for claiming to do stuff I was not capable of.

Majority of coding tests are extremely unrealistic anyways and you never use any of it in real world. Let's say some fizzbuzz or fibonacci or whatever else. I've only had 2 realistic interviews where they ask you to code some microservice or create some app and present it to them. They also make the excuse "I want to see how you think" but let's be honest in real world you would Google and try out bunch of things until something works for lets say some CRUD app you are building and you barely ever use any "logic" to build something, so don't stress about it.

No, writing throwaway code is a waste of time.

Seeing how someone drives an editor, IDE or cli is often a strong indicator of how good they are... Watching people arrow around in vim often gives me all the information I need when interviewing...

One of the top two or three developers I've ever known used arrows in vim.

Turns out that vim or any editor usage is only a (poor) signal and does not inform an observer on a candidate's product knowledge, arcane technical knowledge, past successful launches that a candidate has led, or helps glean any insight into the zounds of hard won battle scars in project design, system design, networking, concurrency, state management, etc.

Yeah how dare people use the keys specifically design to move around a text editor! Just use hjkl like they did on some machine decades ago because it had a limited keyboard.

The ADM-3A terminal on which Bill Joy developed vi had cursor control keys, ctrl+hjkl.

https://en.m.wikipedia.org/wiki/ADM-3A

I agree that vi/vim mastery or choice of editor has nothing to do with programming skill.

“Hokey religions and ancient weapons are no match for a good blaster at your side, kid” — Han Solo, condemning Luke’s use of VI

I read this as "hotkey religions" which actually fits haha

Han Solo was killed by a hokey religion and an ancient weapon.

Oh I love that number pad. And the whole thing is pretty stylish.