[dasmoth]

However I've been to job interviews where they force me to code live in front of several people and I couldn't get half a line of code out before one of them will chip in with a "suggestion" breaking my train of thought. The code they want me to write is some algorithm that they have expected you to memorise.

This could actually be the test in itself. There seems to be a substantial contigent who believe that this is what a collaborative programming environment looks like, and they might actively want to select against people with a more shut-the-door-and-work-through-the-problem mindset. I'd argue that a pair programming exercise is probably better than whiteboarding-with-interruptions, but setting that up well is more work for the interviewer.

Edit: completely messed up the quoting in original!

[Jach]

Great point on this possibility... A big source of brokenness with tech interviews is that so many interviewers want to setup an interview (often adversarial, where the interviewer holds more cards) where candidates get ranked primarily on subjective hidden variables. If the real test isn't the given test, the interviewer sucks. Measure as directly as you can what you care about, whether it's technical criteria or softer criteria, and if the answer is on one candidate's resume but not another's, ask about it rather than assume the other doesn't have it. Want to know how the candidate collaborates? Prime them with that expectation, that the problem solving is a joint effort. Want to know how someone functions in the face of conflict? Ask about their experience with conflict and resolving it, rather than try to setup some conflict and seeing how they respond (or don't). Want to see if they can write a good unit test? Ask them to write some tests rather than saying something vague like "develop as you normally would". Whatever it is, the important part is making clear to the candidate as much as possible what is the hidden state in your head that you're using to evaluate them.

My own dream as candidate/interviewer is to spend some hours trying to solve an interesting problem together that neither of us has solved before. Unfortunately it's not repeatable for the interviewer (at least once it gets solved, until then there might be a way with a big problem to bootstrap a candidate to build on past candidate+interviewer's efforts), and even then its main use is judging "works with the interviewer well" when there are probably better things you should be measuring in most cases.

[thepp1983]

A slight aside. I had a really good coding assignment once.

It simply said "Make a working clone of this webpage, zip it up and file it to us".

I could have just nicked the jQuery code (this was before a lot of the frameworks have taken off and everyone abused jQuery and I worked at a place that used vanilla js for performance).

https://pastebin.com/NvGm89cR

[thepp1983]

If the test is like that I have zero interest in working there.

This is for two reasons

1. I don't like silly games in interviews. You aren't respecting me or my time before I am working for you, you aren't likely to while I am working for you.

2. I personally like to be left alone while working on something. Then again I find scrum calls etc a total waste of time.