I'm currently a Python developer and machine-learning engineering intern. I understand the basics of Linux, networking, databases, backend systems, Docker, cloud platforms, and distributed systems, but I'm not deeply specialized in any of them yet.
I want to become a much stronger ML engineer rather than simply collecting more Python libraries and frameworks. I'm considering going deeper into operating systems, networking, memory and filesystems, C/C++/Rust/Go, distributed systems, profiling, CUDA, GPU programming, Triton, and lower-level systems work.
However, I'm less interested in a topic roadmap and more interested in the learning process that actually made people better engineers. Did books followed by hands-on implementations help? Did personal projects, open-source contributions, reading production code, debugging, code review, or working on difficult real-world problems make the biggest difference? How did you avoid reinforcing poor design habits when working without much supervision?
I'd especially like to hear what worked early in your career and how you practically learned areas such as C, Linux, CUDA, or distributed systems. What habits or experiences had unusually high return on investment?
5 Answers
Since you already have access to experienced engineers, ask one of them to walk through a change you made. Explain your approach and the alternatives you considered, then ask about the trade-offs behind their feedback. Applying that reasoning to your next change is much better than copying patterns without understanding when they fit.
For solo work, use measurable experiments. If inference is slow, predict the bottleneck, profile it, change one thing, and measure again. Tests and benchmarks can validate behavior and performance, but another engineer is still needed to review design quality.
Real responsibility accelerates learning. Being responsible for a project or production issue that is slightly beyond your experience forces you to investigate deeply and make decisions instead of passively consuming information. Production incidents are particularly educational because they reveal how systems behave under failure, not just how they are supposed to work.
The important part is to follow up afterward: document what happened, identify the incorrect assumptions, and improve the system or monitoring so the lesson sticks.
Avoid learning technologies just because they seem impressive. Start with a goal or an engineering problem, write down the requirements and your assumptions, and design a simple solution before implementing it. You will probably redesign it several times as you discover missing constraints, and that cycle teaches a lot about architecture.
Keep notes on the decisions, results, complexity, and performance. Reimplementing one part with a different language or approach can also teach you when each option is useful. The purpose is not to collect tools, but to build judgment about trade-offs.
The biggest improvement came from building projects just beyond my current ability, then actively looking for ways my assumptions were wrong. Books and videos helped explain the concepts, but implementing them exposed the gaps. After getting stuck, I would read production or open-source code to see how experienced engineers handled the same problems.
I found it more effective to choose one area at a time: build something, debug and profile it, compare it with real systems, and repeat. Debugging and code review were especially valuable because understanding why a solution was incorrect or inefficient teaches more than merely getting it to work.
Pick a concrete problem that genuinely interests you and make it require the technology you want to learn. A small database written in C, for example, can teach memory management, file formats, and disk I/O far more vividly than studying those topics in isolation.
The project does not need to be novel. It just needs to be difficult enough that you repeatedly encounter problems you cannot immediately solve.
That distinction between automated validation and design feedback is useful. I’ve mostly relied on tests and benchmarks, so I should make more of an effort to get another person to review the reasoning behind the solution.