4 ms·
In interview design there are a lot of trade offs. Coding something quick within an hour? "It's too time constrained." Take home interview question? "It takes
by novok 5y ago
In interview design there are a lot of trade offs.
Coding something quick within an hour? "It's too time constrained."
Take home interview question? "It takes way too long for the busy professional who already has a job, and plus, even if we time constrain it, they'll put way more time in. Or they'll cheat with friends."
Ask to see previous code? "Many good candidates do not do open source and couldn't tell us what they work on in detail due to NDAs."
Don't use automated interviewing for initial rounds? "We are wasting a lot of expensive engineering time on poor results"
Just ask about work experience and make a subjective call? "We don't know if they actually know how to code, and it's way too random, prone to bias and opens us to lawsuits."
Use different interview methods for different candidates? See above
Watch over a person live code? "Too anxiety provoking". Don't? "How about cheating?"
Trial to work for 2 weeks? "Immigrants cannot do that, and people wont leave their stable job for an unsure offer. So only the unemployed could do it, and why are they unemployed?"
etc, etc
Also there is the entire mountain of going over glacial HR departments and getting them to change their interview processes.
I agree leetcode is shit and I made it a personal mission to change the processes at work to remove the leetcode and add more work sample interviewing, but it's difficult!
- koonsolo 5y agoI can't give you enough upvotes. I also do a lot of interviews and hire people, and it's just very hard. Plus, you only know the false positives, but never the false negatives. And I also think that a lot of people who never interview candidates don't realize how many of them can't even code the most basic stuff.
- Der_Einzige 5y agoSo, the answer is to ask easier leetcodes. I unironically only ask fizzbuzz and then domain specific questions (in my case it's ML/NLP). You can even design domain specific "leetcode like" questions for your domain. In my case, it could be to come up with a very simple implementation of K-NN. I accept psudocode and leave the editor, compiler (err, run button...) And Google open as resources that they can use during this time. But companies won't do this! Bloody Google of all places had me do a code interview in a Google doc!. Imagine my horror as I am fighting indentation issues while trying to come up with the lc hard solution he asked in 45 mins.
- novok 5y agoGoogle is pretty bad in general with their 5 leetcode policy :p But that is what hacker rank and automated interviewing is supposed to be usually, an automated leetcode easy.
- EvanKnowles 5y agoFollowing a comment I saw on HN, we now have several code snippets that we ask them to read through (biggest is like 12 lines) and tell us, at a high level, what it's trying to do. Great results, we've found people who learnt all the lingo completely failed when it came to reading and interpreting code.
- novok 5y agoYeah I like the 'debug the real code block' style of interview too! Just pretty much anything that is not leetcode bingo is a real improvement.
- Nextgrid 5y agoReading this it seems like the company's objective isn't to hire someone but to find every possible reason not to hire them.
- novok 5y agoThis are real responses and complaints about changing interviews from leetcode type to not leetcode type, or to fix other common issues and anxieties that people have in interviews. Every interview type has issues and you have to choose as a company what negatives you want to accept for which items you want to favor. And yes, a bias towards avoiding the false positive is a explicit goal of many engineering interviews, and I think google has said so explicitly.