Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A guide to learning algorithms through LeetCode

github.com

Post reply on HN
Print view View original

171–180 of 222 posts

Re: A guide to learning algorithms through LeetCode

#171

Post by n_f »

digianarchist wrote: post #21

It's becoming obvious to me that my time is better spent learning to solve these riddles rather than actually becoming a better developer. I have a job search coming up at the end of the year and whilst I've managed to largely avoid companies that ask this type of question, I believe it's seriously constraining my career. I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earli…

I think these interviews test whether or not you're willing to work hard-- you can't just use critical thinking to get the answer, you actually need to study to learn all the tricks. That's an important characteristic to screen for imo.

Re: A guide to learning algorithms through LeetCode

#172

Post by azemetre »

extra_rice wrote: post #156
PragmaticPulp wrote: post #130

Earlier quoted context omitted.

> On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete. Ironically, take-home interviews are another contentious topic on HN and other internet message boards. The common complaint is that people don't want to invest much of their personal time into interviewing for companies.

I wonder which takes more time, take home tests or LeetCode grind...

If I were interviewing I'd take a LeetCode over take homes any day of the week. Preparing for LeetCode prepares you for nearly 70% of the jobs you will likely interview at.

Whereas with take homes the amount of time doing say 12-take homes can easily be too much. You end up in this weird positions where you can only devote so much time for certain take homes but with the LC & System Design you can at least prepare once and hit up a bunch of companies.

Re: A guide to learning algorithms through LeetCode

#173

Post by [deleted] »

digianarchist wrote: post #21

It's becoming obvious to me that my time is better spent learning to solve these riddles rather than actually becoming a better developer. I have a job search coming up at the end of the year and whilst I've managed to largely avoid companies that ask this type of question, I believe it's seriously constraining my career. I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earli…

[deleted]

Re: A guide to learning algorithms through LeetCode

#174

Post by ummonk »

wdb wrote: post #158
ummonk wrote: post #144

Earlier quoted context omitted.

The bonus is pretty formulaic with fixed performance multipliers - if you're doing poorly enough to get substantially less than the target bonus, you're at risk of losing your job and comp is the least of your worries. And you absolutely can pay the bills by selling the stock when it vests. Agreed on the mortgage part though.

What's the typical vesting schedule? The companies I spoke you would get the equity after four years. Not even a part each year. The offered 0.00[0]5 equity is not great. I think the packages in US are just much better compared to UK/Europe or maybe they just gave me shitty deals. My offer at one of the FAANG in UK was £85k + 50 stock + discretionary bonus (they didn't give details).

Monthly or quarterly vesting is standard across the industry. FB and Google start vesting within a few months and large companies are switching to this norm although large startups till tend to have 1 year cliffs. You get liquidity though from signing bonus (which is paid immediately after joining but you have to pay back prorated if you leave in the 1st year).

The one exception is Amazon which is notorious for its backloaded vesting schedule.

Re: A guide to learning algorithms through LeetCode

#176

Post by shloosh »

bosswipe wrote: post #138
PragmaticPulp wrote: post #134

Earlier quoted context omitted.

> why do you have to prove it for every next job Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer. > Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a…

I've been programming for 10 years and I'm pretty good at it, at every job I've had I get lots of praise and recognition and accelerated promotions. But I have a hard time with leetcode problems and have failed several interviews because of them. It's not that I can't learn the leetcode tricks, it's that I don't have the motivation or the time to drill for months on them so that I can retain all the tricks. I don't h…

I also don't have a CS degree, and got hired at a FAANG company. If you want to quickly get up to speed on the data science basics, check out "Cracking the Coding Interview" by Gayle Laakmann McDowell. Her YouTube videos are also useful. Certainly, there are other methods, but this is one that I found useful.

Re: A guide to learning algorithms through LeetCode

#177

Post by indecisive_user »

PragmaticPulp wrote: post #134
zerr wrote: post #93

Earlier quoted context omitted.

Err, but why do you have to prove it for every next job?... In reality, it's a legal way for: 1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. 2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget. Keep in mind that CP != CS. And CP is not everyone's cu…

> why do you have to prove it for every next job Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer. > Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps. In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a…

>Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

But even two teams within the same company often don't trust each other's interviewing practices though.

Transferring from one team to another often requires doing the same algorithm interview that new hires go through, even though you were good enough to get hired in the first place and are ostensibly a better engineer than when you started with the company.

Re: A guide to learning algorithms through LeetCode

#178

Post by BurningFrog »

kkkiiiooo wrote: post #137
jkcorrea wrote: post #112

Earlier quoted context omitted.

#2 doesn't make sense, though: If I'm company B, trying to poach from company A, it would be in my best interest to make the leap to applying/interviewing less difficult, not more for employee's of company A. Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent This is a proven reality, and has been out in the open for a long time.

Then a few links to those proofs should be easy to produce?

Re: A guide to learning algorithms through LeetCode

#179

Post by ummonk »

masterphilo wrote: post #105
PragmaticPulp wrote: post #73

Earlier quoted context omitted.

> Where are the papers that correlate this niche, specialized skill to general job performance and productivity? I would love to read this research if it existed in the public domain. However, much of this comes down to trade secrets and business practices. It's also not very amenable to controlled studies. Practically speaking, these companies have a lot at stake in their hiring process. It's strange that so many pe…

On your last point, the best alternative I've seen is take-home projects where it would take less than a week to complete. The interviewer is free to frame a problem in a way that allows the engineer to apply their real-world experience and show their fit for the job. It removes all the variables around interview stress/anxiety and as a result is a better (but not perfect) indication of their performance.

I refuse to do take-home interviews. My time is valuable, and it's important that the company I'm applying to shows its seriousness by allocating interviewer time to interviewing me.
Post reply on HN