Live data from Hacker News

A guide to learning algorithms through LeetCode

github.com

181–190 of 222 posts

Re: A guide to learning algorithms through LeetCode

#181

Edited to remove

Sorry for stating the obvious, but money is a pretty big reason to continue doing leetcode style interviews. Most high paying employers ask them. Out of curiosity, how much does your no-leetcode job pay? Is it at least $200k?

> If it comes down to it, maybe I’ll move into hardware design.

Hardware jobs generally pay less than SWE, you'll lose even further on the monetary aspect.

Re: A guide to learning algorithms through LeetCode

#182

Can you imagine having to learn all this just to make a connection to a database, process some data, and then persist it somewhere?

The popular sentiment on computer science knowledge has done a complete 180 in the past several years. Not that long ago, it was popular to complain that junior SWEs didn't really understand the algorithms, the data structures, and what was going on behind the scenes. The complaint was that they were just copy and pasting from internet searches until things sort of worked on their machine, but they couldn't recognize…

[deleted]

Re: A guide to learning algorithms through LeetCode

#183
post #123
post #102

Earlier quoted context omitted.

I don't think it's just about solving the problem. It's also about: - how you convinced yourself and the interviewer that your solution was correct (essentially an informal proof of your code) - how you test your code after you finish coding - what clarifying questions you asked to tease out a concrete question - what edge cases you thought of and how you handled them - how you handle bugs if they appear in the code…

From talking to some people who give out these interviews, most of those points really don't matter at all. What matters is A) getting a correct solution and B) being able to explain how you arrived at the solution. Tests, idiomatic code, clean design, etc are not expected and will inevitably waste precious time. Besides, the very nature of the interview (using a walled-off in-browser pseudo-IDE) restricts you from a…

As a counter point, I was in an interview loop recently with a candidate that ended up solving the question eventually, but didn't hit a lot of the bullet points in the parent comment (asking clarifying questions, edge cases, abstraction).

After discussing feedback from other interviewers, it was apparent that the same considerations were lacking in multiple interviews, and so the candidate got a no hire decision. For any single interview it probably would have been okay to omit these things, but when there's a negative pattern across multiple interviews, that's when it really hurts your chances.

Re: A guide to learning algorithms through LeetCode

#184
post #135

Earlier quoted context omitted.

Why would equity or bonuses not be part of the salary ? You are almost certain to receive it and the stocks perform quite well on average. They still pay better than finance all things taken together or am I wrong ?

Bonus is not guaranteed so why take that into account? Stock maybe but you can't pay the bills with that or get a mortgage even can make it more difficult.

> Bonus is not guaranteed so why take that into account?

Bonus is not guaranteed only if you're about to get fired. Even lowest ok performance grade at google (CME) will get you 15+% bonus. But it's not a whole lot of money anyway. Stock is where you make bank.

> Stock maybe but you can't pay the bills with that

Only at private companies. FAANGs are all public and their stock is as good as cash. You can trade it for raw cash any moment the stock market is open (except during trading blackout windows before earnings) and pay your bills with it

Re: A guide to learning algorithms through LeetCode

#185

Earlier quoted context omitted.

One of the big unspoken reasons these questions stick around: they cause little imposter syndrome anxiety for the senior engineers who need to conduct the interview. You ask a candidate to code a toy problem, and the candidate either knows the "trick" to solving it quickly or they don't -- very little risk for you as the interviewer, you're just watching things play out. But if your interview requires you to pair pro…

>And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could con…

There are studies out there [1] from assessment providers

The problem is any one spending time on this question also has a vested interest in the answer.

FWIW my experience in hiring for my org and in the talent acquisition tech also reflects this . (Not related to the company in the link)

The reason usually this method is not as popular while the efficacy is understood is because it very hard to scale and do inconsistent evaluations and also takes a lot more time per candidate

[1] https://www.qualified.io/blog/posts/truly-predictive-softwar...

Re: A guide to learning algorithms through LeetCode

#186

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 would just keep my confidence. After all your job is to develop, not to solve whiteboard-puzzles.

If you have to solve something, and can't because it's dumb, or partially dumb, then just explain your opinion to the interviewer.

If they weigh that against you, then it's not a good company for you anyway.

Example: An interviewer once asked me details about POSIX-portability of shell-commands in devops-pipelines. I didn't know the answer, but I had done devops successfully for many years so I replied: "I'm not sure, but I don't really need to know that, because I put all my scripts in http://shellcheck.net/"

Which was a completely satisfying answer for him and one he didn't hear before. So points for me.

Re: A guide to learning algorithms through LeetCode

#187
post #109
post #42

Earlier quoted context omitted.

There are plenty of competitive programming sites where you can grind rating just like you would for MMR rating in video games. For example CodeForces, AtCoder, TopCoder, and even LeetCode have rated contests

Thanks ghj. I was aware of top coder/leet code, though hadn't heard of code forces/at coder. For me the adventure game give a bit more concept linkage. Take Monkey Island, I can remember how to reply to many of the sword fighting insults, or what was needed to get pieces of eight via the cannon at the circus. There's something to be said for linking problems via a memorable story, giving examples and meaning from mul…

For me, codeforces is fun the same way chess is fun. Yeah, the mechanics look dry on the surface, but lots of variation under the surface, and lots of chances to link concepts by having an aha moment during the contest or afterwards in analysis.

Re: A guide to learning algorithms through LeetCode

#188
post #181

Edited to remove

Sorry for stating the obvious, but money is a pretty big reason to continue doing leetcode style interviews. Most high paying employers ask them. Out of curiosity, how much does your no-leetcode job pay? Is it at least $200k? > If it comes down to it, maybe I’ll move into hardware design. Hardware jobs generally pay less than SWE, you'll lose even further on the monetary aspect.

[deleted]

Re: A guide to learning algorithms through LeetCode

#189
post #186

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 would just keep my confidence. After all your job is to develop, not to solve whiteboard-puzzles. If you have to solve something, and can't because it's dumb, or partially dumb, then just explain your opinion to the interviewer. If they weigh that against you, then it's not a good company for you anyway. Example: An interviewer once asked me details about POSIX-portability of shell-commands in devops-pipelines. I d…

Your link doesn't work. I think HN makes you leave a space between the URL and the quote if you want it not to mangle the URL.

Re: A guide to learning algorithms through LeetCode

#190
post #40

Earlier quoted context omitted.

Do you think it's unlikely for you to learn those skills quickly? People who have all those skills earn over $300K at those companies.

It’s been really stressful. I know python, but not really any other languages. I’m able to get work done. But I’m really nearly the same as a fresh grad. But really, I was just bumming around, then studied for four months and destroyed their algorithms questions, so much so that expectations for me are really high. But all I know is leetcode, literally nothing else...

Being on other side of the interviews like this , trust me most interviewers know that .

The logic being if you can pick up leetcode in few months you can pick up most things on the job fast.

Understand that interviewers are first and foremost are looking for ability to learn and understand complex topics , it is not all that important which specific topic it is.

nobody really knows what you will be working on by the time you join or 6months later , even if the interviewer wanted to it he is not able to ask the right questions beyond the basgics.

Also university education in IT is woefully behind the industry. Functional programming, or dev tooling is barely covered in most places . Maybe they teach MVC a bit , I don’t expect most kids to understand CQRS or event programming .

Similarly I would be pleasantly surprised if you have setup a simple app, I wouldn’t expect you to know nuances between different cloud vendors , or have experience with zipkin,istio, helm , grafana or similar tools or be able to grok a explain analyse and fine tune a 500GB dB.

it is unlikely a fresh grad has production experience at best they may already know some frameworks and maybe developed a few small apps of their own, however working in large project with 1m+ lines and complex tooling is a skill that takes time to learn , there is a lot of gotchas in every area you will learn only when you see it .

So all I am left with is, does this candidate know the basics , can he understand and learn fast .

That is why these questions make sense for junior developers and never for senior devs.

Post reply on HN