Comment by siliconc0w | Hacker News Reader

Comment by siliconc0w | Hacker News Reader

Parent Full thread

Only non-engineers listening to VC-hype on podcasts think that AI can replace fully junior engineers. Here is a problem I recently asked a junior dev to solve:

Our service occasionally gets especially expensive requests that amplify to our dependencies, one of those dependencies have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.

AI is pretty far from able to do this. A cracked out vibe coder maybe could have just added a one-off naive rate limit algorithm pulled from stack overflow or maybe pulled in an unmaintained 3rd party 'rate-limit' package and called it a day. And that would be fine for a MVP but in large organizations figuring out what to build, how to build it, and getting agreement with stakeholders is way, way more work that doing than actual implementation (which still rarely can be one-shotted and needs a lot of hand-holding and iteration to get decent solutions).

The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. In most organizations junior devs are not expected to design solutions for open ended problems on their own.

For Junior, problem is already triaged/scoped, low criticality, solutions to this kind of problem are provided but may need judgement or extension to identify the best approach. Design and implementation should be based on requirements gathering from immediate known stakeholders. May need low-level supervision/guidance.

For mid-level, they are capable doing more of the problem triaging/classification and can handle vaguer, larger scoped problems. They can identify the correct stakeholders to engage with and, ideally, influence. Can identify the most likely best approach amongst a set of possible approaches. Guidance is high level- like a weekly or bi-weekly 1:1. Better design taste as far as how to measure outcomes or rollout changes safely.

For senior you're ideally solving classes of problems rather than specific problems. You're charting a longer term roadmap that generates work and exerts influence amongst number of teams to drive long-term business outcomes. You are mentoring juniors/mid-levels so they're setup for success and have the right work at the right level of guidance at the right time to grow in their careers.

While I would not have used the descriptor "dependencies", substitute that with the term "partners":

  Our service occasionally gets especially expensive requests 
  that amplify to our partners, one of those partners have 
  started complaining that our bursts of traffic are 
  impacting other users, talk to them and propose a solution 
  that aligns with our different requirements.

> The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions.

With the clarification above, I believe a junior dev could perform this task, even if the proposed solution is known to be a learning exercise.

The immediate value to the team is the collection of partner concerns.

In my experience, the problems given to juniors are often open ended “improve this” or “fix this” type projects, but smaller scope or lower priority things that more senior devs would just never get to.

I will say though, needing to socialize across other teams to understand the problem and drive the correct solution does strike me as more mid/senior level work.

In my experience, those are the worst sorts of jobs to give juniors if you want actually throughout though. They need direction, releasable pieces, etc. they don’t know how to break something apart into small, releasable parts yet. That’s a major thing more experienced devs can teach them.

Why not? How else do you get these skills without doing it?

Job / Position description means something more... It means that your expected to do the task and perform well at it or you will be let go.

Generally you don't put those skills in a Junior PD, but you would expect a Junior to take on these tasks if they hope to progress. The Mid level PD would have it listed and as the junior shows they can meet each and every additional skill, the option of a promotion becomes available.

None of this seems hard for a junior dev tho... it just takes time, which I'm assuming the others workers don't really have with more pressing matters making this a great issue for juniors to grit their teeth on.

Note the words "on their own". They would be paired with a more experienced dev to collaborate with.

That seems self-selected and biased toward their own experiences.

When I was a junior I was allowed and given free reign to design the test system for the product and implement a design system for the frontend team.

Junior doesn't mean stupid, it just means less experience. How else do you expect people to gain experience if you don't give them basic independent projects?

My first job out of coll, task 1 was improved query perf on our test result database. job 2 was "get performance tests working again."

Both 100 % open ended problems.

That task seems perfect for a junior dev. It's open ended but low risk and not interacting with multiple teams as directly

It's different from the one described above

> talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.

I'm sure some junior devs could do this but the majority wouldnt be able to

Reply on news.ycombinator.com