When hiring developers, have the candidate read existing code

Happens to me too, I get tough interviews, and a good salary, but the work is exactly the same as the juniors "a guy on the scrum team". I don't even understand why they hire seniors, or have that title when it means nothing. I guess they expect them to be just faster versions of juniors.

Absolutely agree, the collaboration should happen sooner in the process, and I would add that the team should probably also have made at least a high level proposed solution together before the work even started.

The problem is that the 'existing code' may well be of poor quality and that in order to understand it you first have to get into what it was supposed to be doing in the first place, and this isn't always obvious. So the writer had better take good care to make the code self explanatory or provide additional documentation to give sufficient context. In a way the underlying assumption is that the code is 'good'.

And that's where the real problem lies: lots of code isn't all that good and plenty of it is probably best described as 'single use', in other words: write only. Trying to read it or trying to make sense of it is more effort than writing it ever was. And given the fact that code is typically read many more times than that it is written it pays off to write it well, but hardly anybody really does. The pressure to deliver the next commercial feature is just too high.

And woe to the interviewee that points out the deficiencies in the code if the author of the code happens to be the interviewer, because people will be people, so this could easily turn into a minefield.

Questions to ask of the interviewer before 'reading' the code:

- who wrote it?

- is it functional?

- are you supposed to debug it or explain it?

- was it written for the express purpose of the interview or is it code from the company codebase that is representative of how they work there? (this alone might be reason to terminate the interview depending on how it looks :) ).

Like you totally disagree.

I described my experience and what I saw, well I did not do any scientific research on 1000s of companies. But I still think my experience has the same validity as your statement. So it can be both at the same time, there is so many companies small and big.

Very little empirical evidence supports it, despite people parroting how "useful" it is. You're also teaching people to BS about themselves to get a job, perverting the entire thing.

If you want to psychologically analyze people, use a method which is actually supported empirically instead of the "do what every other pseudo-psychologist does" method. Big 5, for one, actually has some empirical evidence supporting it, but is barely ever used.

On the other hand, if you can actually figure people out in an hour under a single set of constraints, somehow being able to extrapolate that to the work environment as a whole, while also trying to put the work environment in a much better light than it actually is: quit your IT job now and make millions selling books.