Depth beats breadth, especially early on
It is tempting, especially early in a robotics career, to try to become competent at everything at once: a bit of mechanical design, a bit of embedded firmware, a bit of computer vision, a bit of controls. In practice, this rarely produces someone who is hireable, because robotics teams are usually small and need people who can own a specific, hard problem without hand-holding. A strong mechanical designer who deeply understands tolerancing, material selection, and manufacturability is more valuable to an early team than someone who can sketch a linkage but has never taken a design through to a working, manufacturable part. The same is true for embedded systems, computer vision, and controls: real depth in one area, to the point where you can debug it under pressure and make good tradeoffs independently, is what gets you hired and trusted with real scope.
This does not mean breadth is worthless. As you grow, understanding roughly how the adjacent disciplines work, enough to communicate clearly with a controls engineer if you are a mechanical engineer, or with a mechanical engineer if you are writing perception code, makes you dramatically more effective on a small team, because robotics problems constantly cross discipline boundaries. But that broad fluency should be built on top of one area of real strength, not instead of it. If you are early in your path, pick one lane, mechanical design, embedded systems, computer vision, or controls, and go deep enough that you could reasonably be the person a team relies on for that piece.