Hacker News Reader

Comment by trhr | Hacker News Reader

I've been writing code for 30 years, invented three algorithms, have managed engineering teams and been trusted with half-million-dollar tech budgets, but because I don't have a C.S. degree, I rarely get into a final round.

Maybe changing the expectation that good developers must excel at LeetCode is a place to start fixing the shortage that causes this problem in the first place. I excel at perceiving contexts and understanding when to change approaches, but since you can't test that in a tech screen, it's basically a worthless skill to have.

View on HN

You sound like you have a really valuable experience and skillset. In your opinion, how would you go about technical interviewing in a way that makes sense?

Have a conversation with someone who can recognize the experience, and not be threatened by it. Look for the candidate to tell war stories about technical challenges, leadership challenges, interpersonal challenges and how they solved them and what they learned. Read their resume and recognize multiple stints of increasing responsibility at quality companies means something.

I can:

A) Relate to the GP, and

B) Answer the question

For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP.

I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company.

If you were a photographer, that was the case. If you were a programmer, that was definitely not the case.

So I had a challenge.

I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development).

I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote.

I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered.

I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped.

I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year.

In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had.

I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore.

I think I did OK.

[UPDATE] I made it more about me, to try to make the comment a bit less abrasive.

It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless. The only trend I see that I agree with from leetcode dissenters is that it doesn’t make sense when you have issues maintaining headcount. I’m a newb, and I definitely have no experience hiring, but it doesn’t take ANY intelligence to know that leetcode makes sense when you have a long list of halfway decent applicants.

Whether or not it’s ethical. I don’t know. Having to take the time to practice for an interview is going to select privileged folks.

> It’s ridiculous to say that the go to hiring strategy for most of the highest paid positions in the world is useless.

Hey, be nice. I was talking about my experience, in my career, which was fairly unique.

I managed to make some very picky people fairly happy, for a long, long time.

Need to work on my writing. Was annoyed at your leetcode dissentism and and wasn’t able to contain the annoyance. My b, dog.

Hope to have a similarly long and satisfying career.

> leetcode makes sense when you have a long list of halfway decent applicants

It lets you build a team of people who are good at leetcode, but I won't be on that team. Which is a shame, because my t-shape is wider and deeper than most engineers. I just can't solve fake problems about how many ways there are to combine a string quickly.

Why isn't there a refactoring section of the tech screen? Hand me 5,000 lines of garbage code and let me figure out what it does, why it does it, and how we can improve it. Those are the kinds of problems I actually have practice solving.

The companies that use dsa puzzles in their interviews wouldn't do it if it wasn't reasonably good at avoiding false positives.

Does it test for enthusiasm? Of course not. My company isn't big enough to use dsa puzzles in interviews, and I wish we were. Unfortunately, I've been on teams with a developer who couldn't crunch strings. Leetcode interviews get the job done of avoiding those people (at the cost of also cancelling people like yourself). It's just like tests in college. They suck, and everybody hates them, but they're around because they get the job done.

Your example of 5000 lines is laughably to my point. That's a totally unrealistic filtering process.

But it's totally realistic. LeetCode reflects academia, a world in which all problems are solved in 100 lines or less, thread collisions don't exist, and the context is stable.

My first major software job, which I went into, with almost zero experience, was to maintain 100,000+ LoC of FORTRAN IV code, 1970s vintage, in one file; accessed via 300 baud VT-100 terminals, and line printers that sounded like an M60. No documentation, and stepped on by every junior engineer before me. It was awful, and taught me the value of writing good code, and leaving a legacy[0].

This is the cloc output for the Swift iOS project I'm working on now:

          54 text files.
          54 unique files.                              
           0 files ignored.

    github.com/AlDanial/cloc v 1.92  T=0.06 s (863.2 files/s, 477430.9 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    Swift                           54           3961          11281          14626
    -------------------------------------------------------------------------------
    SUM:                            54           3961          11281          14626
    -------------------------------------------------------------------------------

Note the code is almost 50% comments. That's what being traumatized by Devonian-era FORTRAN will do for you.

BTW: That's only about half the code. I have thirteen dependencies (that I also wrote -except for one small one). They are non-small projects, each in their own right.

My understanding for the reason for LeetCode tests, is because there's a big problem with total fakes presenting as qualified software engineers, and the tests are just there, to make sure they can even code.

I never encountered anything close to that, in my career. Quite a few folks presented résumés that claimed skills they didn't have well-developed, but it was pretty easy to figure that out, in a quick conversation.

I actually hired some of those folks anyway. The stuff we worked on wasn't something they taught in school. Everyone is starting from scratch. I looked for enthusiasm, eagerness to learn, and problem-solving skills.

[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/

> I've been on teams with a developer who couldn't crunch strings. Leetcode interviews get the job done of avoiding those people

My main objection is that it's _timed_ crunching. The juniors can solve three toy problems in two hours because they've been drilling them nonstop for six months. I can finish any Medium and some Hard questions, but the Hards may take me 4 or 6 hours.

And yet, in the real world, I close tickets twice as fast as they do, because I grok the problem space quickly, don't head down as many dead ends, and know before I start when to escalate because this ticket isn't a ticket, it's an epic.

My point is solely that any test where a fresh graduate can reliably outperform someone with decades of experience is objectively not a very good test. I'd go so far as to say the universal reliance on LeetCode is a big part of why greybeards are underrepresented in dev teams.

You’re just a crotchety old grumpy greybeard is what you are. (Teasing)

I think it’s plain as day to both of us that the new grads are outperforming experience because of practice. You could practice to get your solve times down below new grads.

I posit that the dsa puzzle interviews have become prominent as a solution to a very specific problem: lots of very qualified applicants. When done correctly (with many rounds and equally qualified evaluators), the interviews produces few false positives (when it comes to being able to code effectively).

Does it find people who are passionate about software? Does it find people who are good at refactoring complicated codebase? No and No, but the people it finds can stay afloat in a scrum.

Finding the real gems is extremely difficult.

Interviewing is outside my skill set, so take this with a grain of salt, as it's just the sort of question I'd like to answer:

"We have an application that needs to run inside a vehicle, which means the power will be killed at regular, but unpredictable, intervals. How would you design this to ensure data integrity?"

It's weird enough that few people will have solved it before, but it can be solved at every layer between circuit and application, so you can actively brainstorm with the candidate to draw out some of their solutions into more detail.

And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.

(Parent comment did mention the grain of salt, so my response below is to the spirit of the comment itself and not directed at the person).

> And if they start with, "well, I'd build a react app," you can go straight into the trash can with their resume, because you can have that whole discussion without deciding on so much as a language, much less a framework, so you can see who jumps too hastily to wrong assumptions.

So you would reject someone based on the first thing they say? That’s called prejudice - maybe they don’t have the systems programming lingo in place to describe the ideas you are looking for, but might actually have some ideas trending in the right direction given some nudging. Also, that sounds like you gave a systems programming problem to someone who may have specialised in react the last two years - did you read their resume?

Seeing how complex this discussion gets every time on what is the “right” way to interview and how biased people can get (things haven’t changed in a generation - it used to be about picking the wrong Java library I heard) - no wonder Leetcode has emerged as a “fair” standard-bar that everyone in computing has an actual shot at clearing.

That said, Leetcode-style does bias towards people who have time, resources, and not many responsibilities, especially with problems trending to ever more esoteric algorithms. I don’t know the solution.

I perhaps explained poorly in two cases:

I'd knock serious points for anyone who mentioned any languages (except in the context of talking about low-level features of that language that would help solve the problem),

and I don't see it as "systems programming" because it absolutely could be answered at the application level. It could also be solved with a battery pack (systems level) or immutable storage (hardware level), to name a couple others. The point is giving folks an opportunity to talk in the areas of their experience, and the strongest devs have taken a break from VSCode to do other stuff which adds value to solving problems holistically.

Clearly, you need a bank of magnetic core memory.

Reply on news.ycombinator.com