I recently got kicked from a hiring process after a good third round call with the CTO because at some point I’d refused to do a leetcode. I hadn’t, but I had pushed back and asked why round one was a hackerank round, when it was a senior management SRE-team position. Not normally a role with a lot of leetcode. I’d only asked why it was necessary, not refused it. In that actual interview the interviewer (their principle engineer) said he’d looked at my resume as prep, wondered why HR even scheduled a leetcode and skipped the code review and asked questions instead.
He passed me. 2 rounds later the recruiter decided he didn’t lie I’d pushed back early on.
Personally I hate leetcode style challenges and seldom use them. Designing our recent hiring process for our org I included a take-home, but made sure it:
- time limited to 2-4 hours
- had the team practice and verify it’s doable
- clear objectives
- clear marking criteria
- any language they want
It came down to a somewhat typical platform eng/sre/DevOps type task of working with APIs, so chose our company’s public API, so it’s somewhat relevant and interesting, and asking the candidate to write something to read and process our API data.
The really key goal being to weed out people who:
- just can’t write any code at all
- don’t approach problems in a code-first repeatable way.
I learn a lot through running it, and improved the take-home in many ways based on feedback.
The rubric offered the option to do it in a session as a leet-code style round, no one ever asked for that out of hundreds of candidates.
He passed me. 2 rounds later the recruiter decided he didn’t lie I’d pushed back early on.
Personally I hate leetcode style challenges and seldom use them. Designing our recent hiring process for our org I included a take-home, but made sure it:
- time limited to 2-4 hours
- had the team practice and verify it’s doable
- clear objectives
- clear marking criteria
- any language they want
It came down to a somewhat typical platform eng/sre/DevOps type task of working with APIs, so chose our company’s public API, so it’s somewhat relevant and interesting, and asking the candidate to write something to read and process our API data.
The really key goal being to weed out people who:
- just can’t write any code at all
- don’t approach problems in a code-first repeatable way.
I learn a lot through running it, and improved the take-home in many ways based on feedback.
The rubric offered the option to do it in a session as a leet-code style round, no one ever asked for that out of hundreds of candidates.