[thepp1983]

Personally I can't stand these tests either. I normally complete them fine.

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.

I normally leave the interview frustrated and even when offered the job I turned them down because the hiring process has given me a bad taste.

[Jach]

Lack of controlling for anxiety is probably the biggest contributor to false negatives... At least you got the offer though.

On the interviewer side of the table, I had a candidate and there was a stretch of silence after they confirmed they understood the problem which I interrupted with "Is there anything I can help clarify?" (I can't observe internal state!) They asked me if I could be quiet for 5 minutes while they thought about the problem. That's fine, I did so. Maybe you can ask the same thing next time if interruptions come too frequently? If they don't respect the request to shut up, that's a useful signal to not work there too.

Lack of interviewer experience can also account for some of it. Unless everyone in a room with more than one interviewer has their turn at questions, I'd expect the silent ones to either be shadowing so they can interviewer, or be overseeing a former shadow take the reigns. I think an interviewer needs to do as little as 10 of them to run the style range of people who need some quiet time to silently think, to people who ask lots of questions, type some, ask more, type, to people who easily vocalize all their thought processes while typing things; the interviewer may also importantly see that despite the style differences the time to get to the same place (if they get there at all) doesn't vary by much...

[thepp1983]

I normally just wanna hack out a problem first, work out for myself what the short comings is with my first approach and then make all the relative changes.

[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.