> I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most p

> I hate coding interviews but I am sympathetic to people who want to do them because I've met people who are such good bullshitters that they could fool most people. If you're talking about someone with no working experience and who claims to be self-taught, you really have to make them write code. The choice is not limited to made up toy problems vs not testing coding skills at all. You can give them real problems to solve. > The interviewers tried to tell him to approach it like an industrial-grade solution, not a weird academic exercise. Hahaha, and how exactly do you write an 'industrial-grade' FizzBuzz? ;) Obligatory: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... > The whole point of the interview is to get hints about the candidate. There are times when interviewers read too much into what the candidate does or says, but this isn't one of them. Oh but it is. If I were to ask you, the expert, to draw a blue line with red ink and then attempt to draw conclusions from your behaviour based on that question, could I ever get a valid assessment of you? If a test is faulty, so are its results. Garbage in, garbage out. Interviewing is no trivial task. It is an attempt to test how well someone will do a thing without having them actually do it. By definition, that is impossible. Still, we can try to get good enough results by minimising the number of differences between our test environment (interview) and production (the job). That will involve: a) making the interview environment resemble the job as much as possible (no hazing, minimal pressure on the candidate, writing code in and IDE instead of a whiteboard, etc.) b) presenting the candidates with coding tasks that match what the company does on a daily basis (take a suitable bug you had in your codebase, touch it up a bit with more issues, have them fix it; pair program with them to add a new feature to your codebase, etc.) Some concrete examples: - https://rachelbythebay.com/w/2022/03/19/time/ https://rachelbythebay.com/w/2022/03/19/time/ (it suffices to read the first two paragraphs) - https://quuxplusone.github.io/blog/2022/01/06/memcached-interview/ https://quuxplusone.github.io/blog/2022/01/06/memcached-inte... - https://blog.jez.io/bugsquash/ https://blog.jez.io/bugsquash/