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 (19)
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.
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?
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.
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...
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! 😊
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:
For seniors, I additionally expect:
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!
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)
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.
Sorry for having been vague, the answer is along the line of what I was expecting.
Thanks!
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.
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
do you consider the idea of 10x hacker and full stack developer a myth or is it a realistic paradigm? what's your stance?
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.
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......
What importance do you think computer science, leetcode, data structures and algorithms has on the tech industry overall?
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)
Thanks for the answer, tons of value!
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?
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.