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