Let me answer that with an example. In my previous job, I had to implement a simple username/password based authentication API in the first interview. The problem was explained to me. A two page document with a written specification of the problem was also provided to me. After I read the document, I was asked how long I would need to solve the problem. I asked for 40 minutes. Then the interviewer left me alone in the room with a laptop. After 40 minutes, the interviewer returned and went over the entire code I had written, discussed the API design decisions I had taken such as the corner cases that were handled or not handled, exceptions that were thrown, how empty or null usernames or passwords were handled, what error messages were generated, how concurrency was handled, what performance problems could occur if thousands of requests invoke the API per second per thread, how the password was secured, etc.

After I got the job, I learnt that my colleagues had also gone through a similar coding interview with different problems of similar size and scope. Some people asked for 30 minutes while some asked for 90 minutes. Therefore, I believe that it is possible to have a tiny 30 minute to 90 minute project that lets a candidate demonstrate his or her software engineering skills.

I felt this method was very effective because it evaluated a couple of key skills that were important to do the work that we were doing there: time and effort estimation, API design, writing clean and correct code, robust error handling, and design decisions from performance and security perspective.

I didn't get paid for that 40 minutes but it was part of their half a day onsite interview process, so I did not have to spend any extra time apart from the time I had already scheduled for visiting their office. Also, they did provide me free lunch, snacks and drinks, so I didn't complain. I wish more employers did this.

This is not an interview.

The interviewer is focused on his "regular" job, not the candidate. Plus, the candidate can't possibly become fluent enough in the company's app/API/codebase to actually accomplish the task in a day.

Interfail.

I interviewed at an internet darling company. They had the main interviewer (who was a bit rude) and another shadow interviewer who takes notes on everything you do an say. All interviews are like this.

The coding gotchas quickly make you super nervous as everything you do and say is recorded. You have 15 minutes. Plus whiteboard is not an editor. I don't code linearly like writing a text book.

I have come to a realization that fresh out of university me performs better at interviews than 7 year experienced me.

Interviewer: There is no correlation between people's ability to take timed code quizzes and good developers. It causes undue pressure on some candidates for no reason and we should never have it be part of the process.

So, if you are interviewing at 20 companies, you need to expend 100+ hours or almost 3 full work weeks?

It should take 1 hour or less. Period. Probably less that 1/2 hour. I doubt I get much more information asking you for a 5 hour assignment than a 1/2 hour assignment.

If I'm really that interested in your programming on the fly, I should do it at the interview where I'm paying for your lodging, food, etc. I should tell you what you are going to be doing, and to bring your laptop set up to do that.

I actually prefer a coding interview over an interview with an unprepared interviewer, who is making up questions on the fly and expects the exact answer he/she has in mind.

These are good points, and the tests I have given are specifically designed to avoid these issues.

Personally I do this:

* Come up with a simple but realistic 1 or 2 hour task, and write up the request in plain English (do not write a tech spec). It should be task you'd expect anyone to be able to easily do on day one without any assistance.

* Include a short narrative about the end user that clearly implies a specific requirement or two, but don't spell out it out as an explicit requirement.

* Omit a small but important detail that any reasonable person would ask.

* Instruct them to provide a solution to the users problem, and ask questions if something isn't clear.

These are pretty simple to evaluate too:

* Does the code run? (i.e. can the candidate write basic code?)

* Does it meet the user's explicit needs? (i.e. can the candidate follow basic instructions?)

* Does it meet the user's implicit needs? (i.e. does the candidate write code to spec, or do they think about the bigger picture?)

* Did the candidate ask a question about that obvious missing detail? (i.e. does the candidate speak up, or will they make assumptions?)

You would be surprised with how many people don't have the ability to apply their ability to write code to solve simple problems.

And I think it's a great idea, personally I would never consider working anywhere that hired devs without seeing them write some code. But my problem is with the types of questions asked at many companies, specifically the types that require weeks (or months!) of prepping.

During my last job search one interview that stood out (positively) was a problem around parsing some HTTP headers (it started simple and then had layers of complexity added as I solved each one). It was honestly one of the best questions I've seen in an interview as it requires the candidate to be able to write code and solve a problem but without requiring/expecting the candidate to have prepped beforehand to learn (or brush up on) theoretical stuff far removed from the types of problems we actually solve on a daily bases (evidence of this disconnect is demonstrated by the fact people need to prep).

If it is then it is acceptable. If it isn't then it seems asinine.

For me myself, if I had a literal clock there ticking down then it will take me twice as long and I'll do a much worse job. There's a lot of people who cannot program under high stress situations like that (and a job interview is naturally quite stressful already). So expect to dismiss a lot of otherwise great candidates.

Maybe the interview process should be based around the job you're employing them for rather than for trivial games that only test someone's abilities at completing those exact type of task. Crazy I know, but maybe just maybe it makes sense.

I try and do my interviews this way. While I am required to use the whiteboard and the interviewee is required to write on it, I try to make it as clear as possible that we can brainstorm/strategize on the problem together.

Of course I've asked the same few questions probably 100 times now and have seen them solved every which way so I have to play a little dumb sometimes.

Same problem occurs in a "real" pair programming environment too, though.

Interviewing is hard, and it's easy to throw stones at companies who don't do it the way you want it done.

Assuming the role is a fullstack developer, memorizing basic algorithms doesn’t show one is fit for the purpose.

Providing a simple skeleton of a fullstack project—in the chosen tech stack of either the candidate or the company—and then verifying a candidate can add a simple feature, or something similarly fullstack, would accomplish that far faster than algorithm answers.

Edit: I realize this risks sounding like stupid take-home interview homework. I personally oppose that crap. However, I recognize why some companies take that route, as I don’t think I’d feel confident that a candidate could work in my company’s stack by asking silly algorithm questions. I’d probably feel more confident watching the candidate do a remote screen share, git clone a starter app, and do some simple to moderately complex fullstack tasks. Of course, the tasks should fit the role, I think—e.g., I wouldn’t ask a candidate who’s being hired to tune DB queries a bunch of fullstack questions. And if I was hiring a backend dev to build out APIs, I wouldn’t bother with a bunch of frontend tasks and questions. The hiring processes I’ve seen and managed always had better results when more time was invested in prepping specific, job-focused interview processes, rather than offloading that time onto candidates because recruiting teams can’t actually do more than ask shallow questions or follow checklists.

This is why I wouldn't continue interviewing with you, but perhaps not for the reasons you think.

Despite my 15 years of experience as a software developer, your test will likely have some edge-case question that I won't get right. I'm terrible at timed tests, but I'm not a terrible software developer. Why should I spend 4 hours of my weekend failing to prove myself to you? I'd so much rather spend an hour or two having a detailed, technical conversation with you—and I think you would too. You can glean a lot from a conversation (it's easy to copy/paste code from Stack Overflow, but it's not easy to fake it through a lengthy, technical discussion)!

This idea sounds great on paper, but the actual job we expect people to do requires months of context and collaboration.

It doesn't fit into an interview. That's an unfortunate reality of interviews.

So interview problems must be artificially small and artificially constrained.

If you wanted to work on a couple 2-week sprints by yourself for free with no guarantee of a job and use ChatGPT as your sidekick, be my guest. But if you want to get the interview done in a matter of hours then I have to shrink the problem down to something that fits into a matter of hours to reveal how you work. If you're just copying into ChatGPT and then poking at the output, that's not a good test nor representation of anything.

Sounds like you're caught up in a big circlejerk, to be honest. Your interview process is terrible and that's why you aren't finding any employees. You won't compromise on your process? What? You should be less worried about your process and more worried about finding quality employees (hint: your process isn't working).

Asking people to write a program over the phone isn't going to work. Have you ever written a program while on the phone? I haven't and I'm not going to. It's so far out of my comfort level that I'd probably end up looking like a moron.

Your test sounds like it's too much about what a person knows and not enough about how a person performs. You'd be much better off looking at a persons resume and, if you're satisfied with that, just talking to the person instead of worrying about whether or not they can reverse a linked list in C off the top of their head. If you want them to write you some sample code, let them do it at their leisure instead of with you breathing down their neck over the phone.

Frankly, reading about your interview approach just kind of pisses me off. What's more likely: all the candidates suck or your interview process sucks?

Solve a small problem - of which millions can be found in issue trackers.

Here is an example I just read on Github:

Somebody reports that reading a JSON file results in a value that clearly is an integer being misidentified as "Not an integer". The source code is a parser written in C and the code is quite readable.

Give the candidate an hour to try to figure out what is happening (obviously, the language and context must be a match for the job).

Important - I think: It would be good if the problem is unsolved and the interviewer him-/herself does not know the answer. Also: Don't send them into a room alone, watch them. I know that adds stress, but learn how to lower it, make it clear you too don't know the answer. If the candidate really can't cope with someone watching, well, okay, let them try alone, I just think if the atmosphere is right this is valuable. There is no right way to approach solving such a problem, but without and not meant for judgment, I think this is just interesting to see how different people approach problems. Of course, if the interviewer has string opinions about how it should be done that is a bad method and I myself would not like to be interviewee in that case.

Asking about projects is the obvious thing, but only substantial and interesting projects really provide any interview value. Yet another Todo app doesn’t fit that criteria. Neither is another scaffolded crud app.

A PR to fix a bug in a semi-popular library is worth. But saying “I have a lot of repos” is def not.

Can you explain how other industries do it better and come up with a better, plausible, non-fantastical way to interview programmers? I'd love to know how to interview people "better", but it still has to be something where I can later present evidence that my decision is based on, in some kind of report. It would have to allow multiple people at my company to interact with a candidate in a half day or less. Copying what another industry does would be great, if it worked, because it'd help convince people it was a good method to try out.

> Are the hoops you have to jump through justifiable for how "important" your job is?

I never thought a 1 hour phone screen and a few hours onsite was particularly onerous, and based on how much the job pays, it seems well worth it.

> People's lives are dependent on how well she does her job.

I'm not sure why you seem to think that saving lives correlates with strictness of interviewing, especially with the 2 jobs being so drastically different.

Then read some (maybe this, I didn't look at it in detail, but at first glance looks reasonable) and practice.

> I just want to see how well the candidate can code :-(

All this tells you is if the candidate can code. If you want that, give them a test, look at their Github history (if they have it). Ask for code samples from any project they can share that they're proud of.

I personally find it much more valuable when interviewing someone to talk about what they've done. How they've solved problems. What their interests are both in and outside software.

Setting up a non-stressful experience and using behavioral interview type of questions and form is my personal favorite. Something I think is really important, that many people forget, is that the interviewee is also interviewing you. If you come across disorganized, unprepared (didn't even read their resume), etc., then you may fail the interview and even if you want to hire them, they'll say no.

I have a million things I want to learn about. If a potential employer would rather I spend time on what amounts to trivia, then great, I don’t want to work there.

> I’ve had non-leet code interviews, like write some feature in 60minutes.

This is also a problem because it’s impossible to understand the constraints, context, specifications, etc. during this time. When I am asked to implement a feature in the real world, it takes time to understand the domain and context. Writing code is usually the last and easiest bit. It also never occurs that you need to understand and complete something in just an hour or two.

So in leetcode interviews you’re asked to turn on a bunch of knowledge you don’t really need. And in implement this feature interviews, you need to turn off a bunch of important knowledge and experience.

Both are irritating interviews.

The best way to interview, in my experience, is to ask about a project or projects someone has worked on. Even better if there’s time for them to present on it. That way you get a real world picture of their skills, they are comfortable, and you can ask detailed questions without jumping the shark. Further, it is perfectly reasonable for someone to be required to present and answer questions over something they’ve worked on in an hour or two. That does happen in the real world.