71–80 of 238 posts
> I’ve never heard of an ex ICPC competitor go on to build a great piece of software Telegram.
Reasons we test for data structures and algorithms: - The work sucks because existing employees don't know DSA's - We want people to re-implement and refactor with better DSA's - We want to know the candidate studied for the interview (took it seriously) - We actually do want them to know DSA's when joining the team - It's the least you can do when applying for a CS job Most recruiters provide links and resources, th…
The material is irrelevant , at least for most software engineers. (For a FAANG, not so much. But for most places? Irrelevant.) I understand the time-space tradeoffs of the various STL collections, and the Java collections. In 35 years, that's been all I have needed. (And, if it does come up, why spend months memorizing what I can spend minutes googleing?) I am not a huge outlier. Interview for what you need. Anythin…
I can't figure out if it's a strong aversion or an inability - the end result being the same in both cases, at best some approximation gets implemented instead, and the analysis / feature / etc just doesn't get done in the worst case.
Earlier quoted context omitted.
I bet you have. But how long did you have to solve it? Did you have access to the internet, talking out ideas with your colleagues, coffees? I agree that you can’t simulate real scenario in an interview, but you can also acknowledge that the process is a little cartoonish.
Interviewees are encouraged to use Google, code on a laptop rather than on a whiteboard, etc. Sadly, I only get an hour to interview people rather than a week. But I have had people complain about "completely unrealistic problems unrelated to the real work" when the problem is something I literally had to solve 3 months ago.
One amusing thing I've noticed about MAANG companies (with perhaps the exception of Google) is that despite passing the technical interview, the employees do not actually do any difficult or tricky implementations when something like that is actually needed. I can't figure out if it's a strong aversion or an inability - the end result being the same in both cases, at best some approximation gets implemented instead,…
Earlier quoted context omitted.
I have a very talented SWE friend who only left a now-public unicorn because they were recruited by a former colleague at a startup they knew wouldn't involve leetcode in the interview process. I have another very talented SWE friend who has been doing leetcode exercises off and on for months and is struggling to start doing applications even though they do not like their current work and are undercompensated. They f…
leetcode difficulty is vastly exaggerated. people study 4 whole years of their lives in college to increase their chances of making money, why not spend around 5 months on leetcode which can perhaps get you much farther than anything from college? i'm not particularly smart, in fact i struggle at work routinely, but i know what i have to do clear interviews, so i do the grind and it has worked well for me. (to a cert…
Adding new project that must be executed on as a prerequisite to being seriously considered for a job when you are obviously capable can be a hard sell.
Especially given programming challenges are not that fun for people used to delivering features.
I know that for talented SWEs, having a leetcode interview sink an interview process it can be invalidating.
Companies that rely on single algo/ds interviews also discourage potentially great employees when they totally ignore evidence of capability.
The company wants candidates to grind ds/algos, but it won't compel its own employees to look at public contributions.
The leetcode style of interviewing is essentially a legal way to practice age discrimination. When you're young and just starting your career, you typically have nothing but time, and doing programming challenges on evenings and weekends can even be fun. As you get older, life happens and you have children to take care of, older relatives to help out, a spouse who'd like to see you every so often, etc. Practicing lee…
And, as someone in there 30s with two young children, I find time for interview prep easier then any other point in my life. As you get older you should get better at learning. Also, who doesn't have chores and jobs when they are in their early twenties, you should get better at managing your time as you get older.
Earlier quoted context omitted.
My objection is maintaining an entirely unrelated skillset that I have never encounter in my day to day work. It is a skill that you will lose if you spend a year without interviewing/leetcode practicing. Sure I’ll do it, but you may as well test me on painting famous oil artwork from memory too. > I don't understand why people prefer "here take home questions/work for 5 hours for free" over DS&A interview. The alter…
imagine if you were actually an oil painter...you pass the interview with flying colors and show up to work and there is nary a brush in sight
If I have money for every article that rail against DS&A algorithm.... I don't understand why people hate DS&A so much. Just do it. Get money, jump ship, get more money, it also makes you a better engineer. It gives you better compensation, it helps you, helps everyone, helps your team, your company. It helps avoid wasting time as well on both sides. There is no downside of studying DS&A and Leetcode, if there is, th…
>> "There is no downside of studying DS&A and Leetcode, if there is, the downside is minimal." - Personal time taken that is not relevant to the job? >> Also, it is "Green Lumber fallacy" to think that a knowledge of "how webpack 1, 2, 3, 4, and nth build system in JavaScript here works" will make you a better engineer. Those kinds of knowledge aren't long lasting, and it is also quite easy to learn relative to DS&A.…
How many manhole in NYC questions is hand wavy and not precise. Totally different than DSA.
Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.
> Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have. If the current leetcode style of interviewing is the best that SV can come up with, despite having some of the best engineers and thinkers in the world and billions of dollars to spend, that's really sad.
At some point you have to accept that there is no ideal way to interview, and that there are fundamental time/precision/recall trade offs. Big tech optimizes for low time and high precision, which means you certainly will end up with low recall (false negatives).
I’m sure there are improvements to me made (and maybe the specific leetcode style is not ideal), but I don’t think the billions of dollars is relevant. It’s like saying it’s sad that tech companies haven’t improving on O(n log(n)) sorting despite their billions — it’s not possible.