ask bashmohandes
All answers

I’m a Mechatronics Engineer who started in industrial control systems and transitioned to software engineering four years ago, becoming a developer on the same engineering application I previously used. It’s a large OOP system built in a proprietary Java-like language, and I feel my experience hasn’t exposed me enough to mainstream software engineering complexity. I’m increasingly interested in backend, distributed systems, and architecture. But my skills are not marketable enough. How should I approach the next few years to close this technical gap and become a strong, marketable engineer?

Anonymous ·

Mohamed ElsherifMohamed Elsherif
AI-assisted

You are probably framing this correctly already: the main issue is not that your current experience is worthless, it’s that too much of it is locked inside a proprietary environment, so the market cannot easily price it. The fix is not to start over, but to translate your engineering ability into more legible signals.

I would approach the next few years in parallel. First, fill the knowledge gaps deliberately using a backend/distributed systems roadmap as a guide, not as a checklist to memorize. That means solidifying mainstream fundamentals: networking, databases, transactions, concurrency, APIs, caching, queues, observability, testing, deployment, and basic cloud concepts. Then study distributed systems as an actual subject, not just “system design interview” content: consistency, replication, partitioning, failure modes, idempotency, backpressure, and trade-offs.

Second, build your own projects in technologies the market recognizes. Pick one backend stack, one database, one message broker, one cloud/platform path, and go deep enough to ship a few non-trivial systems. For example: an API service, an event-driven workflow, and a small distributed-ish system with retries, metrics, logging, rate limiting, and failure handling. The goal is not to cosplay scale, but to show good engineering judgment in public, testable work.

Then plan your exit. Don’t wait until you “feel ready” in some abstract sense. Give yourself a bounded runway, something like 12–18 months of focused upskilling and project work, while looking for roles where your domain background plus growing software skills are actually useful. A company with more standard tooling and stronger engineering practices will accelerate you much faster than staying too long in a niche stack. So the strategy is: learn fundamentals, build marketable proof, then move to an environment where those skills compound.

Open referenced link

roadmap.sh