Hacker News Reader

Comment by EMM_386 | Hacker News Reader

I'm a 20+ year Senior Software Architect, Team Lead, Senior Developer and a PM (all at the same time at the moment!). I've done everything from C++ to 20 years of .Net to now TypeScript and Angular 13 with .Net Core REST APIs against an Oracle SQL database.

I am self-taught and I can't do these leetcode problems if my life depended on it.

I still deliver high quality software on time, and on budget, and have a solid grasp on my career.

I wouldn't worry about this too much. It depends on what you are going for.

Sure, if you want to pass a FAANG interview where you are going to get these types of questions, go for it. To solve day to day business problems, you rarely need this stuff. You just need to learn how to write quality, performant, correct code that results in solutions.

The best way to do this is develop experience in the industry over the years.

My 2 cents.

View on HN

I'm also self taught with over 20 YOE and pretty lost with leetcode problems. But I get the job done and have a really good eye for user and business domain concerns. My last two jobs haven't required any kind of test. I actually had to do a couple of short narrative essays for one to prove I could write - which was a hoot because I majored in English.

The only job I've ever had to do any kind of test for wasn't leetcode - just a practical demonstation that I could write a basic CRUD app. Was actually a pretty good test to weed out people who were just completely useless.

I'm also finding that experience matters. It's just tough to get that across up front.

The only job I've ever had to do any kind of test for wasn't leetcode - just a practical demonstration that I could write a basic CRUD app. Was actually a pretty good test to weed out people who were just completely useless.

I think this is a totally reasonable way to weed out applicants, particularly if they allow you to do it during the interview time. I've been through several interviews (though, to be fair, they were well over 15 years ago, since that's how long I've been with my current employer) that used a similar exercise. One interviewer just sat me down at his workstation, and told me to build a quick crud with their tech stack (which, of course, I knew going in). Nothing was off-limits (web searches, etc).

If you were to choose between no Leetcode in interviews vs. a significantly higher chance of getting fired in the first 3 months of your job (essentially treating it as a trial period), would you take that deal?

I ask because as a startup founder, I would significantly prefer to try working with someone for 3 months instead of doing useless least-common-denominator interview questions. It's a bad fit, it's better to quickly part ways. But getting fired or asked to resign is a big emotional blow for many people, and I'm not sure if they would rather face that than the Leetcode grind.

The problem is that it takes a lot of effort to fire people. And every time you do, you increase your exposure to legal trouble.

Not in the US it doesn't. The turnover rate if anything is a symptom of the problems in the industry.

At least in Germany it's usual to have a trail period of a half year in any job. During this time both, the employer or the employee, can resign form the contract with usually a two weeks notice period. Neither side needs to specify reasons in detail.

As this is a normal contractual regulation there is almost no risk of any legal trouble (usually).

On the other hand side as soon as this trail period ends all the German workplace protection regulations start to apply in case of permanent employment contracts. So after the trail period ended it gets quite difficult for an employer to get rid of an employee.

But all in all that's pretty fair, imho. After a half year you quite surely know whether you like the workplace, or form the other perspective, the employee.

I realize that I'm probably the outlier here in the US market, but absolutely I'd rather have a 3 month trial period (not only so you can evaluate me, but so I can evaluate you to make sure it's mutual).

I'm fairly confident in my ability to deliver value in the first couple of weeks on a project, so would much prefer this to having to spend time grinding leetcode puzzles that I'm not innately good at.

Note: a large part of this perspective is the privilege of feeling like I could get another job pretty easily, and having a sizeable emergency fund that I could draw from to continue the search if things didn't work out. So you may be filtering out people who are not in such a fortunate position.

What do you mean by "can't do these leetcode problems if my life depended on it".

Because there is a difference between writing FizzBuzz and solving one of those dynamic programming problems that are so common in competitive programming. For the former, I am surprised you can even work without being able to to this, for the latter, you pretty much need special training that is not very useful in most professional settings.

I never took a leetcode style interview so I don't know what is generally expected. If you are expected to do hard problems, it doesn't test much besides your leetcode skills. But easy problems look like a pretty good filter, assuming the stress of the interview isn't blocking you, which is another problem.

FizzBuzz != leetcode. You are correct - easy problems are a good filter. After starting with one company I started sitting in on phone screens and candidate interviews and I was shocked at what a lot of applicants didn't know. Actually helped me with my imposter syndrome. I walked away from several interviews feeling like maybe I did know a thing or two!

IME the challenge is that all leet code problems seem easy once you know the answer, in particular because the code itself is often very simple. And so many of the interviewers claiming a candidate cannot do "easy" problems are off-base. This usually stems from not knowing the history of the underlying data structure or algorithm. Interviewers take for granted the things they know, especially once they've asked similar questions a few times.

IMHO I believe the right approach is to either ask from a standard bucket of questions that require preparation and advertise which ones to candidates, or not ask them at all. Asking "only a few really easy ones" is becoming a red flag to me.

It reminds me of the "Jewish problems". Math problems that look simple, with a simple solution, but are actually really hard. It was used in the Soviet Union to deny access to universities for "undesirable" people like Jews. They were given these "simple" tests and their failure was used to justify their rejection.

> a standard bucket of questions that require preparation and advertise which ones to candidates

And what are you testing than? Whether someone can memorize things?

Even though I'm not good at memorizing things every second monkey out there is.

Actually, people relying mostly on memorization for "problem solving" aren't very intelligent in my experience.

Especially in software development you don't want people who can mostly only reproduce things once learned by heart!

No two problem instances are exactly the same. It's all about the context! What is the recommended text-book solution in one case could be the most stupid thing you could probably do in another superficially "similar" case. You want people being able to recognize the difference and act accordingly.

(Of course you need some amount of drones in every company. Especially when your company is big. Not everything needs highly skilled and highly intelligent employees. Also there is only a given amount of adequate people available at all. If you're big you can't be too picky if you want to hire enough staff in a reasonable time frame. But those are problems of really large organizations).

I agree that leetcode easies are good filters.

But what if too many people pass those filters?

Then we move onto mediums.

But what if too many people solve those?

And that is how we reached the current state of interviews.

I'm a 15 year(ish) engineer-turned-manager who has spent a good chunk of time doing recruiting.

* I confirm that day to day business problems rarely are the sort of problems you find on Leetcode.

* I might ask similar questions in interview. I don't expect the candidate to solve them. As a matter of facts, I don't care if the candidate actually solves them or not. I am observing how the candidate behaves in front of a difficult problem. Will they freeze? Will they jump head in the code? Can they articulate their thoughts and think analytically about it? Can they think on the spot if I challenge their approach? Are they comfortable saying "I don't know"? This sort of things.

In my book, being a "good engineer" is much more about communication, collaboration, familiarity with git/sourcecontrol, clarity of commit messages, pertinent emails, being reliable, being resourceful, etc.

Good grasp of algo is a big plus, of course, but it's not something that all the best engineers excel at.

> Will they freeze?

So what if they freeze during those 45 minutes? How representative is that scenario for what most devs do?

Most people freeze on interviews and its normal entirely.

Also, most problems are not solved in the 45 minutes and in day to day coding , we generally have a minimum of day to think on the problem and solve it without people looking over our shoulder, google or ask someone :)

> Most people freeze on interviews and its normal entirely

And presumably fail said interviews because they froze. Usually "I think I need to think about this for a while, or maybe even sleep on it" isn't the answer that the interviewer requires.

As you note, it's normal to need more than 45 minutes to think about a problem that you haven't seen before. Many leetcode type problems puzzled eminent computer scientists and/or algorists/mathematicians for years before they were solved.

Then there's the psychological aspect of when interviewers try to "help" you by asking questions, providing clues or even the specific clever (or stupid) trick needed to solve the algorithm puzzle but really you're in no condition to understand the hints they might be providing.

What do you mean?

If a candidate freezes for 45 minutes in a 45 minute interview, they won't get the job.

... Right?

So if I asked you a complex architectural question, or an algorithmic question and you froze, would it mean that you are an incompetent manager?

Clearly thinking on your feet in front of people is what it means to be good at ones profession.

My role isn't to assess if you're competent or not. My role is to assess if I want you on my team or not. There's a difference.

And yes, if I ask you a technical question and you freeze, I don't want you on my team. It doesn't mean you're a bad engineer. It means you're not a good fit.

My role isn't to assess if you're competent or not. My role is to assess if I want you on my team or not. There's a difference.

Pretty much sums up how the hiring process is a gamble. So if you don't like somebody and they could be an asset to the company you would not hire them?

> I can't do these leetcode problems if my life depended on it.

Don't undersell yourself, you ARE able to do them, maybe with some practice, like putting some basic algorithms implementation into your muscle memory.

Doubtfully it'll make you a better developer though.

Anyway, the most important skill for FAANG interviews is ability to write code on a whiteboard with a dried out marker.

His intention isn't to undersell himself, for whatever reason it's very favorable on this site to tell people how you have decades of experience working in this field but can't write fairly basic data structures or algorithms. It comes across as very likeable and personable and gives people hope that they too can spend decades working in a field making a better than average salary without ever having to master the fundamentals of their job.

The reality is that if this person's life really did depend on it, for example they lost their job and they have bills they need to pay or a family they are responsible for taking care of, then they almost certainly could put in the effort to brush up on their skills and get to a point where they could do leetcode easy or leetcode mediums in a matter of weeks or a month at most.

It's along the lines of an MIT grad saying that where you go to school doesn't matter or a rich person saying that money doesn't make you happy, or even the myth that Einstein failed at math. These statements that espouse a false sense of modesty have great appeal and they likely come from good intentions, but ultimately they give people bad ideas about what it takes to be a fairly competent developer.

> Anyway, the most important skill for FAANG interviews is ability to write code on a whiteboard with a dried out marker.

This would be a good April Fools ecommerce site. "Dried out markers! Guaranteed to land you a job!"

Same. I've been working 20+ years and am now more management than coding, but I have never been subject to a leetcode style interview and have never subjected a candidate to one. I think they are poor predictors of value in 95% of actual industry work. Any line of business software, web dev, mobile dev, DevOps, IT, creative tech, consulting work requires a mix of basic technical competency, organization and communication skills. And good Googling technique.

Similar experience. 4/5 years in mobile/web, android and angular in Italy. No degree but still now on a solid job. I fully agree.

I have a similar background and YOE as you EMM_386 (except no .NET but a relatively common progression from php to node/react), and I even have a computer science bachelor degree from a top 50 US university (graduated with honors). I can't do these leetcode problems if my life depended on it either.

For OP, I read your post and the post you linked from 9 months ago. It sounds like you two have fairly different backgrounds and experiences. The other poster said they had only worked for 1.5 years before getting fired at a first job, and then spent time leetcoding. 1.5 years is a short time for a person to be able to learn how to effectively work in a grown-up world after school/college. In fact, I had a similar experience at my first job (I didn't get fired, but I was getting below-average performance reviews and I left on my own), also for about 1.5 years. It wasn't until later I learned what matters, what to do and what not to do at a job, and then excelled.

For you, it sounds like you've already learned it, evident from the fact that you had 4 years at a real job with a senior title, proving that you can do it well. It sounds like your issue is more around finding meaningful work, having a disdain for the current trends of agile, react, CRUD apps, etc. which isn't uncommon. I think there are other solutions to what you're facing, and leetcode isn't it.

For me, the key has always been working in an industry I'm truly interested in, then I can dive deep into the business domain knowledge. I'm a very senior level engineer and I'm good at it but at the end of the day the code is still just a tool to me. I don't really care if architectures are tried and boring, I just want to make business impact and build products. Maybe it's the same for you, maybe not. The key is finding what matters for you, and not care about parts that don't matter.

IOW, it turns out that it is really hard to test for the high-level skills that actually produce results, no one has really cracked how to do it, and "Leetcode", despite their marketing, has also failed to figure out how to really build a useful test set.

Disagree that the knowledge required to do well at leetcode is not useful for some business problems. FAANG most definitely has products/projects that need that specialized ds/algo knowledge, which is something most people learn in CS formal education.

Off the top of my head, React uses lots of graphs and trees to render stuff.

All you need to know is that this stuff exists, and when / why it would be appropriate to use it.

Also there is almost never a reason to implement such things yourself—even when you need the algos—as there are libs for that! (Imho one of the biggest signs of incompetence is when someone starts to reinvent the wheel! That's an absolute no-go. And the truth is: If you're not in academia doing research all the wheels you ever need are already invented).

A valid test for a candidate would be whether he/she is able to google for an algo and pick the correct code form the results.

Such a test would be good enough as a lot of bad candidates would fail as they wouldn't google but start to "solve" things on their own; the other bad ones wouldn't be able to pick the right solution at all—because they don't know what they should look for in the end.

I must admit I don't understand how one can not be able to solve them and be able to solve other programming problems at the same time.

I believe you and others when they claim they are good developers. I just want to point out that for many people, it can be impossible to understand how your minds work.

Maybe it is a bit like dyscalculia, where some people can not comprehend "amounts". They can not calculate well, but they can actually be good in other fields of mathematics.

Edit: I never did a lot of leetcode, but for reference, here is a problem they categorize as "hard": https://leetcode.com/problems/median-of-two-sorted-arrays/

It requires calculating the median of an array. Is that really a kind of thing people who are otherwise good developers can not do? I must admit it really boggles my mind and makes me a bit hopeless and desperate. It seems all attempts to explain stuff to people are futile anyway, at least for some things.

Typical day-to-day programming never requires you to find the median of two-sorted arrays, so a self-taught programmer generally has never thought about how you would tackle a problem like that, especially given the complexity requirement (O(log (m+n))) stated in that problem. If your brain immediately knows what to do when you read that problem, then you probably have a CS degree. If you have to spend 5 min thinking about the complexity notation before you even start the problem, then you probably don't have a CS degree.

And if you see that and go "do they actually say the words 'big oh' when they speak that outloud..." you're interviewing as successfully as I do!

I really appreciate your greater point. I've been given all sorts of CS problems in interviews that I don't have any background in understanding the context enough to know what to do. I changed careers from experimental physics, so my software work is essentially self taught. That doesn't mean I'm totally useless in my job or not an asset to my team or can't deliver products that generate massive revenue. But, those things are how interviewers make me feel.

But wouldn't it be exactly the hallmark of a self-taught programmer to be able to figure things out on their own? In general I don't think a programmer can expect the kind of job where they only do standard things all the time?

Merging and comparing arrays as in that task also seems like something that might actually come up in a job.

However, I take the point of the other comment that the real issue here is doing it with certain speed requirements. That does make it harder, indeed, but still doable.

Absolutely - a self-taught programmer should be able to figure out how to solve that problem. All I'm saying is that it's going to take longer for the self-taught to solve it because it's not something they have thought much about before.

Having a CS degree gives you a large advantage when solving problems like this, but that advantage is markedly lower when you are trying solve typical real-world problems in the private sector.

Self taught programmer here. I get stuff done for the project or program I'm working on. I learn how to do what I need to do securely and automate a lot. I can figure out documentation of frameworks, libraries and random code written 10yrs ago. I can glue things together or write new code in python, golang, C, C++, shell, nim, lua, and others. I'm self taught where it matters to get my job done.

Self learning 'big O' is a waste of time and effort. Never have I needed to know it to accomplish a task beyond interviews. Don't nest six for loops, reading lines from a file into memory each loop. Got it, learnt it, can do. Next problem.

This gatekeeping attitude is bullshit.

I never used the O notation in a job, but I have seen people waste cycles. For example in the early days of ORM, I saw people load the whole table and then sort and filter in Java, rather than writing appropriate SQL queries.

Understanding Big O notation is not that difficult and everybody knows it is a common question in interviews. Analyzing specific algorithms can of course be difficult.

> But wouldn't it be exactly the hallmark of a self-taught programmer to be able to figure things out on their own?

Self-taught or not, no one is able to derive an optimal solution to algorithm problems on the fly. You must have previously learnt the technique, and probably practiced applying it a lot.

I think the tricky part with that specific problem is that it asks you to do it in O(log(m+n)) complexity, so you can't even iterate through the two arrays to see all of the values -- you need to do some binary-search-like thing across both of the arrays. In O(m+n) complexity, yeah you could combine the arrays and then find the median of the combined array, which is much simpler. This is actually a great example of why those questions are so hard!

OK I missed that - that does make it harder indeed.

Also I must admit I used to enjoy such tasks more in former years, now it seems more like a needless chore. On the other hand, somehow I feel compelled to solve games like "Human Resource Machine" or "Infinifactory", which can be equally tedious.

I'll try to solve that leetcode task.

For more points, try solving it in 25 minutes without running the code (i.e. as if it were on a whiteboard), and produce an answer that you're confident doesn't have any major errors, and be able to explain why it's logarithmic time. When you're done with all that, then run it and see if it passes. If not, you fail!

Demanding code that runs is silly, I agree. I think it can be valid to see how people cope.

I was once asked to produce the proof of the theorem of Pythagoras, which I hadn't thought about for many years. I failed to do it in the interview situation and later did it at home. However, I enjoyed the interview and I was also offered the job.

Many of those simple problems are only simple once you understand the underlying techniques, and often have subtle tricks that make or break the underlying solution (for the allowed runtime / memory). I am continually amazed reading Segewick when he points out "this only takes one line here to make it all work! Seems simple, but actually took researchers years to work that out". But if you read (or use similar code) invovling that one line, you might think it easy.

A good exercise, I think, would be to ask people to implement binary search (assuming they never have before). We can all intuitively explain the algorithm, but actually getting all the code just right is a little tricky. See if it trips people up. Then ask them to do it in 20 minutes or they are fired (e.g. comparable to interview scenario).

The point of that exercise seems to me to make people implement binary search without having a solution they have learned by heart.

Well, yes but my supposition is that it will trip some people up in unexpected ways. And given a tight timeline, the results will not translate into how good of a programmer they are. IMHO it will be semi-random whether good programmers can complete the problem. And of those that can, a sub-set will have (whether they recall it or not) completed VERY similar problems in the past.

I've found a great number of "easy" problems too challenging to complete in 45 minutes. And yet once I learned the underlying techinques / DS / Algo's, many "medium" ones I can complete in 10 minutes or less, even when I have not seen that particular problem. Conversely, I was able to complete some of the harder problems in 5-10 minutes without EVER having seen the underlying algorithms before, because I actually had in real life problmes but had never drawn the connection. The more leet code I do, the more I realize when encountering a new problem, it is a complete roll of the dice if it will take me five minutes or five hours, despite being of the same level of difficulty and even same class of problem. But this is not so surprising -- this is how the history of those algorithms unfolded. Many were one line of code away from a far better runtime, and sat for years before someone cracked it.

My main take away is, algorithmic style questions can be useful to test whether candidates adequately prepared and practiced from a given set of information, and is perhaps most predictive of their level of comittment / professionalism / base-aptitude. IMHO unless you are building a novel product or charting unknown territory (rare), its far better to be experienced, prepared, and well read, than it is to be smart. Perhaps. I don't take issue with Google requiring a wide variety of expertise in such problems to get in. I do have a problem with a random set of "easy" problems and then making judgements of people afterwards. But that's just IME.

Got this question at a FAANG company. Interviewer was absolutely not satisfied with linear solution and wanted it solved in log(m + n)

There's a huge meta-game around these questions that you pick up after practicing them enough.

Even without the hint, I intuitively know looking at that question that linear time is too easy for a 1 hour face to face interview at Google.

I also know that as the data is sorted the optimal solution must be logarithmic, as in these contrived problems there's no such thing as an unnecessary detail. Monotonic means binary search.

I haven't built this intuition from my experience as a software developer, but by spending my free time playing the game and grinding these arbitrary puzzles.

The fact you missed this meta, tells me absolutely nothing about your skills as a developer, only that you haven't been grinding leetcode.

That shouldn't be a signal not to hire you, but that's how the game works at FAANG.

If you can make this observation about the arrays, and code a fully functional binary search taking into account whether the total length of both arrays is odd/even, handling the out of bounds case, whilst under pressure on your third interview of the day with just the intuition you've built in your day job, then as far as i'm concerned you are the exception not the rule.

>I am self-taught and I can't do these leetcode problems if my life depended on it.

>I still deliver high quality software on time, and on budget, and have a solid grasp on my career.

There's simply no way of proving that to recruiters without Leetcode.

There's no way of proving that to recruiters with Leetcode.

> There's simply no way of proving that to recruiters without Leetcode.

If a recruiter can't assess engineers without something like Leetcode, they need to find a another job. Assessing talent is the job of a recruiter, and if the only way they can do that is with Leetcode, that's just pathetic.

Except, recruiters were able to do just that for a really long time before leetcode came along. If a recruiter today can't assess a candidate without toy questions, they should probably reconsider doing technical recruitement.

Reply on news.ycombinator.com