|
|
|
|
|
by BatteryMountain
1470 days ago
|
|
This is great, I would totally like to interview like this. The best one I had was a task where you have to basically brute force an api endpoint that uses a semi known password (you have to generate all permutations of a string with alterate spellings ex "pA$Sw0rD" and one of them will match), if you succeed the endpoint returns a url & token to upload your zipped solution. So you end up with a console application that has: network requests, string manipulation, concurrency/parallelism/throttling if you want (I did it to impress, wasn't a junior role), file access (zip & attach & send async), some error handling, good console outputs/logging and comments. When you go to the interview we basically discuss the code I uploaded with one of their senior developers, what compromises I made, how would I improve it and so on. I got the job back then but since moved on. But that was the best interview process I've seen in my career. No leetcode etc, just a basic application that test if you know how to do a bunch of different things, without it being a whole framework mess or a whole product in some cases. it took about two hours, so the balance between spending time on and getting judged for my skill was good; it felt fair & realistic. |
|
Other than not using a library, nobody can complain it's unrealistic. Real enterprise devs spend a fair amount of time munging data from one format to another or otherwise "gluing" pieces together. And the kind of person I'd want to hire should be able to complete it to quickly to complain about a "time consuming take home assignment"
And it provides plenty enough opportunity to make sure you're hiring someone who writes code that is pleasant for their teammates to work with.
IIRC the process before that was just the usual 5min recruiter chat and after it was a single on site panel interview before offer.