Whilst the challenges were not particularly complex, you also had to ensure that the person who was going to run your code could stand up your environment, so part of the second challenge was "thoroughly document how to run your code, the environment needed, etc, etc."
Life is too short to deal with this kind of stonewalling.
I did one recently after the initial HR person chat. I spent a morning on it as they suggested 2 or 3 hours. But then I was rejected for the most pedantic reasons (2 white space PEP violations), not setting up mocks for testing (that would have doubled the scope of the project). Providing an HTML response rather than JSON when the spec asked for a "page, don't bother about styling". And various other trivialities.
I tried passing on my complaints, but the HR girls didn't like that. Pretty disrespectful after giving up a morning of my free time.
Sennder is the company, as I feel that we should be naming and shaming.
I don't see how mocks would have doubled the scope of the project. I think I have mocks set up in a few lines of code or so. If your project is so difficult to test or if it is difficult to set up mocks for it maybe there is a serious flaw in your project structure?
> Providing an HTML response rather than JSON when the spec asked for a "page, don't bother about styling".
I don't understand what you mean with this. Did you provide a HTML response or did you provide JSON? I did a super simple HTML response with no styling and that was fine. If you did JSON I could see how they would mark it as a mistake when they clearly asked for a HTML page.
The company was Goldman Sachs. Name and shame.
It seems you don't enjoy coding?
I don't interview much these days, but I spent several years of my career sifting through CVs and interviewing candidates.
The number of candidates with seemingly impressive CVs and apparent several years of experience, yet whom basically couldn't code, was shockingly high. And when I say "couldn't code", I'm talking "couldn't even fizz-buzz" levels of incompetence.
The fact is that there are many devs out there who coast through jobs, while all the time it's their colleagues who are doing all the work.
I wasted, many, many hours of my life before realising that it was pointless interviewing candidates that couldn't code - asking them to perform a sort of gatekeeper test improved things immensely.
So it might seem insulting to have to perform these entry tests, but unless you already have code publicly available (e.g. on GitHub), you shouldn't take it personally.
When I set it up the goal was to avoid a lot of the issues I've personally had or heard about with coding challenges: they take way too long, they're too abstract, or you feel like the company might just be using you to get a couple of days of free work on their actual codebase. For this reason I feel fine about not paying people, as it's just a small part of the application process and not free work for us.
I think it's worked pretty well so far. It happens after the initial phone screen and before the first technical interview. We send people the challenge, they return it whenever they want, and if we like it we set up a technical interview. Since the challenge uses our tech stack and is similar to the work we actually do, a large part of the first technical interview is discussing their solution. Why they chose certain patterns, why they added a certain library, how they'd consider testing it, why a certain function might be slow with 10k entities, and so on.
You don't normally pay candidates for the time they spend doing the whiteboard interview, do you? You can view the take-home task as a replacement of the whiteboarding session, equally with no pecuniary obligations for the candidate.
Then what? Would it feel good to pay