Hacker News new | ask | show | jobs
by shahbaby 322 days ago
As much as I dislike leetcode style interviews, if I fail one of those, I learn what I can and move on.

Failing a take-home is an entirely different thing. It's a huge loss in time and mental energy.

I've only done 3 of those in my career and only because the projects sounded interesting. 1 of those 3 resulted in a job offer which I can now confidently say in hindsight was the worst job in my career (...so far!).

I'm now leaning towards just filtering out companies that do take-homes because it signals to me that they don't care about their candidate's time and how a company treats its candidates is usually a good indicator of how they treat their employees.

7 comments

I've had the complete opposite experience, and feel the complete opposite way. What is there to learn from failing a leetcode? It feels like luck of the draw - I didn't study that specific problem type and so failed. Also, there is an up front cost of several months to cover and study a wide array of leetcode problems.

With a take home I can demonstrate how I would perform at work. I can sit on it, think things over in my head, come up with an attack plan and execute it. I can demonstrate how I think about problems and my own value more clearly. Using a take home as a test is indicative to me that a company cares a bit more about its hiring pipeline and is being careful not to put candidates under arbitrary pressures.

Would you rather do 10 take-homes or 10 leetcode questions?

Either way, when you fail, chances are that you will not get any meaningful feedback other than "we have decided to move forward with other candidates".

If you had done a take-home, how could you know where you went wrong?

If you had done a leetcode question, you can look up the question after the interview and usually learn from your mistakes.

With leetcode you usually don't need the interviewer's feedback to improve. You don't even need the interview. And after a certain point you won't need that much time to prepare.

I feel the complete and total opposite. With leetcode-esque ones it's just a luck of the draw that you can conjure up the memory for whatever it is they're asking you to do. The decent ones are the ones that at least are somewhat realistic, but the truly terrible ones are those where you have to remember how to do an algo of some sort but you have no access to outside tools of any kind. I've never come out of a leetcode and felt like I learned anything or could've done something better, not to mention the artificially crafted high stress environment. I feel like they also literally never reflect anything even approaching the actual work, either, and basically test your memory more than anything else. There's a reason there's a billion books out there about how to "crack" the leetcode style interviews.

On the other hand, with takehomes I get to approach a project as if it were my own little hobby thing. I get to approach it in ways that are comfortable for me to work, with my music on, in my own editor, on my own setup, with no time pressure (or at least very light time pressure, just like during the actual job). I always use it as an opportunity to try out something new as well, so I'm also learning in the process even if I don't get the job. And in my experience even when rejected, I've always gotten detailed feedback for areas of improvement, which has never happened in leetcode interviews for me.

Agree. leetcode is the greatest thing that happened to tech interviews.

Get good at it and you can do hundreds of interviews with no prep.

Take homes are a proxy for hiring most desperate ppl who can spend most time on it.

With all those leetcode acers, why is software slow as molasses? You would think they pattern match for the most efficient algo with all this training.

In my experience the more impressive somebody is at leet code, the worse their production code. Full of bugs, no error handling. Assuming the inputs never stray from the happy path.

Not saying it's always the case of course. But I did interview almost 400 people over my career.

On the other hand, most people cannot code to save their life. So I have no answers. Only more questions.

> In my experience the more impressive somebody is at leet code, the worse their production code.

Used to think this too, until I met some truly impressively bad engineers where I'm pretty sure they would not have passed a leetcode screen either. People acing leetcode is at the minimum a good signal for people having the patience to sit down and learn non-trivial things over a somewhat longer time period by themselves.

Leetcode is all local cpu. Production code is all waiting for network responses.
>Get good at it

>with no prep.

You contradicted yourself in the same sentence. You can't get good at leetcoding interviews with no prep

After getting good at it, there is no "additional" prep time, unlike take homes, where you would need to spend hours for every individual assignment. Is that so hard to understand?
>After getting good at it

Do you know the "use it or loose it" phrase? How long do you stay good at leetocde to not require anymore prep whenever you interview again?

For some people, doing an AI assisted take home might take less time than having to restudy and re-exercise leetcode for months which they won't use again. Plus a lot of people suck at live coding when put on the spot due to anxiety, which means even more time investment for something not related to work.

>Is that so hard to understand?

I understood just fine, I'm calling it out as being incorrect for a lot of people.

Interviews need to give signal to the employer. Having a couple decades experience now, working high scale, highly available services, and having designed interviews for thousands of candidates and given hundreds of interviews across half a dozen software engineering orgs, leetcode is poor signal.

Good signals comes from questions that uncover attributes that will grow your team snd fill deficits.

The best method yet for a technical interview is a work sample test based on recent work actually performed by the team. I've never encountered a leetcode problem in the wild. Data structures and algorithms, of course. Leetcode? Nope.

But leetcode is easy to administer and someone else already wrote the question. The big companies don't even try to differentiate between those who clearly have practiced the given leetcode problem type vs someone who derives a solution by working the problem.

yes agreed leetcode as interview technqiue sucks but its great for interviewers. i am just a powerless cog playing the game trying to provide for my family.
I don't get it, every job I have interviewed for since 2013 has had a take home. A couple of them waived it in my case but otherwise they all had take homes. Where are these jobs where people don't get given take homes?
When you are rapidly hiring, giving a candidate 2 weeks to complete a take home is a huge drag on the process. Instead, sandwiching 3 interviews (resume walk, leetcode, system design) into a 3 hour time period lets candidates move through the process faster.
hmm most of the take homes I ever got had a 1 week to complete but I guess I see it, I don't think I've ever been trying to get on a company that is hiring more than a small time at any time.
meta, google, amazon don't have take home

Basically all big companies doing industrial scale hiring ( and firing) that don't have time or patience for take homes.

In Australia, AWS dev position in 2021 had a take home. Microsoft contract position before that didn’t but they were desperate to fill seats on a poorly executed gov contract.
GitHub (pre-microsoft at least) and Crowdstrike both did. Amazon didn't have a take home so much as a "prove you can write code with this simple problem" though that was also pre-AI days as well.
> Basically all big companies doing industrial scala hiring ( and firing)

Is Scala the right choice for hiring and firing, though? If they need to fire quickly, why not straight machine code?

I believe this is a typo for SCADA, which would control the industrial machinery used to fire employees in order to ensure distance and accuracy.
to pretend that they care about safety
I can't speak to developer roles specifically. But the last job I had (for a long time), I just dropped an email to someone who was a client. I think a fair number of the developers at the company came through internships or referrals and AFAIK takehomes weren't a thing.
What year?
2010.

It didn't hurt that the person in question ran the products group. (And I went to the same school as the ultimate hiring manager.)

People obviously have different experiences at different companies but networks matter a lot in many cases whether a lot of folks like it or not.

Things still took a few months to coordinate meetings and interviews but it was still the only job I (sort of) applied for.

The problem is that the more we go in that direction, the more hiring in this industry rewards gamifying and grinding, and that bleeds into the profession as a whole. And at that point it’s just not worth working there
What if it's an appropriately scoped take-home assignment? 1-2 hours max. I would say that's fair and gives people with interview anxiety more of a chance.
I love take home and don't like leetcode, so I was thinking: choose a company based on how they interview, might help with culture fit?