why do young programmers need to pass? nobody gives a shit whether experienced people pass leetcode so give me one good reason why you should rate young programmers differently.
You should have a mix of developers on any project, some senior, some mid level, some fresh out of school. The senior engineers should devote a significant amount of time to improving the junior. Your mix should skew to junior developers just because some developers will decide to switch to management, selling insurance, or some such.
Note that I did not say younger - you will get a few "old" people switching to programming as well, and they start off as junior.
Do I really want a mix of programmers on my project?
That's a very sweeping blanket statement and you're putting a lot of your beliefs on to other people. The smoothest projects I've worked on were always full of nothing but senior developers. But even though that is just my personal experience I know full well many projects benefit from Junior developers. Sometimes fresh perspective and energy are what you want to solve a problem instead of experience and expertise.
For a short time only senior is better. However eventually someone will leave and it takes time to get the new person up to speed. Your seniors will retire and you need juniors trained up and ready to take over. If you are only a short term next quarter thinker you are right, but if you think long term some juniors that you bring up to senior are the better value. (note that this also requires retention of existing people, if your culture is change the team every project there is no value in this - I'm against such cultures, but it is very common in the real world to not value experience on your project)
Of course there is value in bringing in external experts for a short time as well. You don't want to be isolated and not learn from the rest of the world, and of course sometimes you have money for a large project and sometimes you don't and want to fall back the the minimum staff needed to keep institutional knowledge alive.
Last, ignoring everything else, you have a moral obligation to society to build a better world. That includes training the next generation. (and this helps you - when you are retired they will be the senior engineers building the tools to keep you alive)
A lot of these are good points and need to be taken into account. But not every team persists, or even intends to persist. Not every developer is suitable for training others.
I've been on Plenty of teams that formed and disbanded in 3 months, we had a goal of building a prototype and turned it over to the customer. Just isn't a great place for new devs. Alternatively, I worked at slow and steady insurance companies that had all the appropriate processes for risk aversion in place and were great places to teach new devs. They let them stretch their wings knowing that they would be protected by good CI and good unit tests and other defensive practices at an organizational level.
Not every team needs every sort of skill or skill level. It's a judgment called each team needs to make, and some teams will decide wrong.
A) I, and a lot of other people, do give a shit whether experienced candidates pass leetcode, and try not to give leetcode interviews unless forced to by HR fiat
B) As an industry and as a society, it's not a good thing to refuse to hire new grads, since that leads to the kind of labour shortages we see in e.g. medicine and pulls up one of the best ladders for wealth mobility. Tech therefore needs some kind of funnel to evaluate candidates with less experience. A test that almost none of them can pass is not very useful for evaluation purposes
I agree. It's not a good idea to refuse to hire either young or old candidates. It's also not a good idea to refuse to hire experienced or inexperienced candidates.
These candidates have, as groups, different characteristic strengths and weaknesses. You need to give them multiple tests to see those. Leetcode is not a good test, but you do have to test a new grad on something, which might mean a vaguely leetcode-adjacent test like "go print this json tree of directories to the console then tell me what you did in your third year of uni".
Number one: there is research on how to interview find it and read it. All comments I've seen here give no indication that the commenter is even aware of it. I'm aware the research exists, but I have not read it (my company trained me in interviewing, and the class mentioned research but I haven't checked to see if it is the latest research that I'm trained in)
If the above doesn't answer your question, then different questions for different levels. You should know if you are hiring a junior, mid, or senior engineer. (you may have different levels), and ask them different questions.
one thing I found interesting is the observer or hawthorne effect. in short, people perform differently when observed doing a task. this means that simply by observing people while they are coding, you might make them perform differently, and come to a conclusion they are not able to code, while if you did not observe them, they might have done well.
the reasoning is that it's ok to pass on excellent candidates. as a business owner I find that a real problem. I would prefer the best, not just people who had time to grind leetcode and rapidly crank out solutions to standard problems you can find online. i think it would be better if interviews erred on the side of caution and preferred to let people through especially if they have experience. you can always fire them if they don't perform. there is no job security in the US anyway.
It is my experience that caution during the hiring process means skipping on possibly excellent people to accidentally prevent hiring a dud. There are plenty of both on the job market most of the time.
In practice firing people is hard at most companies, even if there are no laws protecting people in an individual situation. In principle it can be easy but generally a manager who is in a position to evaluate performance doesn't also usually have unilateral authority to fire someone. And a technical manager telling someone that this person can't code or is disruptive on a team often can't communicate that to the managers with firing authority. This can be out of hesitance, budget concerns, or legitimate communication skills on either parties count.
So the hiring practices that most of the companies I have worked at tend to skip on possibly excellent candidates in preference of definitely excellent or at least definitely decent candidates. This is mostly about risk aversion then gain maximization.
I've seen very few people obviously incompetent. As such it takes a while to prove they are incompetent. They do write working code and get it through review. Often the only clear sign is nobody likes working with them - only after you get rid of them do you have concrete evidence that they weren't contributing (that is the team got as much done now since they no longer were stopping their own work to help the incompetent person on things that it is never clear if should have been figured out alone)
How does your comment relate to the topic here, job interviews?
squeaky said that companies are risk averse in their hiring process because it's hard to fire people. I said that companies are not risk averse if they can't fire incompetent people.
You responded that it takes time to determine whether someone is incompetent. Ok, but that just shows job interviews are ineffective at weeding out incompetent candidates, so there's still no justification for the so-called "risk aversion" of the interviews.
I guess I'm not sure why you responded to me rather than to squeaky.
I think the relationship between hiring and firing and interviewing is a little more subtle than a strict if/then statement.
It can be impossible to know up front if it will be easy to fire someone. Some people can hide incompetence of certain kinds for months or even years. Maybe the person that needs to be fired is competent but just toxic. Maybe the person rides right up to the line of the rules and makes an otherwise functional organization seem dysfunctional. Interviews might not be able to tell you if someone is excellent but some terrible people will absolutely reveal their cards. Most of the time there is an unlimited pool of applicants so even if an excellent one is passed up there will be another decent one somewhere. Not every job needs excellence some just need a baseline competence and an ability to be a team player.
These and other factors add subtle weight to risk aversion.
Also, difficulty in firing people doesn't automatically mean organizational dysfunction, sometimes it's an attempt at preventing abusive management. With how swiftly you are advocating for firing I would love to be at such an organization that made firing difficult if you were my supervisor.
> Interviews might not be able to tell you if someone is excellent but some terrible people will absolutely reveal their cards.
You appear to be equivocating on the definition of "terrible". The type of programming interviews that people dread, and are the subject of the linked article, are technical coding quizzes. These audition-style interviews do little or nothing to identify people who are "toxic". And grinding leetcode doesn't make you a team player.
> Also, difficulty in firing people doesn't automatically mean organizational dysfunction, sometimes it's an attempt at preventing abusive management.
Organizational dysfunction and abuse management are one and the same.
> With how swiftly you are advocating for firing I would love to be at such an organization that made firing difficult if you were my supervisor.
I advocated firing "someone obviously incompetent". Why would you fear that?
> You appear to be equivocating on the definition of "terrible"
Such a thing defies singular definition. Every company, person, and project will use different metrics. We might agree that someone truly awful is terrible, but more people exist on the margins. So how could I cleanly define it when clearly there isn't a single definition that matters?
I agree they don't find some kinds of toxic people, but I would argue that a system that does is magic.
> I advocated firing "someone obviously incompetent". Why would you fear that?
Because I don't know you and do not YET trust that "obviously incompetent" isn't a synonym for "politely disagreed one time", "didn't suck up enough", or "black". That last one is super important, somehow the places I have worked that fired very quickly, fired people that looked different very fast. And having a longer harder vetting process during might let a company see a red flag and avoid someone who might make such decisions and allow some time and process to review firing because the rate of terrible hires is likely lessened so firing rapidly is perceived to be less important.
> Such a thing defies singular definition. Every company, person, and project will use different metrics.
The submitted article is about bug squash interviews vs. leetcode interviews, in other words, technical audition-style coding tests. That's what I've been discussing all along too, and the relevant definition of "competence" is technical programming ability. You appear to be want to go off on a tangent about "toxicity", but it's unclear what bearing that has on the topic of the overarching conversation. Certainly no technical coding test is going to weed out toxicity.
> I would argue that a system that does is magic.
I agree.
Also, magic does not exist.
> Because I don't know you and do not YET trust that "obviously incompetent" isn't a synonym for "politely disagreed one time", "didn't suck up enough", or "black".
Well, you don't have to worry, because I've never hired anyone and won't be hiring anyone in the foreseeable future.
> And having a longer harder vetting process during might let a company see a red flag and avoid someone who might make such decisions and allow some time and process to review firing because the rate of terrible hires is likely lessened so firing rapidly is perceived to be less important.
It's weird that you've seemingly shifted suddenly from the topic of hiring engineers to hiring managers. Again, this is completely irrelevant to the topic of the submitted article, which is bug squash interviews. You want to argue that more "vetting" will help, but you haven't actually explained your method of vetting, other than "magic". In any case, if you're worried about racial discrimination in the firing process, which of course is a legitimate worry, then why wouldn't you worry about racial discimination in the hiring process too? After all, you don't have to fire someone who you never hire in the first place, right? Why do you think that black people wouldn't simply be "vetted" out before they get hired (especially since you yourself appear to want to increase the amount of vetting, and thus the opportunities to weed out whomever the hiring manager doesn't like)? It's truly bizarre to believe that you could institute a magical hiring process that could somehow nullify a racist hiring manager. On the other hand, if your magical hiring process could weed out racist managers before they get hired, then you wouldn't have to worry about the firing process.
> Because many people who hire think more vetting reduces the chance of bad hiring.
I don't know why you are answering for bluGill, and bluGill is answering for you. This is frustrating to me, because you don't appear to be of one mind. Unless you are secretly of one mind, one person behind two HN accounts.
In any case, bluGill's previous comment suggests that job interview vetting is rarely enough: "I've seen very few people obviously incompetent. As such it takes a while to prove they are incompetent. They do write working code and get it through review. Often the only clear sign is nobody likes working with them - only after you get rid of them do you have concrete evidence that they weren't contributing (that is the team got as much done now since they no longer were stopping their own work to help the incompetent person on things that it is never clear if should have been figured out alone)"
How do you define best, and once you do, how much better than second best are they? What if the best person asks for several million dollars per year (an unreasonably high number as I write this), but the second will accept for $200k (a reasonable number though low if they really are second best). My guess is you cannot tell the difference between the top 20% of programmers in actual day to day work, and probably couldn't tell the difference in an interview.
We don’t typically do affirmative action by picking interview questions that make things harder for some candidates as opposed to others, though. We consider some questions to be easier for, say, men to answer (“tell me about a time you were asked to demonstrate leadership”) but we seek to remove that bias rather than asking questions that solely focus on things that can only be answered by those who experienced bias (e.g. “tell me about a time you experienced racism that affected your work” is not likely to be an interview question).
Yeah my first response to 99% of these kind of interview questions is why? I look at ROI and how working code impacts budget and investment. It pains me to say it but the biggest companies out there have horrible code in COBOL that frankly doesn’t make sense to change it over. Similarly bug squashing usually is how did it pass QA/static analysis/dev ops.
