Agreed, I have refused a few places. Skyscanner keeps on contacting me. Their choice was a "full stack test" entirely in JavaScript, or a Systems engineer test in HackerRank. I wasn't wasting my time with either of those.
Its amazing how many people phone me "for a chat" after seeing my Linkedin profile then expect me to jump in to do their coding test. You have to convince me that I actually want to work for you first. If I haven't spoken with anyone technical about the job then its a definite no.
I must admit that I wonder if part of the success of these types of tests is that they are bullshit and what is actually being tested is how compliant you are as an individual and not really anything to do with technical competence.
Not to say asking puzzle coding questions is an ideal approach, but I think the motivation is somewhat opposite: If you base your hiring decision on how awesome the applicant tells you they are, a certain number of the people you say "hire" for are going to be bullshit artists who can't code. When the interview is over, the interviewer is judged either explicitly or implicitly on how well they conducted the interview, and there's probably nothing worse they could do than say "hire" to someone and have the next interviewer find out they're lacking basic coding skills. So they have to ask some kind of coding question, and it has to be something with some meat to it, but you probably can't make it too OS or framework specific, so you're left asking about overlapping rectangles.
Why not just ask applicants to bring in some code they have written to discuss?
If they have written it they should be able to discuss it and answer questions easily.
If someone else wrote it and they have understood it enough to discuss it, you probably have an even better developer, especially if the job involves working with some legacy code.
> Why not just ask applicants to bring in some code they have written to discuss?
That can be really difficult for a lot of candidates. It's predicated on the idea that they've written code they:
a) Feel comfortable sharing (not just a one-off weekend hack project)
b) Are allowed to share, legally. This is usually the real problem for most developers.
The truth about hiring: There really isn't any one-size-fits-all that works for everyone. Any hiring process you come up with is going to be an incredible obstacle for a sizable minority of people.
>If you base your hiring decision on how awesome the applicant tells you they are, a certain number of the people you say "hire" for are going to be bullshit artists who can't code.
If you base your hiring decision on how awesome they are at leetcode hackerrank style algorithm questions you're selecting for bullshit artists who memorized "cracking the coding interview".
There's a systematic industry-wide bias against realism in developer tests. It's depressing how many people think realism either isn't necessary or isn't possible within typical interview time constraints.
Its amazing how many people phone me "for a chat" after seeing my Linkedin profile then expect me to jump in to do their coding test. You have to convince me that I actually want to work for you first. If I haven't spoken with anyone technical about the job then its a definite no.