Evaluating Employers as a Junior Software Engineer

I got an ask about this on Tumblr recently:

Do you have any advice (for a very junior software engineer) on how to determine whether a particular company is a good place to work?

AS A MATTER OF FACT, I DO.

So, I’ve written a blog post on what can go wrong in a junior software engineering job. Your goal is to prevent that from happening.

Step 1. Are you the sort of person who cares a lot about Prestigious, Cool-Sounding Projects? If so, STOP. In my experience, the more prestigious a thing sounds, the better the odds are that the people doing it are kind of floundering and not making progress. Look for projects that are unsexy and obviously make money. It’ll be easier for you to learn from them.

Yes, it matters that what you do makes money. You need a job that has feedback cycles and clear progress metrics. Things that make money tend to have feedback cycles. Things that don’t… well, if you’re not making money, you have to convince someone to pay you somehow, and in practice that usually means politics, not numbers.

Step 2. Work with engineers who are a) better than you, and b) care about you, and most importantly c) will make time to mentor you. All of these things are necessary. In an interview, it’s easy to filter for ‘does this person seem nice?’ Unfortunately, there are many, many managers and mentors out there who are nice people, but really have no idea how to effectively help their subordinates/junior engineers.

Step 3. You need to write a few hundred thousand lines of code to become a better engineer. Your goal is to find somewhere to work with lots of code to write. You would think that if “coder” is a synonym for your job title, this would be easy, but it’s harder than you’d think.

So if prestige is a bad filter, and niceness is a bad filter, and "being a company that writes code" is a bad filter, what should you ask about in an interview in order to evaluate these things? I'm glad you asked!

• Onboarding process.
• When you get hired as a new engineer, how will they get you up to speed on their tooling and codebase?
• The answer you want is something like, “Oh yes, we have training materials for getting new hires up to speed on our codebase. [Person], here, will walk you through getting your dev environment set up on your first day. And [Person] will be assigned as your mentor if you have any questions.” 
• It might be more casual than that if you’re at a small company, but the important thing is that it is part of someone’s explicit job responsibilities to spend time answering your questions and helping you. If they don’t have that, give them a good hard side-eye. 
• An ideal situation here is “your manager or mentor sits behind you and it’s socially acceptable for you to turn around and ask them a question at any time.” 
• How you’ll interact with your manager. Will you have regular one-on-one meetings with them? (Good.) Will you have time to ask them questions? How many direct reports do they have? 
• If your manager has more than 10 direct reports, this might be a bad sign. Managing people takes time. You need to be able to ask your manager questions and escalate problems to them when you’re stuck.
• If you will mostly be working with your manager (not anyone else), you should have at least an hour of time with them per week for questions, especially near the beginning. 
• But if you have a technical mentor who is separate from your manager, this may not be needed.
• How other engineers collaborate with each other.
• For example, code reviews. Do they do them? Code reviews are a great way for senior engineers to induct juniors into better code style and practices, and a great way to help you stay in touch with other people while doing your work. 
• Work style and social-ness. Do people mostly keep to themselves all day? Do people frequently come to each other’s desks and ask questions, or use IM or email a lot? What does the typical engineer do when they need help?
• The easier it is for other people to ask questions, the easier it will be for you, too.
• What is your first project going to be? An organization that helps its engineers grow is an organization that assigns projects well.
• One of the most important things your boss can do to help you grow is assign you projects of gradually increasing difficulty, selected to be useful to your organization.
• Asking “What will my first assignment be?” will help you evaluate whether they’re making that decision with your growth in mind.
• Why are you being hired? What does the organization need to do to get from where it is now, to where it wants to be? Will there be enough work for you to do, such that you can climb that ladder of projects-of-ascending-difficulty?
• Does the organization have a lot of code to write? Are they racing to get all the work they can done, or are engineers trying to manufacture more work for themselves?
• As a junior engineer, it’s better for you to be in the first situation, because it means there’s plenty of code for you to cut your teeth on. The second situation is fraught with politics and bullshit; avoid it if you can. 
• This gets more important the more senior you get: How does the organization evaluate progress towards its goals?
•  As a junior engineer, this matters less, because your personal growth is less tied to the growth of the organization as a whole. But like I said - clear feedback cycles help straighten out all sorts of organizational bullshit. Which may affect you indirectly.

Lastly, a rather personal opinion of mine: DON’T DO MACHINE LEARNING. Every junior software engineer wants to do machine learning. As a result, there's a whole industry of bullshit grown up around it, and in general, There Be Politics. If you think your project is really unusually data-driven and great, then maybe. But make them show you the ground truth and the metrics they use to evaluate their performance, and make sure they're good at all the people stuff, too.