DEV Community

Gergely Orosz
Gergely Orosz

Posted on

Ask the engineering manager: career development paths in tech companies from junior, through senior, to staff

I'm a hands-on engineering manager, with a few years' of engineering management, and a decade worth of engineering across distributed systems, mobile, web and desktop development.

The past few years, I've been helping engineers on my team grow from junior, through senior to beyond senior positions, like staff/principal. I've had pretty good success and a great team to work with, on the way.

In an effort to give back, I've been blogging about my learnings. I've also started writing a book on how to grow, as a software engineer in tech companies, from small ones to larger ones like Microsoft, Uber, Facebook, Google and the like.

I'm be happy to answer questions on career development. - and your questions might also give me further inspiration for topics to cover in this book.

Top comments (22)

Collapse
 
gergelyorosz profile image
Gergely Orosz • Edited

The most common mistake I've seen is engineers thinking they can still be engineers, while also being managers. As one of the managers who I talked with, told me: "When I went into management, I spent 80% of my time coding, the other 80% on management. It did not help the team and I burned out, even though I worked harder than ever.". This manager later went back to being an engineer, realizing they liked that kind of work better. To avoid this, I would suggest to stop coding for the first few months of being a manager, however tempting it would be. This will force you to focus on people, and the managerial skills you might be lacking.

The other common mistake I see is people assuming they'll be good managers, and not seeking frequent feedback from various channels, like mentors, peer managers and asking their new reports (after they built up trust). The best time to build up habits that will make one a good and efficient manager is in the early days of this role - but seeking and getting good and actionable feedback is key. To avoid this: gather people who you can get honest feedback from, ask for the feedback, listen and see if you can or should change your behavior.

I also collected some things that helped me transition into engineering management.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

I personally think that think candidates have often an very inaccurate mental model of what the interview looks like from the recruiting side

Is that also your experience?
if yes, what would be useful for candidates to understand better in that regard?

Collapse
 
gergelyorosz profile image
Gergely Orosz

Yes and no. Bigger companies, that have in-house recruitment teams usually explain the process a bit better. But I do see that candidates don't really understand how the process actually works. Until I became a hiring manager, I didn't, either.

On one end, understanding how the process works is helpful. However, it rarely changes the fact that preparing for interviews helps, luck is often involved (in ways that might be invisible to candidates, even) and it's never a bad thing to stay positive, throughout the process.

I'll probably write more in-detail about this, as it's easy to go down the rabbit hole. If you have questions on specific parts on the process that you'd like to learn about, I'm happy to share what I know.

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard

I think that would help a lot if you do that.
I think devs obsess over things that don't matter for the company itself.
So if you can liberate them from that stress...

Collapse
 
willvelida profile image
Will Velida

Hi Gergely,

What advice would you give to junior software engineers who want to move into a intermediate/senior role? Are there specific things you would look out for when promoting juniors?

Thanks for doing this AMA! 😊

Collapse
 
gergelyorosz profile image
Gergely Orosz • Edited

Hi Will! I'm writing a book pretty much on this! It's a broad subject and I won't be able to fit all my thoughts in a reply here. But here goes.

First, distinguish between professional growth and promotions. Getting promoted is a different process altogether and here are is my advice on how to get promoted as a developer.

Taking a step back from a promotion, here's what I expect from an intermediate developer:

  • Competence with coding. You can turn an idea and write solid, good, quality code, with (unit) tests included. You know your tools well: the debugger, you refactor with ease - and are unafraid to do so - and have mastered one or more programming languages.
  • Unblocking yourself. When you come across a problem - it could be on coding, on specification or other areas - you find a way to remove this blocker. This might mean coming up with workarounds, or it might just mean finding the right person to tell them "I need your help to do XYZ". And not stopping until someone helps you resolve it.
  • Getting reasonably complex projects done. You're able to break it into smaller pieces, make progress and get it done.
  • Curiosity to learn. You know there's plenty to learn and you do so. You pick up interesting projects, try out different technologies and approaches. You have written "Hello World" or done simple applications in multiple languages, even if just an exploration.

For seniors, I additionally expect:

  • Pragmatism and choosing the appropriate tradeoffs, much of which comes from "been there, done that, burnt myself" experience. Should we build a prototype or a production-ready MVP? Do we manual test or write integration tests? Do we add versioning to the API from day one or leave that for later? And so on. Seniors make reasonable choices that they can explain the "why", in the context of the project.
  • Good stakeholder communiciatiton. Seniors can be the point of contact for larger projects - and collaborate well with business stakeholders.
  • Mentoring/coaching of less experience developers. They grow more junior devs by pairing, doing good code reviews, giving gentle and constructive feedback and delegating well - and letting people figure things out, but being there to support them.
  • Familiarity with other stacks than your own. If you're a backend developer, you have some idea of client-side challenges and have an understanding of the things developers on that end need to worry about. Same thing when you're on the client side: e.g. if you're a web engineer, you have an understanding of APIs, how data storage works at a high-level and e.g. caching approaches between the backend and the client-side. You don't need to be super hands-on, but you also are not ignorant of areas you work with. This enables you to work better with other teams around you and make pragmatic decisions on e.g. what stack to move parts of the business logic to.

Also, don't forget that mid-level and senior will mean something else at each company. If you're lucky, your company might have a career ladder with competencies. Regardless, understand how the promotion process works at your company.

And if you're interested in more detailed advice, sign up to get notified when my book on growing, as a developer will be available - an announcement will be coming soon!

Collapse
 
endorama profile image
Edoardo Tenani

Hi Gergely, thanks for this AMA!

What do you think are some prominent errors a manager makes or may make when trying to "level-up" their engineering team? (Like in what are the challenges involved and where are the traps along the way)

Collapse
 
gergelyorosz profile image
Gergely Orosz

Hmm, this seems like a pretty vague question. Engineering managers, who are already thinking of how to "level up" their engineering team are already doing something right.

I hope this means they are delegating well, setting a vision, helping the team and its members be more autonomus, and the like.

The biggest mistake I could think of is not looking for feedback from the team and team stakeholders. A "leveled up" team should have better output from the perception of both the stakeholders, and the team members. Blindly making what a manager would think of improvements, without observing how they work, will probably not help.

Collapse
 
endorama profile image
Edoardo Tenani

Sorry for having been vague, the answer is along the line of what I was expecting.

Thanks!

Collapse
 
gergelyorosz profile image
Gergely Orosz

I notice that it’s much tougher getting into the industry as someone who is self-taught, or with a bootcamp background than I’ve seen in the past. This might be as junior/entry level jobs have not grown, but especially since bootcamps became popular, people applying for them has skyrocketed, and will continue to do so. Bootcamps also make it sound like it’s easy to get into this industry, when it is not. And even after that first job, it’s really tough to stay in for the first few years.

I wish I had specific advice, but unfortunately, I don’t. Thr best I can offer is suggesting you network locally and try finding local mentors from similar background as yourself, who have succeeded and can give infinitely more applicable tips than myself.

Collapse
 
tmohammad78 profile image
mohammad taheri

Thanks for post , I have very low experience , 1.5 years in React , Is this book understandable for my level ? because I read that it's book is professional and I think it's so heavy , but I'm so interested to learn it

Collapse
 
robinaspman profile image
Robin Aspman • Edited

What importance do you think computer science, leetcode, data structures and algorithms has on the tech industry overall?

Collapse
 
gergelyorosz profile image
Gergely Orosz • Edited

On computer science, I'm unsure what you meant by the question. Computer science and the tech industry are close: the tech industry is built on top of computer science fundamentals. While it's possible to code without understaning these fundamentals, the more experienced one gets, the more they run into parts of it, and the more they tend to self-learn things.

Data structures and algorithms are an area every engineer needs to understand, in order to work at a tech company, that has these as an entry-level requirement. I am less fan of algorithms, and am seeing some companies (like Uber) place far less emphasis on this. However, data structures are key, both at interviews, and it's a frequent thing you use day-to-day, when deciding e.g. how to represent data in-memory.

Tech companies try to gauge how well someone can code in an hour. Data structures and algorithms questions work well great with this kind of constraint. It also means hiring for people who can go beyond frameworks, and could (and sometimes do) re-implement these from scratch. It's a useful skill to be able to cut though abstractions, all the way to primitve data stuctures that the language supports.

Leetcode is the most popular way to prepare for these interviews. With an industry, where for every position at a decent tech company, there are easily 10-100x qualified applicants, this is the homework people need to do, in order to demonstrate coding on the spot. Nailing the coding / data structures / DS&algo interview is the new minimum bar to make it into many of these places. I'm not a huge fan, but I also put in my time to prepare for them, and this is how I made it into e.g. Skype and Uber and to offer stage at Facebook. It made me a better engineer to some extent, and it's a widely advertised criteria at these companies.

The fact that these interviews are prominent, and spreading, is a sympthom of fewer junior jobs being available with little to no experience. It also shows that companies are able to fill these jobs this way. My advice is to beef up your data structures&(basic)algorithms knowledge. Do it once, and this knowledge will make switching jobs, or getting into better tech companies much easier. It's also knowledge that won't grow stale anytime soon.

(PS: this has been the case for large tech companies, see Get That Job at Google from 12 years ago, which is still just as timely as back then)

Collapse
 
robinaspman profile image
Robin Aspman

Thanks for the answer, tons of value!

Collapse
 
tam360 profile image
Mirza

do you consider the idea of 10x hacker and full stack developer a myth or is it a realistic paradigm? what's your stance?

Collapse
 
gergelyorosz profile image
Gergely Orosz

I personally see people like the 10x developer to be damaging at a team level. I would argue the "10x developer" and the "brilliant jerk developer" are often close to each other. This kind of culture celebrates individual contribution with little collaboration, but at the cost of a dysfunctional team.

In some circumstances, this could be a good thing: like a cash-strapped startup, who can only afford to hire one or two developers would thrive initially working with such a person.

However, the way I look at it, I'm looking to build high-performing teams (and later, high-performing organizations). With the right people and right motivation, some teams will work 2-3x as fast or as good, as others. The industry, as a whole, seems to be moving away from the 10x developer concept, in favor of teamwork and mentorship.

Collapse
 
tam360 profile image
Mirza

How much does economics come into play when hiring software engineers? I think companies whether small or big want to increase there profits and 1 way of doing is to hire in 10x hackers/full stack devs in small numbers.

Another problem which I see with this paradigm is burnout. By having 10x hackers to do everything, companies are becoming complicit in the outcome which mentally & physically stressful. Working 40-50 hrs (even 70 hrs especially if you're a video game developer) on every level of application development is unrealistic.

Employees are humans not androids......

Collapse
 
daveford profile image
Dave Ford

Do you have any advice for anyone who is at a point in their career where they are trying to decide if they want to go into management or stay technical?

Collapse
 
gergelyorosz profile image
Gergely Orosz • Edited

Learn more about what management is and take steps to test out the waters, to see if it’s for you. I’ll actually be posting a longer blog post exactly on this topic early next week and I can link it here as well.

In the meantime, gaining breadth or depth in tech is a good way to keep growing. If you commit to the management path, your tech skills will likely slow growing, and might even get reduced.

I am happy that I went into management after I was very solid senior engineer with 10 years industry experience, having gone deep in many technologies: desktop, web, Windows Phone, iOS, Android, distributed backend systems. It both gave me solid technical backing, and it’s much easier to keep my skills sharp, with less effort.

I have seen people with 2-4 years experience move into management, only to feel overwhelmed by not being able to coach senior engineers with 10-15 years experience, as they’ve never been there. The better ones went back to being engineers for a few more years, getting to a good, senior level, before going back into management.