We've had a problem with candidates who seem impressive on paper and during the first phase of the interview, and then can't solve this exercise without being seen to glance at Google or SO results on camera -- or worse, being caught copying a worked example directly off the web!

There are plenty of people who can talk a good talk about technology but can't write a line of code to save their lives! Entire majors at universities are devoted to this; when I was in college, all the people who couldn't cut it in CS because math, fell back to MIS -- Management Information Systems -- whose courses had big colorful textbooks I call "Richard Scarry books" because they're packed full of busy-looking illustrations. MIS helps you learn about technology in a business context, but prepares you very little for actually doing technology and building the systems with it. The coding exercise helps screen out the people who can't actually do what's needed of a developer.

I guess people reach for leetcode because it's easy, but it misses the point of the coding exercise. The point is to screen out people who can't program at all, not to select for the programming equivalent of NES speedrunners. So it needs to be set at a very low bar and administered by forgiving interviewers.

To be clear, I am making the distinction between "coding exercise" and "brain-teaser". Brain-teasers are not useful in an interview context, and only result in adding stress to an already stressful situation. Simple tasks like "Write a function that rolls two dice and calculates the position of a game piece as it moves around the edge of a game board" are much better. I am not looking for the candidate to give me their masters thesis in a piece of code on demand, I am looking to weed out candidates that clearly don't have the skills to fill the position.

There's a lot of good here.

Do companies have bad interviews? Yes. Is it because they ask stupid trivia questions, demonstrate stupid biases against races, genders, ages, and nervousness, or otherwise don't have a rigorously meaningful process? Yes. Is interviewing stressful? 100%, and every interviewer should be cognizant of and prepared for the intensity of that stress for some people.

But saying that software engineers shouldn't have to code in an interview is always going to sound absurd to me.

> A live coding exercise often has little to do with what the candidate's output is like on the job.

That's not an argument against live coding exercises. It's an argument against ones that aren't representative of the scale of expected work given the available timeframe and the position's responsibilities.

There's a parted Red Sea of difference.

There isn't to my knowledge any other way to demonstrate ability to perform that can be completed in an hour or less. That isn't to say that there are no other ways to evaluate someone. Certainly one could completely restructure their business around zero-onboard few-hour contract jobs, but that's really an untenable degree of accommodation if we're looking for something that can be applied broadly. Is there yet another way? I don't know. I can't think of one, and the author doesn't provide any useful insight.

Do you know what a senior engineer in the US gets to do after they're done demonstrating competence though? They get to make a shit-ton of money compared to everyone else on the planet except for drug lords, investment bankers, and Dwayne "The Rock" Johnson. We're talking Scrooge McDuck swimming in his money bin money compared to approximately 100% of all people on the planet. All they have to do is put on a t-shirt for an hour or two and show that they're halfway decent at their profession.

Maybe that's worth some performance anxiety for a few miserable fucking hours and then they can go back to tweeting or binge-watching Ted Lasso or whatever it is that stressed people do to unwind these days. Does that privilege people who are better at demonstrating themselves? Yes. That is always going to be the nature of demonstration. But if they fail, there are a thousand more tries ready and available right now. And if they can't do better after a few...well...nobody wants to hire someone who doesn't improve when given the same test over and over again.

> Why are you giving Senior Engineers coding interviews anyway?

Because most so-called engineers quite frankly really suck.

> Do you really think someone who has been holding increasingly more demanding jobs over the past decade or two was faking knowing Python the whole time?

Uh. Yes. I've seen way too many "senior" bombs, and this is definitely the reality. Many if not most people who call themselves software engineers are actually very bad at what they do ranging from being utterly incapable to just not caring about quality. If that's not you, show it.

> If you say to me "tell me about a time you dealt with an unusual networking problem and how you resolved it" I'm going to tell you a way more detailed and interesting story about Dell Optiplex 2x0 boxes that all had the same MAC address when their Service Tag was cleared.

If you let me contact your previous/current bosses _before_ the interview, then I'll gladly let you tell me all the stories you want. Otherwise I think I need to be able to see how you perform. And, yes, that also includes seeing if/how you perform with pressure.

Look, I'll plan, architect, code, document, and mentor circles around 99% of my peers and also be the life of the workplace that everyone enjoys interacting with, but ask me for a story about something I did one time and I'm going to stare at you with an eyebrow raised for a few seconds before saying "Sorry, I don't remember or even care about what I was thinking 30 seconds ago let alone before that. Are you hiring someone who builds software or someone who tells anecdotes? Perhaps I can solve a problem for you." And if I a person thinks that they'd rather have a story than a demonstration, then that's their mistake to make, and I hope they find someone who tells very good stories after the fact. Maybe I've just solved so many significant problems that none of them are memorable anymore. Maybe the thing that makes me so good at solving problems is that I reserve all of my neurons for solving and don't waste neurons on remembering.

> Take-home quizzes are dramatically less anxiety-inducing for a lot of people (myself included).

Take-home quizzes also don't show anything about how well you perform. If I build a take-home quiz that should take a reasonably competent person 30 minutes and you spend all night on it, or worse ask a friend for help, then what? How do I know? Honesty? HAHAHAHAHAHAHA.

> Why bother asking a question that tests someone's ability to retain information for 12-24 hours?

IMO that's not consistent with the immediately following paragraph suggesting that you should ask for "tell me about a time when" stories. You either care that they retain information for some period of time or you don't.

At least twice been invited to interview for roles that were not hands-on-keyboard roles, yet the entire interview process was coding activities. That's the kind of thing that drives me nuts, as it makes it obvious that the company doesn't even know what they want to hire. At least one of the times was a company that shows up on HN as a "darling", which makes me even angrier...

In my technical interviews, I look to talk through specific technical problems, and they're usually real-world bugs or design issues I've worked through in my job. There's not usually a lot of code involved, and the code isn't that tricky. It doesn't usually even rely on too much specific domain knowledge. It's about being able to take a broad technical question, formalize it a little into something concrete enough to be discussed, identifying constraints on the solution, working towards a solution, reasoning about performance, and discussing tradeoffs of this approach vs. others. In short, it's about technical reasoning. I don't care if we get to the right answer by the end if we've had a fruitful technical discussion.

Code samples are a good idea, but they're as deeply problematic as interviews. Most of the code from most of the best engineers I know is closed-source, not on github. 48-hour programming projects can tell you what someone can cobble together, but they don't say anything about the person's attention to longer-term concerns around design or code quality. Moreover, being able to code up a technical solution to a 48-hour problem is like basic literacy: I expect at least that, but I really want to find people who can make forward progress on the uncertainties associated with a 3-month project, at least.

If candidate lists lots of skills/experience, I do a self-assessment where I get them to claim that they're really good at something, then ask them to do something that requires bare-minimum skills in it. The idea is not that they need these skills to do the job, but that if you claim a CS degree, eight years work experience, and being a python expert, but you can't crack out a basic, non-trick whiteboard coding exercise blindfolded, something smells bad.

If a candidate doesn't have much experience, I'm trying to figure out just how green they are; low-experience candidates cover a huge range of skill all the way down to knowing literally nothing but a few buzzwords. If you don't know a language or a library or a technology I can teach you, but if you don't know anything it's going to be years before I can get anything shippable out of you.

I wish these weren't a major worry but the majority of people who come in the door (after a resume and phone screen!) don't pass.

What do those of you who are doing intensive whiteboard-coding interviews think you're getting out of it?

The difference is that a candidate with a good attitude and growth potential is usually worth hiring even if they're not a fit for the role they applied for, and so the hiring manager will get creative trying to make something work.

Perhaps some of the well known tech companies don't put the same level of care into their interview pipelines, and then folk become jaded and irrational? Does anyone remember that Office episode where Ray Romano interviews for the manager position and talks about how all his old coworkers are jerks while eating a sandwich out of his briefcase?

Yes, I get that a whiteboard isn't an editor, and you don't have google/SO, and some people just freeze in an interview, but I've long ago stopped assuming people can code just because they've got coding on their resume for successful companies. (For all I know at the interview moment, they didn't have a coding role, or may not have even worked there.)

However...

99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.

That does not work for us.

We must put each and every candidate in front of a keyboard, and bang out at least a little code.

We had one candidate, recently graduated with an MS in CS. Nice personality, good talker in general. The candidate seemed to understand CS and could explain how to solve problems.

However, even with repeated prompting, I could not get this person to even type in a loop to start to solve the problem presented.

We've interviewed multiple candidates with a BS in CS or similar who also spectacularly failed at doing even basic coding tasks.

Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.

As a person who recently interviewed and got offers, I cannot say they don't ask coding questions, they do. But points are given to solution methods, clear and concise thinking.

People mostly making coding interviews as bogeyman here. Meanwhile experienced engineers already have required mindset to tackle problems.

For instance, I never read specific interview/algorithms books. Because, at the end of the day if you're gonna memorize these stuff for the sake of memorizing (or passing interviews) you'll forget them and not really use them.

My experience lines up exactly with what the GP said. The overwhelming majority of experienced engineers that are interviewing simply can't write useable code. I understand it's hard to believe, but it is the reality whether you believe it or not.

Now I can see why it's easy to disagree with interviews that check your algorithms 101 knowledge: that stuff is really really rarely used in real-life and you can just google it if you ever need it. But! Keep these in mind:

- Can you come up with a better process that scales with the number of interviewers in your company, but also maintains reasonable consistency and keeps reasonable costs? Maybe you think you can, but keep in mind that the tech giants have data-crunched their interview stats over and over and this process is what they stuck with. (Of course, with scale there's also the problem you occasionally have arrogant interviewers - but I think that problem should be decoupled from the coding/non-coding interviews problem).

- In places where they look for A* engineers, the point of the interview is often not to test what you know best, but how you get along with problems you have never seen before. An algorithm or data structure question often fits the bill.

- Geeks love geeky puzzles (like inverting binary trees). Companies often look for geeks in love with abstract stuff.

Also, IMHO, knowing only one language is a red flag for me too at 10+ years experience level.

But I see no other way to test if the person is competent than sitting them down with a problem to solve -- if only to have them explain what they do and don't understand, and what their process is.

There are multiple ways to "become really good at programming".

A company of any size needs people who can churn through well-defined problems quickly, and most live coding tests are relatively well-suited to selecting for that. They also need people who do other things well:

* tackle large, ill-defined problems, alone or in a small team * identify, triage, and (if necessary) solve problems as they emerge * refactor existing implementations that have outgrown their initial architecture * identify trends and estimate when they will lead to scaling issues in the future * communicate complex problems to people without the necessary context * break down complex solutions into discrete, well-defined steps that can be tracked to completion

They also need people who can accurately estimate how long all of the above will take... unfortunately, as we all know, such people do not exist.

If you're hiring someone to churn through well-defined problems, live coding interviews are likely a good fit out of the box. If you're hiring someone to reinforce a weakness in your organization's ability to do any of the other things above, live coding exercises are at best a loose framework that we're all familiar with to try to get at whether or not they have those skills.

Second, and more importantly, a coding exercise during an interview is long, long way from working in a startup, or working of pretty much any kind -- unless you've somehow managed to find a way to get paid for solving toy problems. I've done both, and both are hard, but in different ways. To use running analogies, working in a startup (in my experience) is a relay: you have a team, each of you is carrying your own respective bit of the endeavor, but the success or failure proposition is net across the team. In an interview, you're running a sprint, and all eyes are on you, and you alone. One feels completely different from the other, because it is.

Also, half the times (for a sample size of two) I've been asked to do a code exercise during an interview, the interviewer realized halfway through the exercise that he'd misrepresented the specifications of the widget I was supposed to make. The plural of "anecdote" may not be "data", but I've seen and heard, and can conceive of enough problems with the practice of interview coding exercises that I just can't trust them for anything more than exploring how a candidate approaches programming: the way they think.

So if you've been successful without this ritual, you have my attention. But what (if anything) are you doing to see if someone is good at writing software. Do you know the candidates you interview already, by reputation?