Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

221–230 of 675 posts

Re: Stop Interviewing with Leet Code

#221

Earlier quoted context omitted.

You won't get the job not because you "didn't worry about the algorithm" but because you didn't ask any questions about the problem; just went straightforward to the implementation. In FAANG interviews that would be a red flag.

So even if you deliver exactly what they were expecting they are upset that you didn't need to ask any questions to get there?

That's what I've heard, yes. Crazy, eh?

Re: Stop Interviewing with Leet Code

#222
post #203

> you can pick a ticket and pair program. Have them review an actual PR. Etc. This seems so obvious. If you pick a leetcode question, there’s always the risk that your candidate has memorized the answer to that particular question. But if you pick an actual bug/PR from your codebase, that problem disappears completely, and you get to see how they would perform on the actual job you’re hiring for. Can anybody think of…

The easy way to get around exploiting free labor is to pay for the labor.

Give the project a cost and time budget (e.g., "You've got six hours to try to resolve this issue that our [already trained and familiar with the codebase] engineers think will take ~2 hours to resolve, and we'll pay $100 an hour for the effort whether or not you succeed")

Re: Stop Interviewing with Leet Code

#223
post #109

To be honest if I was an employer I probably would do leet code or similar. The logic would be that yes, many engineers are shy or nervous around people. But losing those is worth it since hiring someone bad that you have to fire (that wastes some months of productive time at the company) and then re-hire someone else is definitely worth that risk. Having made something impressive on github is somewhat fakeable since…

> get a lot of help from the internet But this exactly what they’ll do on the job. Actually, searching for help and distilling what you’ve found into a clean solution is a skill in itself.

Yeah but it's somewhat hard to determine how difficult a challenge it actually was to produce that piece of code from the outside. It may be a signal of competence, or it may be one of those things that seems really impressive but they actually just followed a youtube tutorial that explained most of it step by step. (Which is a fine solution if you found that for a particular problem you had to solve, but it's not a reliable signal they'll be able to solve arbitrary things in the future - not everything has been explained by someone else, especially when trying to tackle very novel problems.)

The point is that code challenges are a pretty hard to fake test and the loss of some types of people is worth it for the employer (like me, who sucks at them).

Re: Stop Interviewing with Leet Code

#224

In my team we do technical interviews in three steps: - an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the co…

This is pretty similar to what we did. We didn’t offer a refactor problem though. We just had a basic problem to create a calculator from a string, only supporting addition and subtraction. Then a high-level question on how would you architect and scale a simple API/service.

We didn’t reject people if they weren’t able to complete the algorithm, because it’s a lot of unrealistic pressure. For both questions, we mostly just want to see how they think things through, how they identify pain points, how open they are to feedback, and discuss their approach.

Even though we would tell people this, I think they still put a lot of pressure on themselves because of the status quo of leetcode interviews.

Re: Stop Interviewing with Leet Code

#225

As an interviewer I can tell you are absolutely missing the point. Why would I ever want to hire a developer without seeing them perform? And since being able to program a small piece of code to specification is such a basic, important part of development, why would it be bad for me to verify if you can do it? If your friends are so good developers, why would they have a problem reasoning around a relatively simple,…

> I think people just complain too much rather than focus on figuring out how to succeed.

This is a great example of what the top comment in this thread describes.

Re: Stop Interviewing with Leet Code

#227

Earlier quoted context omitted.

> replaced them with real engineers nice gatekeeping. Shame on them for working to get a job they want.

After seeing all the unreliable and buggy software, i think more gatekeeping in IT would probably be beneficial. You wouldn't let someone do surgery on you that hasn't been to medical school.

Systemic problems being blamed on individuals is not going to help. Of course society is a shared responsibility model essentially but it means even a highly skilled and otherwise technically competent and qualified engineer in an inadequately structured system can regularly produce garbage work. Having to hire nothing but the best to achieve decent or viable output IMO moreso implies that the processes or systems are lacking than whether people are even capable of output of the desired feature set.

Re: Stop Interviewing with Leet Code

#228

Earlier quoted context omitted.

> replaced them with real engineers nice gatekeeping. Shame on them for working to get a job they want.

I want the airplane I am about to board to be flown by a real pilot.

Do you want the plane designed by a brilliant engineer or 100 people who are really good at memorizing engineering questions?

Re: Stop Interviewing with Leet Code

#229
post #203

> you can pick a ticket and pair program. Have them review an actual PR. Etc. This seems so obvious. If you pick a leetcode question, there’s always the risk that your candidate has memorized the answer to that particular question. But if you pick an actual bug/PR from your codebase, that problem disappears completely, and you get to see how they would perform on the actual job you’re hiring for. Can anybody think of…

I've never worked somewhere with a codebase simple enough for a new engineer to find and fix a non-trivial bug on their first day. Especially not with someone looking over their shoulder deciding whether to hire them.

Re: Stop Interviewing with Leet Code

#230
post #163

Earlier quoted context omitted.

This reminds me of the interview process at Thinking Machines, where the interview was working onsite for a week and then getting voted on. Or Pixar which required you to excel in atleast one thing in your life

i excel at training dogs, would Pixar like to hire me?

They might (but having that one skill alone may not suffice).
Post reply on HN