What should you look for in a job?

Dear new developer,

As a new developer, you have a lot of flexibility when looking for a job. This is great in some ways, but makes it difficult to hone in on particular a job opportunity.

What should you do when you are looking for a position? After all, if you are open to any position, differentiate yourself is difficult.

For example, this is not a good look:

Interviewer: so, what do you like about this job opportunity?

You: well, it pays me money to program.

You may know where you want to go (in terms of business domain, technology area, or career path).

But, you may not. I didn’t.

If you don’t have an idea, here are three items I use to evaluate a job opportunity. You can evaluate jobs before you ever submit a resume, but update your viewpoint while you are interviewing too. You’ll never be in a better position to leave a bad job than before you start it.

Domain experience and resonance

Sure, you can be happy slinging code anywhere, but as a developer, you’ll be better served if you understand the business. That is easier to do if you care about the problems the company is solving. You’ll learn the jargon, interact with other team members, and have more empathy for your users.

There are, of course, levels of interest. Aim for a 6 or above on a scale of 10 (where 0 is “I actively dislike this problem” and 10 is “solving this is my mission in life”). But, the deeper you get into a domain, the more interesting it typically gets. I worked in a real estate brokerage for years and the more time I spent there, the more I learned about both the intricacies of real estate and the life changing aspect of home purchases.

This is also a good filter if you have previous life experience. If you worked as an insurance broker, look for companies working in the domain of insurance, risk management or sales. If you worked in fast food, look for companies in restaurants, customer service, or process engineering. Adjacency and company research help you stand out as a candidate, too.

You don’t need this job to be your life’s work, but if you couldn’t care less about the problem the software is trying to solve, you’ll have to focus on other things for inspiration, such as the team or technology stack. That can work, but the problem space is the overarching container for opportunity at a business and is therefore a better filter.

Trust

Professional relationships are built on trust.

The entire point of hiring someone is that you trust them to do the work. This is true in all careers, but especially for software developers. It is relatively easy for a manager to see if a host at a restaurant is working (are they helping a customer? are they cleaning their area? are they on the phone handling a reservation?).

In contrast, a software developer is sitting in front of a computer whether they are hard at work or daydreaming. Yes, a manager can look at output (and should), but that can vary wildly based on the experience of the developer and the difficulty of the problem. And doing so doesn’t even touch on the team aspect of most software.

Trust is critical. You must trust your manager and the company just as much as they must trust you. You should look for a high trust environment.

This is a difficult to ascertain from a job posting, however. No one posts “This is a low trust environment. Watch your back!” in their job description.

So, you mush look for other signals. A great option is to chat with one or more current or former employees. LinkedIn is your friend here.

If you have a list of target companies, see if you know anyone via first or second degree who has worked there. Ask them for 10 minutes of their time. The data may be out of date or incomplete, but it is far better than nothing. Ask questions like “so, how much did you control your day?” and “how did leadership follow through on promises?”.

Another useful signal is how they treat you during the job interview process:

• Are they respectful?
• Do they do what they say they are going to do, in terms of actions and timelines?
• If they make a mistake, do they acknowledge it?

These are all small signals, but they add up and they matter.

During an interview, ask questions about day to day decision making:

• Are people granted autonomy or are they going through tickets as fast as they can?
• Are there times where employees can drive decisions (hackathons, product feedback meetings)?
• Who sets schedules and determines levels of effort?

Realize is that high trust and low trust environments can exist in the same company. This attribute is team dependent, both because of the outsize effect of your manager and also because of the team’s scope of work. A customer service team will almost always have less autonomy than a engineering team, simply because of the nature of the work.

Determining the level of trust at a possible position is difficult, but you should do the best you can. If you can’t trust your team, you are going to be pretty miserable at the job, even if the benefits are great, the pay is good and the technology challenges are interesting.

Learning

The final criteria for evaluating at a company is the learning opportunity. You can slice this two ways.

First, are the main tasks of this job ones you haven’t done before, from a technical, career or domain perspective? Given you are a new developer, chances are high that this is true. As you grow in your career, avoid having the same year of experience over and over.

A new job is the perfect chance to stretch yourself and work on something adjacent to your previous experience. There are many ways to do this.

If you worked with react before on a small team, you could work with:

• react again. I bet the new company does things in a different way.
• angular. Learning a second JS framework will improve your understanding of both.
• vanilla javascript. Going back to the basics will deepen your appreciation for frameworks
• a backend language/framework like Ruby on Rails.
• a big team, where you’ll learn more about process and change management.

I don’t have the right answer for you, but evaluate a company on what you think you can learn there.

Second, what support do they provide. Consider:

• Are engineers blogging or tweeting?
• Are they sending their developers to conferences?
• Is there a learning budget?
• What support for mentorship, both informal and formal, is provided?
• Are people churning at the company or there for decades?
• Do they have an intern program?
• Do people shift roles at the company?

At the end of the day, your goal is to be in an environment where you have plenty of time and support to learn.

These are three criteria to help filter job opportunities. A company doing work in a domain you are interested in, with a high trust environment where you can learn, is, in my opinion, an optimal work environment.

Sincerely,

Dan