4 ms·

> 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 th

by trhr 4y ago

> 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.

comfypotato 4y ago
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.
- ChrisMarshallNY 4y ago
  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/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
- trhr 4y ago
  > 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.
  - comfypotato 4y ago
    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.

by trhr 4y ago

comfypotato 4y ago

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.

ChrisMarshallNY 4y ago
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/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
trhr 4y ago
> 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.
- comfypotato 4y ago
  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.