Comment by hex4def6

There's no fix for this problem in hiring upfront. Anyone can cram and fake if they expect a gravy train on the other end. If you want people to work after they're hired, you have to be able to give direct negative feedback, and if that doesn't work, fire quickly and easily.

> I must ask once again why we are having these 5+ round interview cycles and we aren't able to filter for qualities that the work requires of its talent.

Hiring well is hard, specially if compensation isn't competitive enough to attract talented individuals who have a choice. It's also hard to change institutional hiring practices. People don't get fired by buying IBM, and they also don't get fired if they follow the same hiring practices in place in 2016.

> What are all those rounds for if we're getting engineers who aren't as valued for the team's needs at the end of the pipeline?

Software development is a multidiscinary field. It involves multiple non-overlapping skill sets, bot hard skills and soft skills. Also, you need multiple people vetting a candidate to eliminate corruption and help weed out candidates who outright clash with company culture. You need to understand that hiring someone is a disruptive activity, that impacts not only what skill sets are available in your organization but also how the current team dynamics. If you read around, you'll stumble upon stories of people who switch roles in reaction to new arrivals. It's important to get this sort of stuff right.

It's the cargo cult kayfabe of it all. People do it because Google used to do it, now it's just spread like a folk religion. But nobody wants guilds or licensure, so we have to make everyone do a week-long take-home and then FizzBuzz in front of a very awkward committee. Might as well just read chicken bones, at least that would be less humiliating.

I can understand such process for freshman, but for industry veteran with 10+ years of experience, with with recommendation from multiple senior managers?

And yet welcome to leetcode grind.

Dealing with an intern at work who I suspect is doing exactly this, I discussed this with a colleague. One way seems to be to organize a face to face meeting where you test their problem solving skills without AI use, the other may be to question them about their thought process as you review a PR.

Unfortunately, the use of LLMs has brought about a lot of mistrust in the workplace. Earlier you’d simply assume that a junior making mistakes is simply part of being a junior and can be coached; whereas nowadays said junior may not be willing to take your advice as they see it as sermonizing when an “easy” process to get “acceptable” results exists.

There are some definite signs of over reliance on AI. From emojis in comments, to updates completely unrelated to the task at hand, if you ask "why did you make this change?", you'll typically get no answer.

I don't mind if AI is used as a tool, but the output needs to be vetted.

Just like anything, anyone who did the work themself should be able to speak intelligently about the work and the decisions behind its idiosyncrasies.

For software, I can imagine a process where junior developers create a PR and then run through it with another engineer side by side. The short-term incentive would be that they can do it, else they'd get exposed.

Is/was copy/pasting from Stackoverflow considered harmful? You have a problem, you do a web search and you find someone who asked the same question on SO, and there's often a solution.

You might be specifically talking about people who copy/paste without understanding, but I think it's still OK-ish to do that, since you can't make an entire [whatever you're coding up] by copy/pasting snippets from SO like you're cutting words out of a magazine for a ransom note. There's still thought involved, so it's more like training wheels that you eventually outgrow as you get more understanding.

Pair programming! Get hands-on with your junior engineers and their development process. Push them to think through things and not just ask the LLM everything.

having dealt with a few people who just copy/pasted Stackoverflow I really feel that using an LLM is an improvement.

That is at least for the people who don't understand what they're doing, the LLM tends to come out with something I can at least turn into something useful.

It might be reversed though for people who know what they're doing. IF they know what they're doing they might theoretically be able to put together some stackoverflow results that make sense, and build something up from that better than what gets generated from LLM (I am not asserting this would happen, and thinking it might be the case)

However I don't know as I've never known anyone who knew what they were doing who also just copy/pasted some stackoverflow or delegated to LLM significantly.

> Is there any way to distinguish between these two categories?

Yes, it should be obvious. At least at the current state of LLMs.

> There's the long term incentive, but is there a short term one?

The short term incentive is keeping their job.

I was attempting to mock Claude's "You are absolutely right" style of response when corrected.

I have seen responses to PRs that appear to be a copy and paste of my feedback into it and a copy and paste of the response and fixes into the PR.

It may be the that the developer is incorporating the mannerisms of Claude into their own speech... that would be something to delve into (that was intentional). However, more often than not in today's world of software development such responses are more likely to indicate a copy and paste of LLM generated content.

This. May you have great success! My PR comments that I get are so dumb. I can put the most obvious bugs in my code, but people are focused in the colour of the bike shed. I am happy to repaint the bike shed whatever colour they need it to be!

I had one fairly-junior teammate at Google (had been promoted once) who was a competent engineer but just refused to make any choices about what to work on. I was his TL and I gave him a choice of 3 different parts of the system to work on, and I was planning to be building the other two. He got his work done adequately, but his lack of interest / curiosity meant that he never really got to know how the rest of the system operated, and got frustrated when he didn't advance further in his career.

Very odd. It was like he only had ever worked on school projects assigned to him, and had no actual interest in exploring the problems we were working on.

heh. i am making software for 40 years more-or-less.

Last re-engineering project was mostly done when they fired me as the probational period was almost over, and seems they did not want me further - too expensive? - and anyone can finish it right? Well...

So i am finishing it for them, one more month, without a contract, for my own sake. Maybe they pay, maybe they don't - this is reality. But I want to see this thing working live.. i have been through maybe 20-30 projects/products of such size and bigger, and only 3-4 had flown. The rest did not - and never for technical reasons.

Then/now i'll be back to the job-search. Ah. Long lists of crypto-or-adtech-or-ai-dreams, mostly..

Mentoring, juniors? i have not seen anything even faintly smelling of that, for decade..

I love building software because it's extremely gratifying to a) solve puzzles and b) see things actually working when I've built them from literally nothing. I've never been great at coming up with projects to work on, but I love working on solving problems that other people are passionate about.

If software were "just" a job without any of the gratifying aspects, I wouldn't do nearly as good a job.

It seems so obvious now, but it does make me thankful that my training drilled into my head to constantly ask "what is the problem I am trying to solve?". Communication in a team on what's going on (both in your head and the overall problem space) is just as important as the mechanical process of coding it.

I feel that's the bare minimum a junior should be asking. the "this is useful" or "this is slop" will come with experience, but you need to at least be able to explain what's going on.

the transition to mid and senior goes when you can start to quantify other aspects of the code. Like performance, how widespread a change affects the codebase at large, the input/outputs expected, and the overall correctness based on the language. Balancing those parameters and using it to accurately estimate a project scope is when you're really thinking like a senior.

More to the point, I think part of being a senior is being able to dig up code you wrote a few years ago and say “how awful”

Senior level. Still can't sometimes. Just the other day I looked over some code I wrote and realized what a pile of slop it was. I kept wondering "What was I thinking when I wrote this? And why couldn't I see how bad it is till now?" My impostor syndrome is triggered hard now.

Sure have. Finance, research labs, government contracting. Can't wait for people to chime in with their horror stories. I've seen some of the most dysfunctional crap you can imagine.

Then it sounds like you need to train them and also pay them better. Most people just want to stay at one company and not do the grind, but the lack of raises, poor treatment, and much better pay other places is blaming juniors for your companies problems.

"What are you buying with those 20k?"

You keep a good thing going, you buy oil for the machinery, you keep your part of the bargain and do the maintenance. You pay the correct price for the stuff you are lucky enough to have been getting on the cheap.

I like the directness of the question: "Why should I pay more when it won't burn down right this instand if I don't?" This is a question asked all over, and it is dangerous, keeping anything going requires maintenance and knowledge in how to maintain it. That goes for cars and it goes for people.

This is not business, it is miserly behaviour, it is being cheap.

The miser will find himself in a harsh, transactional, brutal world. Because that is the only way for people to protect themselves against him.

>What are you buying with that $20k exactly?

This incentive is entirely backwards. It should be "what are we losing with not spending that 20k?". You lose out on someone used to the company workflow, you waste any training you invested in them, you create a hole that strains your other 3-4 100k engineers, and you add a time strain to your managers to spend time interviewing a new member.

if you really believe you can buy all that back for 120k as if you ran short on milkk, you're missing the forest for the tree.

>Sometimes I wonder if it wouldn't be easier to just fire staff for a week then re-hire them at a new salary.

if society conditions a workforce to understand the issue, sure. But psychologically. you'd create an even lower morale workplace. Even for a week, people don't want to be dropped like a hot potato, even if you pick it up later as it cools. People want some form of stability, especially in an assumed full time role.

In my view, I have observed many good, underpaid engineers because they choose stability over higher pay. Most people are happy with slow and stead pay rises while working at the same company. Companies know this and pay accordingly. Only your top 1-10% of employees need more careful "TLC" to give higher raises and regular off-cycle feedback: "You're doing great. We are giving you a special raise for your efforts." You can mostly afford to lose the rest.

https://codegood.co/writing/why-your-best-engineers-are-inte...

Everyone's kicking the can down the road and we're very soon going to hit points of "no one has experience (or are already working)". Someone needs to do the training. It doesn't seem like school and bootcamps is enough for what companies need these days.

Its the tragedy of the commons. These companies will think they are very smart for doing this, but theyll just foster a culture where there are no competent employees once the current seniors retire

>but instead invests that money in poaching.

give a big enough raise and they won't want to be poached. You won't retain everyone, but your goal probably isn't to compete with Google to begin with. So why worry of the scenario of boosting a good junior from 100k to 150k but losing them to a 250k job?

In some ways you will also need to read the room. I don't like the mentality of "I won't hire this person, they are only here for money", but to some extent you need to gauge how much of them is mission-focused and how much would leave the minute they get a 10k counter-offer. adjust your investments accordingly and focus on making something that makes money off that.

What's the solution? Locking juniors in with contracts? Vesting cliffs?

some places like Amazon operate around the churn. Keep everyone anxious and they won't try to collectively bargain nor ask for raises. They won't be around long enough anyways.

Where do you think that money is going?

No. Good in that developers are exposed to outside skills and ideas they wouldn't be by spending 10 years doing the same thing.

Yes, we are working on some guidelines, but there are layers of bureaucracy...

We need to develop new etiquette around submitting AI-generated code for review. Using AI for code generation is one thing, but asking other people review something that you neither wrote nor read is inconsiderate of their time.

At least they're running the test suite? I'm working with guys who don't even do that! I've also heard "I've fixed the tests" only to discover, yes, the tests pass now, but the behavior is no longer correct...

> Which stands to reason you'll need less of them.

Depends on how much demand there would be for somewhat-cheaper software. Human hours taken could well remain the same.

Also depends on whether this approach leads to a whole lot of badly-fucked projects that companies can’t do without and have to hire human teams to fix…

> This is what I'm doing, Opus 4.5 for personal projects and to learn the flow and what's needed. Only thing I'll disagree with is how the work takes similar amount of time because I'm finding it unbelievably faster.

I guess it depends on the project type, in some cases like you're saying way faster. I definitely recognize I've shaved weeks off a project, and I get really nuanced and Claude just updates and adjusts.

I've seen Product Manager / Technical Program Manager types leaning into using AI to research what's involved in a solution, or even fix small bugs themselves. Many of these people have significant software experience already.

This is mostly a good thing provided you have a clear separation between solution exploration and actually shipping software - as the extra work put into productionizing a solution may not be obvious or familiar to someone who can use AI to identify a bugfix candidate, but might not know how we go about doing pre-release verification.