Chat with recruiter.

Technical and non-technical chat with a member of the team, some behavioural questions.

Take home task that I was expected to work on for 8 hours - red flag where I should have stopped the process. The scope didn’t suggest when you should stop working on it nor did they indicate any expectations. I raised this as a concern.

I worked only a couple of hours on the project as frankly it’s ridiculous to expect someone to work on a takehome task for 8h (free labour much?) and wrote it in Golang. If you know Golang it’s a very straightforward project with an HTTP server and an in-memory queue to retry some failed requests. All modular and testable with just 4-5 files.

The email I got was along the lines “code was hard to navigate and it didn’t show the system architecture skills we were looking for” the same email also said that the way they assessed it was by comparing it to other people’s code for the same project. The unfairness and the flaw in this approach is apparently not obvious to them where candidates can work on the takehome task as long as they want, and one candidate might work on it for weeks improving it to perfection whereas another might work on it for 1h.

The feedback didn’t make sense as well because there is nothing architectural about the task. Just 1 process that does a couple of things. I’m not sure why they found the code hard to navigate - feedback didn’t say why - but I’m guessing perhaps the reviewer didn’t know Golang. The other possibility is they use candidates’ takehome tasks as free labour for their business.

The other red flag is they mentioned RFCs as a way of working, but when asked why they picked Mongo as a DB, their response was "because the tech lead worked at Mongo before". Make of that what you will, to me it sounded worrying.

Behavioural questions and a take-home task