I'm continuing my series of posts this week to earn more GHT for my donation lottery with another post about my job. This time, I'm coming from the angle of telling you what I tell other software engineers about getting hired and getting promoted.
So, you want to get hired as a software engineer, or you're already a software engineer and you want to get promoted. What should you do?
Lots of people have written about this topic. I'm not an authority here. I'm not even responsible for hiring decisions at my current job! But, I can give you some insights from what I've seen working with lots of engineers and interviewing lots of engineers and seeing who got hired and who didn't. Here goes!
What do I expect of new software engineers?
I don't spend a lot of time interviewing new grads or junior engineers coming from bootcamps or self-education. That said, I do work with a lot of them. Here's what I skills I expect them to have:
ability to turn a problem into code, but probably only after asking a lot of questions to refine the technical constraints
ability to ask for help when they need it
ability to express their opinions but also know when to listen and accept they don't know everything
a desire to get better at the job and to work well with others
eventually an ability to get tickets done without a lot of help
I'm sure there's lots of stuff I've left out, especially generic stuff about working at a company, but this is what came to mind. I think if these skills are missing (or an ability to demonstrate these skills during an interview) then that's probably why someone has a hard time getting hired to a junior position.
To that point, why didn't you get hired for a job? Sometimes it's because the hiring manager actually is shitty and is hiring for friends to go drinking with. However, I don't think that's usually the case since people who do that tend to hire worse employees on average and their companies don't succeed. More typically it's because you didn't demonstrate something the hiring manager expected to see. Usually this is going to be a technical or people skill. Did you fail to solve the programming challenge? Did you talk about how you hate working with stupid people? Do you give off a low-confidence, high-conflict, or weird vibe that is going to make the hiring manager nervous about if you'll mesh well with the team? Did someone else you didn't meet just happen to perform better on the interview and there's not enough budget to hire you also? If yes, I'm guessing that why you didn't get the job.
This is really hard when starting out. It's hard to get your first job out of school because nobody trusts you can work. If possible, do an internship while in school as a software engineer. That will give you experience to talk about in interviews to demonstrate you know how to be a software engineer and not just a programmer. If that's not an option (maybe you're self taught), consider hiring a career coach who can give you more targeted advice, or if that's out of budget bug your friends or random people on Linkedin.
Also, don't give up. It's a numbers game. You might have to accept a somewhat shitty job as your first software engineering job that doesn't pay as much as you want and isn't working on something you care about. At least it will get you in the door and give you a chance to show you can do the job. And you'll have war stories to tell, which are great because they show interviewers that you have taste (you know what sucks).
What if after all that you still can't get hired, even after having a software engineering job? I don't know. My best guess is that sometimes life is hard and unfair and you might be a great programmer but not able to get hired at a software company for reasons you and I don't understand. I've met plenty of brilliant programmers who seemed like terrible employees for various reasons and argued that we pass. Most of the time it's something that has nothing to do with programming and everything to do with their ability to be an effective employee of the specific company I was working at. That doesn't make you or them less of a person, it just means you need to find some other way to make money.
What do I expect of experienced software engineers?
I do regularly interview experienced engineers. Depends on the level, but generally I expect to see the following during interviews:
ability to turn a word problem into code (e.g. here's a toy product problem, can you write code that solves a highly constrained use case in a 60 minute live coding interview)
ability to design a distributed system (this is perhaps specific to my line of work, but most engineers with a few years of experience working at startups will know how to put together some kind of box and arrow diagram describing a scalable system and then talk about the technical choices and tradeoffs they made)
ability to ship a project (scope of the project should match your level)
Speaking of level, here's roughly how I think of engineer levels:
junior: can ship tickets
mid-level: can ship epics (a collection of tickets that delivers some functionality, may require some coordination with others)
senior: can ship a small project (multiple epics with multiple people, usually no more than 4-5); should be able to do this without a lot of oversight.
staff: can ship a large (approximately year length) project for a team (probably made up of multiple sub-projects that consume a team's worth of people); should be able to do this with little oversight.
senior staff: can ship a multi-year project for a group (multiple teams); should be able to do this with minimal oversight.
principal: can ship a multi-year project for a business unit or function; should be able to do this with nearly zero oversight.
fellow: can ship a multi-year project for an entire organization; this person could be the CTO of a large org if they wanted.
Notice how this is all results oriented. I don't really care how good a programmer someone is (past some base level of competence) so long as they can ship a project. If a project requires them to be a great programmer, then they better be a great programmer or be able to get one to work with them. The common mistake of junior, mid-level, and senior engineers is seeing the craft as an end unto itself. That's a good attitude to have to become a master of the craft of programming, but it's not a good way to get promoted to the staff+ level. Speaking of which.
What do I think you need to do to get promoted?
Growing up the ranks from junior to mid-level to senior is straight forward: be really good at solving programming problems and keep getting better at solving harder ones. As the problems get harder you'll need to pick up some project management skills to deal with the increased complexity and needing to work with others to get the job done.
Some companies let you stay at the senior level, some expect you to grow to staff. I have no real strong opinion here, it's just how it is. If you want to stay senior, don't work somewhere that will expect you to grow to staff. Ask about it during the interview. If it's a small company and they don't know the answer, they probably need you to be a staff engineer anyway simply because small companies need people to be more autonomous than big companies do, but if you can't do it don't worry small companies are so focused on the struggle to survive that no one will give you too hard a time so long as you keep shipping useful code.
To get promoted to the staff level, you need to produce a master work. This is a project, generally greater than 1-year in length and involving at least 4 other engineers, that you ship from end to end. You conceive the idea, get buy in, lead the execution, ensure smooth delivery, and follow through on measuring and demonstrating the expected impact actually happened. I don't think I've heard anyone put it this way explicitly, but if you look at what's expected of staff engineers, it's pretty clear this is what you need to do to tick all the boxes. You might find some other way to demonstrate you can do the job, but this is the most straightforward method.
Want to get promoted again to senior staff, principal, or fellow? Ship another master work but now scoped to approximately the next level up. Once you've done this, if you can't get the promotion internally take your experience on a road show of interviews and see if someone else will give you the job. If you've demonstrated ability to operate at the level, they probably will.
As always, there's lots of other little things you need to do to get promoted: don't be a jerk, make your boss look good, etc.. All the general advice matters, but it doesn't matter unless you can do the core skill of shipping code at the scope expected for the level.
Bonus: Do I think you should be a manager?
Only if you really want to. You need to understand that management is a different from from software engineering, though to be an effective engineering manager you need to first be a software engineer.
A line manager is roughly equivalent in level to a staff engineer as they have approximately the same scope and overlap in in their responsibilities. If you're excited about growing people and helping them succeed, you might want to be a manager. If you're excited about building cool systems, you probably want to be a staff+ engineer.
Management is not a promotion, it's a switch to another job. You might be promoted at the same time you become a manager if you're going from senior engineer to line manager, but the promotion isn't to management, it's to team scope.
As with my other posts on my job, this is just how I happen to see the world. Feel free to disagree with it. It probably doesn't match how everyone thinks of it, and that's because I'm very biased by how software engineering works in Bay Area startups. If you work for a government contractor or a telephone company or something then everything I've said may not apply. And, actually, if you work at one of those places, I'd be interested to hear how it's different in the comments!
I'm continuing my series of posts this week to earn more GHT for my donation lottery with another post about my job. This time, I'm coming from the angle of telling you what I tell other software engineers about getting hired and getting promoted.
So, you want to get hired as a software engineer, or you're already a software engineer and you want to get promoted. What should you do?
Lots of people have written about this topic. I'm not an authority here. I'm not even responsible for hiring decisions at my current job! But, I can give you some insights from what I've seen working with lots of engineers and interviewing lots of engineers and seeing who got hired and who didn't. Here goes!
What do I expect of new software engineers?
I don't spend a lot of time interviewing new grads or junior engineers coming from bootcamps or self-education. That said, I do work with a lot of them. Here's what I skills I expect them to have:
I'm sure there's lots of stuff I've left out, especially generic stuff about working at a company, but this is what came to mind. I think if these skills are missing (or an ability to demonstrate these skills during an interview) then that's probably why someone has a hard time getting hired to a junior position.
To that point, why didn't you get hired for a job? Sometimes it's because the hiring manager actually is shitty and is hiring for friends to go drinking with. However, I don't think that's usually the case since people who do that tend to hire worse employees on average and their companies don't succeed. More typically it's because you didn't demonstrate something the hiring manager expected to see. Usually this is going to be a technical or people skill. Did you fail to solve the programming challenge? Did you talk about how you hate working with stupid people? Do you give off a low-confidence, high-conflict, or weird vibe that is going to make the hiring manager nervous about if you'll mesh well with the team? Did someone else you didn't meet just happen to perform better on the interview and there's not enough budget to hire you also? If yes, I'm guessing that why you didn't get the job.
This is really hard when starting out. It's hard to get your first job out of school because nobody trusts you can work. If possible, do an internship while in school as a software engineer. That will give you experience to talk about in interviews to demonstrate you know how to be a software engineer and not just a programmer. If that's not an option (maybe you're self taught), consider hiring a career coach who can give you more targeted advice, or if that's out of budget bug your friends or random people on Linkedin.
Also, don't give up. It's a numbers game. You might have to accept a somewhat shitty job as your first software engineering job that doesn't pay as much as you want and isn't working on something you care about. At least it will get you in the door and give you a chance to show you can do the job. And you'll have war stories to tell, which are great because they show interviewers that you have taste (you know what sucks).
What if after all that you still can't get hired, even after having a software engineering job? I don't know. My best guess is that sometimes life is hard and unfair and you might be a great programmer but not able to get hired at a software company for reasons you and I don't understand. I've met plenty of brilliant programmers who seemed like terrible employees for various reasons and argued that we pass. Most of the time it's something that has nothing to do with programming and everything to do with their ability to be an effective employee of the specific company I was working at. That doesn't make you or them less of a person, it just means you need to find some other way to make money.
What do I expect of experienced software engineers?
I do regularly interview experienced engineers. Depends on the level, but generally I expect to see the following during interviews:
Speaking of level, here's roughly how I think of engineer levels:
Notice how this is all results oriented. I don't really care how good a programmer someone is (past some base level of competence) so long as they can ship a project. If a project requires them to be a great programmer, then they better be a great programmer or be able to get one to work with them. The common mistake of junior, mid-level, and senior engineers is seeing the craft as an end unto itself. That's a good attitude to have to become a master of the craft of programming, but it's not a good way to get promoted to the staff+ level. Speaking of which.
What do I think you need to do to get promoted?
Growing up the ranks from junior to mid-level to senior is straight forward: be really good at solving programming problems and keep getting better at solving harder ones. As the problems get harder you'll need to pick up some project management skills to deal with the increased complexity and needing to work with others to get the job done.
Some companies let you stay at the senior level, some expect you to grow to staff. I have no real strong opinion here, it's just how it is. If you want to stay senior, don't work somewhere that will expect you to grow to staff. Ask about it during the interview. If it's a small company and they don't know the answer, they probably need you to be a staff engineer anyway simply because small companies need people to be more autonomous than big companies do, but if you can't do it don't worry small companies are so focused on the struggle to survive that no one will give you too hard a time so long as you keep shipping useful code.
To get promoted to the staff level, you need to produce a master work. This is a project, generally greater than 1-year in length and involving at least 4 other engineers, that you ship from end to end. You conceive the idea, get buy in, lead the execution, ensure smooth delivery, and follow through on measuring and demonstrating the expected impact actually happened. I don't think I've heard anyone put it this way explicitly, but if you look at what's expected of staff engineers, it's pretty clear this is what you need to do to tick all the boxes. You might find some other way to demonstrate you can do the job, but this is the most straightforward method.
Want to get promoted again to senior staff, principal, or fellow? Ship another master work but now scoped to approximately the next level up. Once you've done this, if you can't get the promotion internally take your experience on a road show of interviews and see if someone else will give you the job. If you've demonstrated ability to operate at the level, they probably will.
As always, there's lots of other little things you need to do to get promoted: don't be a jerk, make your boss look good, etc.. All the general advice matters, but it doesn't matter unless you can do the core skill of shipping code at the scope expected for the level.
Bonus: Do I think you should be a manager?
Only if you really want to. You need to understand that management is a different from from software engineering, though to be an effective engineering manager you need to first be a software engineer.
A line manager is roughly equivalent in level to a staff engineer as they have approximately the same scope and overlap in in their responsibilities. If you're excited about growing people and helping them succeed, you might want to be a manager. If you're excited about building cool systems, you probably want to be a staff+ engineer.
Management is not a promotion, it's a switch to another job. You might be promoted at the same time you become a manager if you're going from senior engineer to line manager, but the promotion isn't to management, it's to team scope.
As with my other posts on my job, this is just how I happen to see the world. Feel free to disagree with it. It probably doesn't match how everyone thinks of it, and that's because I'm very biased by how software engineering works in Bay Area startups. If you work for a government contractor or a telephone company or something then everything I've said may not apply. And, actually, if you work at one of those places, I'd be interested to hear how it's different in the comments!