Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

I actually very much agree with this comment. I was a manager for 25 years. A bad "team fit" was not good.

I never had a technical failure in my hires, but I did have a couple of "bad cultural fits." These usually weren't toxic people, but people that couldn't handle the responsibilities and pressures (we were a small, high-functioning team, and everyone's visibility was fairly high).

But this:

> who also has a history of doing good work at previous employers.

makes me wonder how LeetCode tests can tell you that, as they seem to be the single most important component of all software engineering hires, these days.

In my experience, they just drive out the qualified people that can see projects through, and leave you with ... the ones that are really well-practiced in short, academic exercises.

View on HN

I'll second that. I never hired anyone who couldn't do the work. The only times things went badly were times when the person basically didn't want to do the work, due to some personal hangup. No amount of interviewing is going to weed out that guy who can code perfectly fine but deep down is yearning to be a psychologist instead. Like any other job that pays bills, you are vulnerable to paying his bills until they find what they really want.

> In my experience, they just drive out the qualified people that can see projects through, and leave you with ... the ones that are really well-practiced in short, academic exercises.

Yeah beats me how anyone thinks LC is useful, other than for weeding out the most unqualified people, like people who genuinely have never coded. I suppose what it really does is finds you people who are willing to put in the time to study all the hundreds of questions.

>I suppose what it really does is finds you people who are willing to put in the time to study all the hundreds of questions.

Yes, this is it.

As opposed to putting in the time to learn how to write and release ship software.

I won't study LC, because I'm waaaaaayyyy too busy, learning Swift, UIKit, AppKit, WatchKit, SwiftUI, DocC, MapKit, SiriKit, device SDKs, networking, USB, etc.

I literally work every single day (like seven days a week), and learn something new every single day, yet I am barely keeping up. I would be nuts to sacrifice any of this time, studying schoolboy questions that have little to no relevance in the software that I write.

These technologies result in actual applications that you can sell and market.

Just another way to look at it.

I'm seeing this comment as a result of this Reddit post: https://www.reddit.com/r/programmingcirclejerk/comments/ydiu...

But overall I agree with you. While I don't have the results to back it up, I do believe that ultimately Leetcode isn't that useful outside of recruiting people straight out of college. Otherwise, I think there are more domain specific methods to assess candidate fitness to a role.

Also, my giving my unsolicited opinion, I do agree with one of the Reddit posters saying that you are currently on your way to burnout. While I can sympathize with you being super interested in learning programming all the time (because it is very interesting!) be sure to not ignore your other needs, and also to take a mandatory break at least one day a week. Speaking from experience, if you don't do this you will burn out and you will have to pick up the pieces.

Well, I have been doing this for over 30 years, and going at my current pace for probably ten years (I noticed the comment about me being an enthusiastic youngster. That was cute).

But I also take breaks (and naps) whenever I want. No one wants to hire old folks, so I don’t work for anyone. I do this, because I want to.

What’s that saying? “It’s not work, if you love what you do?” For me, coding (designing solutions, in particular) is relaxing. I have some fairly serious family and extracurricular obligations that bring their own stressors. Coding is how I get away.

I’ll tell you when I was actually in danger of burning out; it was when I was a manager (which I did for 25 years). I spent a hell of a lot of time, sitting on my ass. I coded on the side, so I wouldn’t burn out. This is like Disneyland, compared to that horrible grind.

I share this position fully, but we need to consider the benefit of a standardized test despite its flaws. Other paths to success need to exist (e.g., university admissions take people on other merits besides SAT and similar) but it can be more difficult to assess the validity of any claims regarding level of experience without a well-known certificate.

When a job doesn't focus on what LC asserts, and I think we'd agree about how huge that segment is, then naturally it should be a small or non-existent consideration.

I have no problem with licensing, depending on the job.

Some stuff should definitely have a steady hand on the tiller, other jobs, not so much.

But the thought of licensing software engineers is daunting. The industry is so incredibly varied.

For example, almost none of the programming I do, involves higher math. I've pretty much forgotten all my calculus, while other jobs are almost nothing but math.

I could be writing crucial, lifesaving device control stuff, and the math person could be working on a game physics engine.

I am in awe of game programmers, but they also work on "nice to have" stuff. I know someone that writes software for medical devices. He is not a "math person," but he's also very dependable, and can be relied upon to Get The Job Done. He has many years of working on things like USB drivers, firmware, Bluetooth, and networking layers.

So, if the “licensing test” insisted on a good command of advanced math (because “everyone should know it” –the same argument given for LC), neither he, nor I, would make it, so the company would be deprived of some very good, dependable, disciplined, and talented engineers, fully capable of writing highly effective asynchronous device control code, and would, instead, prefer an inexperienced math programmer that would try to rewrite the project in haskell.

Amen to that. We hired a guy that just completely polluted the office morale. We were small and wanted to do the "right thing" so we tried to figure out how to make it work for way too long. Finally ended the relationship and the whole place felt better. He wasn't a bad guy, just didn't fit somehow. He was really big on "lanes," didn't handle code review well, and on and on... Important lesson learned. It would have been better for him and us if we had ended it much sooner.

Reply on news.ycombinator.com