Comment by novok | Hacker News Reader

Comment by novok | Hacker News Reader

Parent Full thread

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!

Following 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.

Yeah 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.

I 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.

So, 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.

Google 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.

Reading this it seems like the company's objective isn't to hire someone but to find every possible reason not to hire them.

This 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.

Reply on news.ycombinator.com