> Hire someone right away and let them quit if they want to and hire someone else. It's just business for crying out loud.
This is missing the point of interviewing. The goal isn't to find any warm body to fill the chair, the goal is to find someone qualified to do the work who also has a history of doing good work at previous employers. You also don't have unlimited headcount and hiring budget, so it's worth making the investment to find the top 10% of your applicants rather than picking first-come first-serve.
One of the things you don't realize about the hiring market until you've been reviewing resumes for a while is that problem employees are over-represented in the candidate pool. The most qualified employees spend the least time job searching because they're given offers right away. The most problematic and underqualified employees are frequently searching for jobs after being fired or let go. If you sample applicants at random, they're far more likely to be in the underqualified and/or problematic group than in the great employee group, statistically.
The other thing that isn't obvious is just how damaging a single bad hire can be to a team. Hire someone who clashes with their peers and fails to deliver any good work and you'll find yourself losing the good team members very shortly. Nobody likes working with painful coworkers.
That said: The analogy of a "walk-on" job isn't dead in tech. If you pick a company you want to work for, find someone on LinkedIn, and send them your resume with a short pitch about why you want to work there, there's a good chance they'll at least strongly consider your resume. Nobody is guaranteed a job this way, but it's one route to getting your foot in the door even when you don't see the exact job posting you want on the website.
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.
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.
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.
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.
The GP was using the proxy of "shows up at 7:30AM, ready to work" as signal for motivation and a lesser extent, competence. Not a morning person, but would prefer this to leetcode hazing.
This is missing the point of interviewing. The goal isn't to find any warm body to fill the chair, the goal is to find someone qualified to do the work who also has a history of doing good work at previous employers. You also don't have unlimited headcount and hiring budget, so it's worth making the investment to find the top 10% of your applicants rather than picking first-come first-serve.
One of the things you don't realize about the hiring market until you've been reviewing resumes for a while is that problem employees are over-represented in the candidate pool. The most qualified employees spend the least time job searching because they're given offers right away. The most problematic and underqualified employees are frequently searching for jobs after being fired or let go. If you sample applicants at random, they're far more likely to be in the underqualified and/or problematic group than in the great employee group, statistically.
The other thing that isn't obvious is just how damaging a single bad hire can be to a team. Hire someone who clashes with their peers and fails to deliver any good work and you'll find yourself losing the good team members very shortly. Nobody likes working with painful coworkers.
That said: The analogy of a "walk-on" job isn't dead in tech. If you pick a company you want to work for, find someone on LinkedIn, and send them your resume with a short pitch about why you want to work there, there's a good chance they'll at least strongly consider your resume. Nobody is guaranteed a job this way, but it's one route to getting your foot in the door even when you don't see the exact job posting you want on the website.