Comment by strickjb9

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

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.

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.