FAQs For a Software Engineering Hiring Manager - Part 5 of 5: On Managers, Growth & Progression

Technical Interviews have evolved a lot since I transitioned from being a Software Engineer to an Engineering Manager. Particularly in the post-Covid era, there's been a greater emphasis on the person, which I think is an important and welcome change.

Over the decade of interviewing hundreds of coders, I've also had the pleasure of working with various bootcamps, colleges, and hundreds of individual job seekers on LinkedIn. Across all the changes over the past years, across the various locations and mediums, something remained consistent throughout: The questions I get asked.

With that in mind, I thought - why not make a FAQ from my perspective as a hiring manager?

While this is my perspective, it's based on years of observation and supporting data. But that being said, advice is not fact. You may disagree with certain points, and that's OK. Opinions we disagree with allow us to better understand our own views. At best, I hope these responses help you land your dream job. At worst, I hope they'll help you form your own ideas on how to approach your career.

In this part, I’ll focus on the questions I’ve received about resumes.

On Managers

1. How often should I be meeting with my manager?
   You should have regularly scheduled one-on-ones. No less than once every 2 weeks, but ideally once a week. Regular meetings are crucial to tracking how are you doing so that you're set when performance reviews come around.
   

   
   

2. What should we be talking about when we meet?
   Don't have a status meeting. Don't give an update on the project you're working on. If your manager seems to mostly focus on whatever work is currently in flight, ask them if you can also discuss your overall performance.
   
   1:1s are great times to talk about your objectives, how you're growing, where you think you're weakest, where you want to be in 6 months, 1 year, 3 years. It's also a good time to focus on areas that are normally outside your purview. Maybe you've identified an inefficiency - or maybe you've felt someone else isn't fully performing to the best of their ability. While you want the main focus of your 1:1 time to be with your manager, you also want to make sure that you're both on the same page come performance review time. If you're having candid conversations regularly there should be no surprises.
   
   Feel comfortable with even asking, very plainly: "How am I doing?" or "Is there something I should be doing that I've not been doing?" or "Where am I weakest? What should I focus on learning/growing?"
   
   These questions are direct, and some managers have a hard time with candid and honest criticisms, even if it's constructive and actively being requested. Don't be afraid to ask for it a few times. In the absence of a meaningful answer, give your own. "Well, it's great to hear you think so - but here's what I'm trying to learn on my own. Would love to get your thoughts..."
   

   
   

3. I'm not sure my manager is invested in my growth, or really knows me. What should I do?
   Not all managers will be invested in your growth, and you don't need their investment in order to grow. Of course, when they are invested it can be really rewarding - but I've also learned and grown a lot under managers who only cared about results.
   
   It's ultimately a matter of your own perspective and how you apply yourself to different challenges. You'll always encounter people who are difficult. Learning to work with different styles will greatly help you.
   
   Case in point, I once had a manager who never provided feedback. Neither positive or negative. No criticisms, ever. Given that I was still pretty junior at the time, I needed the feedback but wasn't getting it. Eventually, I grew to realize how he communicated expectations and how he measured quality. I got there by mostly observing his interactions with others. He had the habit of casually talking around problems and ambiguously assigning ownership and accountability. But I clued into the fact thatifhe wasn't talking about something - that generally meant he was good with it.
   
   I'm not defending the style, and it definitely was a struggle - but I couldn't easily change his style, nor could I easily change managers.
   
   Most importantly, after learning his style - it became as effective for me as anyone who was more explicit. Once you decode an illusion, it never fools you. As a result, years later I had a manager with a very similar style. That manager was largely disliked by the team - but yet, having cracked the code with a different manager, I was successful with them.
   
   That's one approach.
   
   Other managers are a lot more receptive to criticism and suggestions. Especially if they're early in their management careers, they are learning how to adjust from an individual contributor to a manager. They need help in learning that people are their priority. Managers can learn a lot about their role from their team members, and that's where the 1:1 can be really valuable.
   
   The Manager's Path talks about how, to be a good manager, you should learn how to be managed. The sad truth is many managers learned poor management from their own managers. Learning to manage upwards by setting expectations and communicating openly will help you - whether it's with respect to your code, the product you're producing, your own growth. The more you relate it all back to relationships with people (and not roles), the more successful you become.
   

   
   

4. I feel like my manager isn't being very transparent. What should I do about that?
   Being a manager comes with a lot of difficult responsibility. You're made aware of different challenges and risks, and you have to carefully navigate the space while being accessible and honest with your team. Full 100% transparency may sound ideal, but it can actually create more chaos than you may want.
   
   As a manager you learn about budgets, customer attrition, business challenges. Managing through those circumstances is a balancing act. Sharing too much (in the interest of transparency) can create chaos and uncertainty in the team's life. Sharing too little creates a sense of distrust. Saying*"Trust me, things are good..."also creates distrust.
   
   Hearing"We're about to lose our highest paying client..."* doesn't help anyone. It's speculative, for one. Stating things in these terms creates chaos, stress, anxiety, and uncertainty. No one does their best work when they're hearing that kind of news.

   
   

   2 weeks later, the manager may then update everyone with "Great news! They've signed on for 2 more years!" Or they may say: "I called it. Yeah, we lost them. This is going to impact our budget..."

   
   

   Managers who try to be fully transparent create distracting emotional roller coasters.
   
   A good manager will address lingering concerns or suspicions while doing their best to avoid introducing unnecessary chaos. They focus on facts and share them as they materialize. They'll avoid speculating or editorializing.

   
   

   If, in the earlier example, the team begins sensing something is going on a good manager will step in to say: "I know you've noticed the stress the sales team has had lately. They're dealing with frustrations from our largest customer - the current experience is slowing them down. We're working closely with them to get a better idea of how we can address those issues. You may see me get pulled into a few urgent calls - but to be clear, this is a priority for me, not for you all. I'll let you know if/when it ever needs your attention. For now, it's too high level to be worth distracting any of you guys with it."

   
   

   Someone on the team may ask: "Are they cancelling their contract with us?"

   
   

   And the manager would say: "That's too speculative. Right now, we're still looking to understand the gap in expectations. Keep building against the backlog because that work has been vetted and prioritized. If priorities shift, you'll be part of the conversation."

   
   

   Managers are often asked questions that require their speculation, and that can also be difficult. "Will we hire for more roles next year?" or "Are we going to get the investment we need from the business?" or "Will we have the budget for me to get a raise?"

   
   

   Good managers won't give concrete answers to those questions and will probably give you the answer you are expecting: "It depends."

   
   

   My recommendation is, if you're seeking transparency, ask questions that they can answer honestly and without speculation: "How am I tracking against my yearly objectives?" or "Will you be asking for additional headcount next year?" A safe follow-up could be "What if we don't get the additional headcount?"

   
   

   This last question isn't asking your manager to speculate; it's asking them to share their contingency plan.
   

   
   

5. How should I ask for a raise?
   First off, do some research. It's often true that job-hopping will also increase your salary faster than staying at the same place - but it can also damage your reputation if you hop around too frequently. A lot of companies have a 3-6 month ramp up. If you leave shortly after a year, or even at the national average of 18-24 months, your contribution will be pretty minimal.(Incidentally, if you're worried about handling attrition, you should check out my primer on Systems Debt.)
   
   Leaving too soon means it's harder to share our outcomes and impacts on your resume. You're not giving yourself enough time to be successful - and eventually the hopping will catch up to you.
   
   So, do some research. Find out what you could make if you were to leave, but also find out what you should be making if you stay. It could be less - but it shouldn't be below the average of what people make at your level.
   
   Next, track your work and progress over the year. Start at the beginning of the year - don't wait until the end of the year to quickly summarize it all.
   
   Instead, keep a running log of your "wins" and contributions, and use your 1:1s & quarterly check-ins to talk through those and show your progression.
   
   It's good to be aware: many managers suffer from recency bias when doing annual reviews. If you had a strong first half of the year, but then later slowed down, they'll remember the slow down. On the flip side, if you were lazy in the first part of the year but really applied yourself in the later half, they'll likely forget your laziness.(That being said, I wouldn't advise being lazy if you're going to ask for a raise...)
   
   Don't track your progression in a vacuum. Keep your manager informed and involved so you don't unload a long list of wins at year's end. Instead, go into 1:1s and mention a recent accomplishment. Ask them to break down for you what you could have done better, if they believe you can take on a larger challenge, etc. Make them a part of the discussion.
   
   The easiest raises I've given as a manager is when all the work was done for me. I didn't feel like I had to advocate for someone out of the blue. Instead, I could be talking about someone's progression on my own 1:1s. I could be prepping my own manager for the inevitable ask:"Sally finished that one major project ahead of schedule - and not only that, but she's also continued to grow beyond her current role. Just giving you the heads up - when we do annual reviews in 4 months, I'll probably be looking to promote her and give her a raise. At the pace she's growing, I don't see us retaining her if we don't recognize her work."

   
   

   In a nutshell, when you're asking for a raise - plan early to be asking for a raise and know that you're not asking your manager for the raise. You're helping your manager get you a raise.

   
   

On Growth & Career Progression

1. When should I leave my current role?
   I'll often point to a study that shows tech professionals stay with a company for18-24 months before looking for their next role. I've seen this number a few times, and it's also been an anecdotal observation as well.
   
   If you think of that period, it generally makes sense: 18-24 months is long enough to have shipped some meaningful projects, it's also long enough to burn out, grow bored, start re-evaluating your priorities.*Maybe you got married? Maybe you had your first child? Maybe you bought a house?*A lot can happen in 18 months, and even more in 24.
   
   Incidentally, if you're a manager, isn't it funny howwe'll ask candidates about their 3 year goals, and then we're surprised when half that time passes, and people leave? It's almost as if...we've...not...actually...invested...in...them....
   
   Anyway, does this mean you need to leave at 18 months? Not at all. In fact, I don't think you should unless you're not getting the support you need. I've stated this in another response to a question, but I'll re-state it here: if it takes you 3-6 months to ramp up at company, and you leave at 18 months, that only gives you 12-15 months to have made a meaningful contribution. It's definitely possible to do that - but your opportunity is lower, and your impact is less measurable. Plus, you never want to be the candidate who is ditching their team in the midst of a super big project that is nearing release. I've seen many candidates who are on the cusp of delivery - and unless they have a compelling case for why they are leaving, it can be a red flag.
   
   The thing is: getting a project over the goal line is tough. The first few months are super exciting, but that excitement decreases quickly and then it's a slog. You start to encounter bugs, things you had beautifully designed have become to get cluttered and sloppy. You've had to cut corners. You're increasingly less proud of what you're delivering and quicker to pass the work on to others. You lose the desire to see it through. While tackling this problem is worth aseparate article- the simple point is that there's lots of value in seeing a project through.
   
   If you're getting antsy and want to leave, ask yourself why. You may be unhappy with the company, or maybe the work has lost its novelty. If you struggle with that, and always get distracted by bright and shiny new toys, try to learn to trade novelty with nuance. As you learn to appreciate nuance, projects remain appealing. You start to broaden your perspective around problems and come up with new solutions. The experience you gain from getting a project released is huge - and it'll help you fight the feeling the second time you butt up against it.
   
   So, when should you leave? Either when:
   

   1. You're in a toxic, unprofessional, negative environment.
   2. Your growth has been stunted, or you're hearing false promise after false promise,
   3. You're being drastically underpaid/underappreciated,
   4. You've stopped learning,
   5. An amazing opportunity has come your way that you can't pass up,
   6. Your personal priorities have shifted

   
   The important thing is to always try to leave on good terms. Don't burn bridges, keep connected with the supportive people. You probably won't return to that company, but those people will help you build your network.
   

   
   

2. Am I networking correctly?
   What do you expect to get out of your network? If you have an answer to that, then you're doing it wrong.
   
   Your network is made up of professional friendships - and any good friendship doesn't come with expectations. They're supportive, they're genuine, and they may or may never have a big pay-off. Your goal, with any kind of friendship, is friendship. If any other benefit comes out of it, that's just an unplanned perk.
   
   The larger (and more genuine) your network, the greater the odds of realizing some kind of perk - maybe a connection into a company you've always wanted to work at, maybe a connection to a mentor, maybe you can learn from them, they become a resource, whatever - but you can't make that your end goal and you have to be willing to provide similar perks for others.
   
   Connect with people because we are social creatures*(even the introverts)*, and we long ago realized that there's power in connections.

   
   

   Reach out to people on LinkedIn, at virtual events, at live events - and have genuine (non-needs-based) conversations.

   
   

3. What personality traits should I highlight, emphasize, grow?
   This one is an easy one: Growth. Have a growth mind-set. Embrace and be empowered by the fact that you don't know everything, but that you can learn it. Be a forever learner. Be interested in things.
   
   Skill is important, but candidates who also convey that they're continuously looking at how to grow are the best hires.
   
   You can learn new tech stacks, new methodologies, no paradigms and technical concepts. But there's so much more about that. Learn about productivity methods, learn about leadership, learn about management skills (even if you don't want to manage), learn about the industry you're in, learn about your product, its history. People who learn have infectious enthusiasm.
   
   Share what you're learning. Learning is the one thing that you can unabashedly brag about. I personally love learning, and I love being taught things. When someone teaches you something, you see them light up with energy and passion.
   
   Lastly, and critically: the opposite of a learner is someone who is stubbornly stuck in the same spot, refusing to budge. Don't be that.

   
   

4. Do I need to constantly be coding?
   Not constantly. There's lots of people who have had successful careers and only code at work. It can definitely help you grow your skills, it can definitely help you stand out as a job candidate, it can definitely help you keep your skills sharp when you start to code less professionally (yes it will happen, even if you stay a coder.)
   
   Don't just read theory, put it to practice. Even if to get a sense of how it works.
   

   
   

5. What books should I read?
   There are so many great books out there - and in the interest of being a forever learner, you should read more than what I've listed here. These books have had a profound impact on my own career, and I'm always quick to share them:
   

   • The Manager's Path by Camille Fournier
   • Working Effectively With Legacy Code by Michael C. Feathers
   • Agile Project Management with Kanban by Eric Brechner
   • Cracking the Coding Interview by Gayle Laakmann McDowell
   • Programming Interviews Exposed by John Morgan
   • The DevOps Handbook by Gene Kim
   • Dealing with Difficult Customers by Noah Fleming
   • Thinking in Systems by Donella Meadows
   • An Elegant Puzzle by Will Larsen
   • Cracked It! by Bernard Garrette
   • Agile Estimating and Planning by Mike Cohn
   • The Five Dysfunctions of a Team by Patrick Lencioni
   • Accelerate by Nicole Forsgren
   • Measure What Matters by John Doerr
   • The Success Equation by Michael Mauboussin
   • Start With Why by Simon Sinek

   
   Have others you'd recommend?Send them my way!

   
   

It's worth noting, all these responses are my own subjective views that I've generalized across small and large companies. They reflect my personal style, but I'll also happily submit they're not 100% right either. It's what's worked for me - but I love getting input and thoughts from others.

Have any questions I haven't answered? Connect with me on LinkedIn and send them to me!

Also published here.