Here is a bunch of advice for making sure your next company is a good match for you.
BIG NOTE FOR FIRST TIME DEVS: If you are trying to get your first dev job, don't be picky. You are unproven and a big risk for anyone to take on. Once you get your first dev job, work there for at least 1 year (no more than 2), then come back to this so you can grow faster, level up, get paid more, etc. Once you've worked as a dev for at least a year somewhere, you have officially proven you can do the work without being fired, so you're a safe hire, and there is high demand for devs. If you're going to pay attention to any of these sections, it should be the "Learning" section.
I tend to have several pre-meetings before agreeing to officially come in for an interview. I want to know if what I'd be going to is better than what I'm leaving. So I'll have a few lunch meetings, or phone calls to discuss and ask questions. Get to know them first. And just because they might not be right for me, that doesn't mean I don't know someone that I think might be right for them. More about that at the end.
The Questions
Each of these questions is good to know, but how important it is to you may vary. It's good to know what criteria is important to you so you can compare potential positions that you may be considering at the same time. What matters more to you, PTO days, or flexible schedules? Control over your laptop, or control over your tech stack? Only you know what you care about. So figure it out. On to the questions.
Tech
- What is your tech stack?
- This is a deal breaker for me. I have the technologies I love, the technologies I like, the ones I accept, and the ones I hate and won't ever touch again. Be specific here, ask about meta-languages, libraries, frameworks, and tools. If you're going to be working in a codebase every day, it better be one you like.
- GitHub.com, internal GitHub Enterprise, or something else (Bit Bucket, etc)?
- What is your CI system like? GHA, Jenkins, etc. Docker, Kube, etc.
- Would this be greenfield work?
- Greenfield means starting a project from scratch. Brownfield means working on an existing project that has been around for a few years.
- How many projects is the team I'd be working with in charge of?
- This can vary a lot and is good to know. Is it one main project and a secondary one that gets updated like once a year? Or is it a constant churn of new projects every few weeks/months. Or are they in charge of 38 legacy projects that need constant updates (yikes).
Laptop
- Am I issued a laptop with this position, do I have a say in which one I get?
- The hardware itself. Almost every company will issue you one, and if you ask, most will give a list of 2-4 to pick from (usually 2 Apple, and 2 Windows options of differing screen sizes/specs)
- How much control do I have over the system?
- Is there a ton of security software that slows it down to a brick? Could you wipe it and install your own desired OS from scratch? Are there downsides to using a machine without a corporate image (usually auth/vpn hassles).
- Software/tooling?
- Can I use my favorite editor/IDE/tools, and will the company actually pay for the license. Am I forced to use the same thing everyone else uses?
- Is there a "Software Procurement" process?
- Some places require all software to be approved by a security team before it is allowed to be installed on company machines. Some places will insist that you use software that the company has a company license for. Some will say "just use your company credit card if it's something you use for work". And others will say "if you want to pay for it yourself, that's on you".
- What laptop/OS/IDE does everyone on the team use?
- Even if they are open to you doing something different from the rest of the team, if you are the only person with a different OS or Editor, it may just not be worth it. If no one has ever set up their codebase for that environment, you would be stuck figuring it out on your own and trying to get their stuff to work in a way that isn't documented, and not designed for. If you're lucky, everything you need to get up and running is documented in a step-by-step on-boarding process. But that is rare, and even if you are lucky, if those steps were designed for a different environment, you will be in troubleshooting hell for days.
Process
- What is the flow of a product from inception to launch?
- This gives you a big picture understanding of the processes a company does when starting or finishing a project
- Do you work in sprints, what does a sprint look like, what ceremonies do you perform?
- Many places say they "do Agile", but what that means in practice varies wildly. Do you demo to users and get direct feedback? Is the dev team present during demos? How often do you do demos and retro. What does standup look like? How is backlog grooming and prioritization handled? Can you give an example of something that came up in retro that caused the team to change in some way (such as a process change)?
- What forms of quality control do you have in place?
- Strict linting, High test coverage, PR checklists, Code reviews, QA sessions. Teams/projects with low quality control are teams that don't care about what they're doing, and I only want to work with people that actually give a shit.
- What does the development process look like?
- I care a lot about the process of how a team works together, how tickets are created, assigned, reviewed, tested/QA'd, deployed.
- How is UX handled? Do we have a dedicated UX team member, or is there a pool of UX people that are made available when a team needs them, or is UX just handled by the devs?
- How is tech debt managed?
- There are two types, intentional and unavoidable. Tech debt that isn't dealt with regularly as part of the weekly process leads to a project you don't want to be working on a year from now. And if that was the case a year ago, then it's a project you don't want to start working on now.
Culture
A lot of the "Process" section informs you of the culture too.
- What is the culture like for work hours, working from home, etc.
- I prefer to work from the office everyday, but like the option to work from home during bad weather. You may be different. Know what is important to you and see if it matches.
- What is the favorite thing you've made?
- This is just a fun one to learn about the person you'd be working with. What do they value, what was it that makes that project their favorite.
- Is the company involved in the local tech community, or if relocating, what is the meetup scene like there?
- I run several meetups and am heavily involved in the local tech community. So this is important to me.
- What's the team like? Who on the team has been on the project the longest? Who has been at the company the longest? Can I talk to those people outside of work, without their manager around?
- This is a pretty reasonable request, and most people are happy to oblige a potential team member to let them know what it's really like to work there. All good managers are totally cool with this question. If they are hesitant either they don't want you to know how bad it is there, or they don't know how to politely tell you that they already decided to go with someone else. Just be prepared to pay for your own food. Honestly I'd pay for the whole meal, the info you get during this meeting will be very valuable and could save you from wasting years of your life at a bad company.
- Is travel required?
- Some places require you to go to the Headquarters, or go to specific out-of-town company events.
- Are there any office perks?
- Multiple monitors, personal desk, fancy chair, docking station, free food/snacks, free parking, weekly "happy hours", etc. Specifically, what are the snacks, do they have that one that I like... can they get that one... No reason.
- How often are there team lunches/outings?
- Free food is nice, but so is the recognition for completion of major features.
- What is training like for managers?
- "People don't leave jobs, they leave managers" is a famous saying. Most likely you will be asking this question to a manager, who should be able to speak to this.
- What happens with underperforming managers?
- It isn't uncommon for good companies to take managers that used to be devs, and send them back to being a dev if management wasn't a good fit for them.
- What is the exit survey like?
- If they don't know, then that means they don't care why people leave, which means they aren't interested in changing things while people are there. I've been at places that don't even have exit surveys.
- If you are a woman, or in a minority group, you may want to ask if you'd be the only member of that group on your team, or even in the company.
- Tech is 85% male and mostly white (in the U.S.). I've had several friends express how happy they were to find "they weren't alone" when they started a job. One of my friends says if there are other women working somewhere she is interviewing, she won't accept the job until she gets to talk to some of the women that work there outside of their office to find out about the culture from a female perspective.
Learning
- Are conferences or training paid for?
- Some places only pay for 1 conference a year, or none. Some pay for online training accounts. Some pay for a portion of your continued education if enrolled in college.
- How do you code into the system your time spent at a conference? Some places have you use your PTO days (take time off) to go to a conference. Some places have "Education" built into the time sheets for this. I actually gave a conference talk, and the company said "As long as you introduce yourself as an employee here, we'll pay for your flight/hotel, and you just clock it as a day worked".
- How often do code pairings happen? How available are other team members to help out/walk through something they know about? What tools do you use for paired programming?
- Some places never do this and are against it. Others do this "as needed", meaning you reach out to someone else and work with them when a problem is hard enough to justify it. Other places actually require a certain amount of paired programming per sprint.
- Some places actually have special two-person desks with two mice/keyboards hooked into the same machine and monitors that slide from one side of the desk to the other. These are cool, but expensive and hard to justify unless paired programming is a super common occurrence.
- Some places use Slack to see the other person's screen and voice chat while they work through the issues.
- Some use specific code editor software that allows both people to type in the same file at once (similar to Google Docs).
- Are there any kind of knowledge shares like lunch and learns within the team/division/company?
- What more broad company opportunities there are for learning?
- Some companies have "Guilds". These are groups made up of people with the same role across many teams, so maybe a Frontend Guild. They may have meetings to show off tools or share lessons learned on a project, or just talk about things happening in the industry at large.
- Are there "Innovation Days" or something similar?
- Some companies set aside dedicated time for engineers to work on trying new things or whatever you want really. The goal being to learn something new. Some have this day once a week, others once a quarter, or not at all.
- If these are a big part of the culture, then it is important to know expectations around them. Is it okay to skip these and just get your work done? Is it looked down upon if you don't skip these?
- Teams that actually commit to these days can be a good sign for learning.
Benefits
- What is PTO like?
- No PTO (contractors).
- "Use-it-or-lose-it" where you are given "N" days a year, with limited carry over to the next year, and no payout of unused days (I consider this the absolute worst). If you don't use the days given, they just disappear. Bad system. Companies that do this think it's still 1950.
- PTO that carries over with a cap and payout. Usually the cap is like 4-6 weeks, which is reasonable, and if you leave the company the days are paid out.
- Unlimited PTO. This one is dicey some places with unlimited will still keep track and make sure you're actually taking time off, even requiring that you schedule time to be taken each year. Other places will just load you with work and let you decide when to take off (which will result in almost never).
- Salary, 401k, equity, stocks, bonus, etc. Money stuff.
- You can check salary.com and glassdoor, to see roughly what pay should be for your position in your region. You can also ask around in the local tech scene as to what people think the pay scale/range is for junior, dev, and senior positions for your role. Typically you don't talk money until after the interview and an offer is written up. You can counter this, or see if they are willing to give you something else if they can't budge on salary, like extra PTO days or something. If they go out of their way to try to do something there, don't be rude, not every place can pay as much as the bigger companies. And often salary isn't the most important criteria on this list anyways. If you care about 401k, equity, or stocks, then you likely already know enough about them to make a decision. Be careful with equity at a start up, almost all startups and new businesses fail in the first 4 years, most of that happening in the first year. Get paid. Max out your 401K.
- What opportunities for raises are there each year?
- Some places tie raises to bullshit metrics and manipulate those metrics to justify not giving raises. Some places give a ~2% raise every year which is slightly less than inflation, so they're actually paying you less every year while giving you more money that has less value. Other places actually have real opportunities for decent raises each year. And some places give tiny raises to keep up with inflation and have company profit sharing bonuses if the company does well to "make up for it". Money's money.
- What is the max amount you can pay for this role?
- This is a ballsy question, but it basically tells you what your upper limit is that they can give you without promoting you to a new job title if you were to work there for a few years. All HR departments have a cap on how much they can spend yearly on a job title. If it is a public/government position, usually this information is also public, so asking is okay. However for private companies, you're basically asking "well why don't you just pay me the max" during salary negotiations, and they aren't gonna like that, and will probably give you a non-answer like "our rates are very competitive".
Conclusion
It depends on the situation as to whether you have made a connection early, and can have these conversations before the interview, or if you come in for the interview and then have these questions in a follow up. However, if you are a skilled dev, most places are happy to take the time to answer these questions. For my current position I went out to lunch 3 times with my future boss (who had been at the company for 8 years), did a 45 minute phone call with his boss, then flew to their head quarters for 4 hour back-to-back interviews in person. All of the questions on this page were asked before the interview except for some of the money/benefit ones.
As a member of the local tech community, I have many connections in my network. So when looking into a position, if it isn't right for me, I often mention it to others who may be interested. For example, if a company is using a tech stack I don't like, I'm not going to work there, but I may have a friend that likes that stack and I could recommend them. Everybody wins. Sometimes I even get a finder's fee or recommendation bonus. But even if not, it's good to get the right people to the right places in my town and help the community stay strong and happy.
My biggest recommendation to you is to make a list of all the stuff you ever liked about your current job, and all the stuff you don't. I call this document "Reasons to leave". It's effectively a pros/cons list of your current company/job. It lets you know what things about working there bother you. What are the things that attracted you to come there. Are the good things you like about it still there? These can be anything from the snacks, to the parking, to getting to work with a friend of yours. It's important to know if those positives changed over time, maybe they got rid of the best snacks, relocated you to a new building without parking, and your friend left the company. Those are the things you liked about the company, and stuff you can look for in the next one. What things matter a lot to you, is honestly kinda random. A lot of companies just think that they can throw more money at you to keep you happy, when a problem may be systemic or cultural, and no efforts are done to address or improve them.
So write down everything that annoys you about your current job, and all the things about it you ever liked. Then figure out how important those things are to you when shopping around for the new job. It will help you know what questions to ask, and how much they matter to you.
Cat photo from Pexel.
Top comments (0)