How to vet software work culture during your interview

Software is not merely code. Software is code that expresses a set of human intents, goals, and expectations that will inevitably shift with time. When these intents, goals, and expectations only exist inside the heads of their original writers, you’ll have a huge disconnect, and that human disconnect will result in the failure of your software to achieve its goal.

Here is a distillation of common patterns I’ve observed over the last decade of working (and interviewing) as a software engineer at various software startups, including questions you can ask in interviews to get a better sense of the work culture, and some of the most common red and green flags to look out for.

Can they communicate organizational goals clearly?

“What’s your projected trajectory / roadmap for the next quarter?”

• ✅ in general, if they can provide you with clear information that they have clearly put thought into
• ❌ has grandiose goals, but unable to provide clear quarterly/monthly/weekly goals
• ❌ rigid low-level planning too far out to adapt to new information
• ❌ extremely premature optimization (e.g. making elaborate implementation plans before actually having data or problem on which to execute plans)
• ❌ “we don’t need roadmaps”
• ❌ “this doesn’t apply to us because we need to stay flexible for <insert reason>”
• ✅ agile sprints or some similarly inclusive, transparent planning process
• ✅ people generally aware what their coworkers are working on and why
• ✅ clear, actionable, quantifiable goals

Explanations

• If a company can’t even communicate its goals well to you in an interview, then how are they going to communicate them on the job, when you’re expected to be fulfilling those goals?
• Some organizations may claim this doesn’t apply to them because their goals are inherently open-ended. However, they still have implicit goals; they are just different than typical business goals.
• Examples of concrete goals in open-ended organizations include “submit a paper to upcoming conference by <deadline>”, “demonstrate novel results in <field>, starting with <approaches>”, “make progress toward <open problem>”, “collect dataset of ___”.
• Even if the high-level company goal is as abstract as “explore <field>”, they should be able to clearly state whatever it is they are currently working on, what the hypothesis/goal of the current project/experiment is, and how they envision their current work might be used in the future. If they can’t do that, you’re not necessarily looking at an employer so much as an investor with a vague idea who wants other people to make the idea good for them.

Are there clear hiring goals?

“What are your expectations for this role?”
“What are examples of some projects I might be working on if I’m hired?”
<to a peer> “Do you feel like the company’s expectations of you are clear?”

• ❌ furiously hiring, but no idea what roles the new hires will land in
• ❌ “this is a generalist position, so we can’t say anything specific”
• ✅ people are clear on how their work relates to the business goals
• ✅ explicit hiring caps / paced growth (dig deeper, since companies are amazing at misrepresenting this)

Explanations

Even if hiring for an extremely generalist position they don’t want to define, a company does have implicit goals and expectations associated with the hire; they may simply lack the communication skills or willingness to tell you in words. Examples of common implicit expectations for under-defined roles:

• “We want someone who is really good at adapting to changing demands”
• “We want a jack-of-all-trades to do a very wide range of tasks, potentially ranging from embedded device debugging to distributed systems to web interfaces, as the project progresses”
• “We are so early stage that we can’t say with certainty what this role will look like next year. However, this is the scope we’re thinking for the next three months.”
• ❌ “We want someone we’d enjoy getting a beer with”
• ❌ “We want a unicorn who can do UX, UI, full-stack, infra, devops, platform dev, data warehousing, data science, and PMing for very little money”
• ❌ “We want someone who is willing to bend over backwards and work on weekends for our approval” (usually more benevolently & agreeably phrased as “we want someone who is really passionate about prioritizing the mission and willing to put in the time to make it happen”, though to be fair, this can also occasionally be said by companies who genuinely don’t want you to work on weekends)
• ❌ “We want geniuses who can do it all by themselves” (though it’s understandable to try to save your seed-stage funding to hire such a person, this particular sentiment points to a lack of regard for teamwork and collaboration)
• “We want a senior employee who can architect complex systems, do project management, and make stakeholder decisions given very little direction”
• “We want to hire someone whom we can easily re-allocate onto different projects/teams as our business priorities shift”

Many of these expectations are quite reasonable job requirements. However, it’s much better to discover them in advance, rather than after you’ve signed up for the role. Push for more clarity and ask employees off-record (rather than the hiring manager) if things are unclear to you.

• Cyclic growing pains are a natural part of VC-backed software startups, and will inevitably peak several times over the startup’s lifetime. However, it’s totally reasonable if you don’t personally want to commit to a place that is currently undergoing too many growing pains for you.

Peer performance reviews and regular checkins

“How often do you have peer performance reviews?”
“How often do you have regular 1:1 checkins with a manager?”
“What does your feedback process look like?”

• ❌ “we don’t need that, we just give feedback whenever we think it’s needed”
• ❌ “we don’t need that, we trust each other to say things when needed”
• ❌ 1:1s are rare or not regularly scheduled
• ✅ regularly scheduled anonymized peer feedback cycle, usually quarterly
• ✅ regular team retrospectives every 1–2 weeks
• ✅ normalization of regular 1:1s, usually weekly
• ✅ regular retrospectives after sprints or projects
• ✅ feedback is actively sought out

Explanations

• It’s great when people genuinely do feel welcome giving feedback whenever it’s needed. However, in places where feedback isn’t regularly scheduled and normalized, it’s very disadvantageous to junior employees, minorities, people who are more financially dependent on the job, and others in positions of less power. Marginalized groups often experience disproportionate consequences & backlash for stepping out of line or being perceived as “complainers”, while non-marginalized groups are praised for the exact same behavior.
• In a culture that lacks regular check-ins, feedback is more likely to be viewed as a major, negative, or rare occurrence. People are more likely to sit on feedback until it becomes “big enough to be important”, rather than thinking of all feedback as important, which it is!
• Regular check-ins are a pressure valve that normalize minor, informal feedback. When you have a scheduled check-in time every week, even if you have no real complaints, it’s much more natural for people to casually bring up small concerns and address them early and easily, instead of stewing on them until they grow into major roadblocks. This is beneficial not only for employee satisfaction, but for literally making your software more robust.
• In the absence of peer performance reviews or other documented peer feedback, your fate at the company may be determined by whatever limited perception the CTO or lead has of you.
• The lead is a busy person. If you don’t spend a lot of time working directly with them, their perception of you will have less basis in your actual work, and more in your demeanor and appearance. This is frequently extremely disadvantageous in America if you are not a tall, outspoken, white or light-skinned cis-man (or one who is frequently perceived as such).

Suggestions

• One team retrospective model I particularly like is the 🙂,😐,🙁 checkin.
  The 🙁 normalizes the existence of difficult feelings, while the 😐 normalizes more minor/neutral feedback that people wouldn’t otherwise think was “important” enough to bring up.
• A less feelings-oriented variant is the “➕/Δ” checkin, where ➕ is for things that went well, and Δ (delta) is for things you wish could change next time.
• I personally advocate more for the 🙂,😐,🙁 model, as the feelings-oriented model makes more space for team morale and factors out of your control. For example, if you were affected by an AWS outage, or a supplier failed to deliver, or you had a personal health issue, then that’s not the fault of anyone in the organization or something you could have predicted, but it’s still a bummer that’s worth mentioning.

Management & mentorship

“How are new hires mentored?”
“How are managers chosen?”
“How was the current/last manager chosen?”
“Do managers undergo managerial/communication training?”

• ❌ unclear report hierarchy
• ❌ managers are chosen because of perceived individual technical skill rather than a desire to support other people’s growth (this requires some digging)
• ❌ excessive growing pains (deeply confusing onboarding experience, people don’t know what they’re supposed to be working on)
• ✅ managers collaboratively support their reports’ growth trajectories and personal goals
• ✅ managers undergo some kind of communication/empathy training
• ✅ employees are given clear feedback on how to align their work with team goals
• ✅ new hire buddy program

Explanations

• Managerial skills are deeply underrated. A supportive manager who cares about managing can turn the whole team into a powerhouse while also keeping them happy, while a manager who doesn’t understand management can downgrade an entire team by rendering them ineffective, not helping them obtain cross-departmental resources that help them do their job, not clearly communicating expectations, and/or making them feel unappreciated or unsupported in their work.
• It’s unfortunately common for people uninterested in management to get incidentally promoted to “manager” because of individual technical prowess which is unrelated to management.

Leveling & pay bands

“What does your leveling structure look like?”
“What pay band are you putting me in? How does this salary compare to other hires with similar backgrounds?”

• ✅ the bands/levels are named and clearly defined
• ✅ 🌟 the hiring manager not only tells you which pay band they’re putting you in and what percentile in it they think you’re at, but they tell you the dollar range for that band upfront
• ✅ 🏆 🌟 everyone in the same “band” is paid the same amount
• ❌ “we don’t have/need levels”
• ❌ “we don’t negotiate”

Explanations

• Every company has leveling, even if they won’t admit it. It’s just that some companies write it in a transparent document and allow the information to be disclosed, while some secretly decide the levels inside executives’ heads based on biased perceptions about people’s “value”. (I once tried to negotiate at a place where I was told I couldn’t because there was no leveling and everyone was equal. After quitting, I found out that a white cismale coworker at the same “level” was being paid 3x more and my white cismale boss was being paid literally 10x more.)
• If different people in similar departments are paid different amounts, that’s leveling. If they genuinely don’t use different levels, then everyone in your department is paid the same amount of compensation. This is unbelievably rare and will probably be on public record in the news and on the front of their jobs page when it’s actually true. There is nothing wrong with salary leveling, but there is a problem with lying about it.
• For an example of how Big Tech levels are structured, see Levels.FYI. Note that startups will not pay this highly.
• If most companies are aware they can get away with paying you less without a big fuss, they will do it. It’s business. This disproportionately impacts people who aren’t upper/middle-class white cis-men. (In my late-stage career, I started filtering explicitly for companies who were transparent about pay bands, and it was honestly mind-blowing how different the culture was.)

Negotiation

I was not aware of the existence of salary negotiation until several years into my career, when I polled a bunch of my MIT friends and found that all the white guys were getting paid the most even though some of them never studied computer science, had ten years less experience on their resumés than me, and just switched into software later in life.

In other words, I am years worth of financial savings behind white men with less technical experience than me just because companies knew they could get away with it. Yes, it’s very frustrating.

Unless you are dealing with a small self-funded seed stage startup where the money is literally coming directly out of the founder’s savings, you can usually negotiate. Even if your base salary offer is absolutely fixed, you can often negotiate side benefits like your starting bonus, moving bonus, personal development budget, or soft perks such as “I get a 1:1 with the C*O every quarter”.

If a company is not budging on negotiation, go get a competing job offer from one of their competitors and then see if they change their mind.

Is actionable & constructive feedback normalized?

<to a future peer> “Do you have code reviews?”
<to a future peer> “Do you feel like you receive actionable feedback about your work?”

• ❌ code reviews are rare or nonexistent
• ❌ non-actionable feedback, e.g. “your code is confusing and bad”
• ✅ highly specific, constructive, and actionable feedback, e.g. “could you document your functions with PEP8 style docstrings to make it easier for others to use them?” or “I think it would be valuable to add a fuzz test for this particular function, because…”.
• ✅ all code is peer reviewed before merging

Tips

• People who give non-actionable feedback may not know or care that they’re doing it, so YMMV depending on who you’re asking this question to.
• However, you can observe what kind of feedback you receive during interviews.
• It’s probably most helpful to ask interviewers with a similar job title what kind of feedback they receive while working.

Communication culture

“Do you have communication training or workshops?”

• ✅ if they have communication training, workshops, or discussions
• ✅ 🌟 if they have a communication or soft-skills interview
• ✅ if the interview process includes multiple meet & greets where you aren’t technically interviewed and the point is just for more team members to get a chance to meet you
• ❌ “technical ability is the most important thing, but <insert excuse>”

Explanations

• Even though I enjoy and actively seek out computer optimization problems, the vast majority of challenges at every senior-level job I have had have not been related to computers. They have been human misunderstandings, conflicting stakeholder goals that need to be resolved, disagreements on the “correct” goal, “what does the user expect the software to do here?”, fuzzy tradeoffs between time/money/quality, mismanagement, or communication with customers, or PR issues.
• If you are going for a junior-level job, this may affect you less, or at least, there may be fewer expectations around your ability to slip & slide while conflicting stakeholder interests are tossed in your general direction.
• Unless you’re working in an almost purely digital realm such as algorithmic trading, it is completely normal for the primary challenges of your software to not be computer-related. Any software which interacts with humans in production is merely a way of expressing complex, fuzzy human goals in machine code. We talk plenty about the machine side, but rarely receive formal training in the human side.
• This is especially critical if you work in SaaS, where there is an even higher ratio of human concerns to technical concerns.

Is the codebase easy to change without incurring catastrophes?

“What’s your approach to testing?”
“What do you use for CI/CD?”
“What’s your build/deploy process like?”
“Are there many pain points around legacy code?”
“Are code reviews mandatory?”
“How do you check your system health?”
“How are new features rolled out/back?”

• ❌ no/few code reviews
• ❌ no/few tests
• ❌ manual deploy that only one person knows how to run
• ❌ system health can only be checked manually
• ❌ people seem apprehensive or avoidant around deploys or feature rollback
• ✅ all code is peer reviewed before merging
• ✅ test-driven development (TDD)
• ✅ test suites are run automatically by CI/CD
• ✅ feature flags
• ✅ feature rollback is considered normal and easy
• ✅ automated build process
• ✅ automated system health alerts & dashboards
• ✅ 🏆 🌟 tooling allows people to safely ask complex BI questions on production data without knowledge of code implementation (eyy, observability)

Many heavily VC-funded companies prioritize Shiny New Features over maintenance work. The amount of time I have spent tripping over ill-maintained code, hardcoded assumptions, or screaming into the void because of this is legendary, and could have been averted if more sprint time was allocated to allow engineers to do code maintenance. Do yourself a favor and get a job where the codebase is decently maintained.

Caveat: These may be challenging to discuss if you have not worked in an industry software environment before, as there can be a lot of situational nuance.

Are they trying to make a high quality product or are they just a VC growth funnel?

🌶️ “How much time is spent on existing users versus future users?”

Unfortunately, this is a really spicy question that’s difficult to get straightforward or useful answers to. What’s going on here is that a lot of heavily VC-funded companies are driven to promote unsustainable growth at the cost of alienating the existing userbase, mistreating gig workers, or leaving the product ill-maintained.

This may be more useful to dig up from the product’s support forums, or by just using the product yourself. It’s also culturally very tightly linked with codebase maintenance issues. A work culture that prioritizes Only New Features All The Time over codebase maintenance will probably also prioritize fast, unsustainable growth over slow, sustainable growth.

Extra spicy questions if you’re feeling bold

• 🌶️ “What do you wish you’d known before you started working here?”
• 🌶️🌶️ “How many people have left the team recently?”
• 🌶️🌶️🌶️🌶 “What were the circumstances of the last layoff?”

It is unlikely that you’ll get completely transparent & representative answers about this from hiring managers or execs at most places, but if a peer who’s interviewing you seems distressed about a situation like this, that’s a big red flag for you.

Caveats & size/resource constraints

Organizations that manage to check every ✅ on this list are unbelievably rare. An organization’s capacity to check ✅s will also be limited by small size.

<5 person software company

It would be an extremely high bar to expect any company with 1–4 people to check off half of these ✅s; many of them are unnecessary overhead & premature optimization if it’s literally just your founding team with seed funding and a beta prototype. However, I would still want to see perhaps a third of the ✅s, and relatively few ❌s. Even if not all these points apply to seed-stage companies yet, they can at least serve as an aspirational template.

<15 person software company

For similar reasons, I would not judge a 10-person company for having only about half of these ✅s checked. However, I would filter for companies that seemed genuinely enthusiastic and aspirational about implementing most of them with growth.

<40 person software company

This is a software company that is starting to receive major funding and is probably in series B phase. At this point, you’d better have engineering managers. Teams will rapidly drift out of sync without regular checkins and good communication pipelines, and process becomes more important. I would filter for places that have most ✅s checked, because you are not going to get a work culture course correction at a VC-backed company larger than this.

40+ person software company

At this stage in my career, I would absolutely not work for a 40+ person software company that had very few ✅s checked. No matter how they justify it, a 40 person software company absolutely has the monetary resources and the tolerance for process to prioritize managerial training and address most of these ✅s, and is simply choosing not to prioritize them. Without most of the ✅s checked, I know that signing at a company of this size will condemn me to waste 30–80% of my engineering hours mired in blockers that could have been solved with thoughtful work culture until I inevitably ragequit.

What about hardware companies?

Unfortunately, I have not worked in hardware companies and cannot provide good estimates there, but the scaling factor does seem to be quite different. From friends’ anecdotes, a 20 person hardware company seems commensurate in scale with perhaps an 8–10 person SaaS company, given all the additional parts of the production pipeline they need to handle.

How much does this all matter?

“This all sounds like a nice bonus, but I’m just here for the software. What if I’m prioritizing technical work over ‘culture’?”

I, too, got into software purely because I find it satisfying to write software, and love the rare occasions where I get to spend most of my time focusing on software instead of nagging companies about unblockers. In fact, the point of all these work culture observations is to find a job where I just get to sit down and write some goddamn software, and I feel extremely burnt out that I have had to learn about all these subtleties by trial and error in order to unblock my job. (For a great explanation on how this happens to people, I highly recommend Glue Work.)

Unfortunately, that idealized job doesn’t exist for many people. Lack of thoughtful work culture is an enormous obstacle to most people’s ability to get shit done once your organization grows so that you have more than one coworker on your immediate team.

Process is not as important when you’re hacking prototypes in a garage with one collaborator, but it’s crucially important the moment you have multiple teams coordinating with each other, or a new hire who hasn’t been present for the history of the entire codebase, or you expect hires to get up to speed & contribute in specific ways, or you have customers.

Software is not merely code. Software is code that expresses a set of human intents, goals, and expectations that will inevitably shift with time. Sometimes, these things are well documented in the form of docstrings, unit tests, build scripts, automated checkers, comments, and frequent meetings.

When these intents, goals, and expectations only exist inside the heads of their original writers, you’ll have a huge disconnect between team members, and that human disconnect will result in the failure of your software to achieve its goal.

In short: the work is what I’m here for. The work culture unblocks my path to get it done.

Thanks to Catherine Olsson for collaboratively inventorying many of the red flags above together, and motivating me by osmosis in the eternal struggle with negotiating one’s worker value under capitalism.

Thanks Daiyi for recommending extra spicy questions.

Author’s background

I started programming in 2001, did my first software research internship at Stanford in 2007, graduated from MIT in 2012 with a bachelor’s degree in computer science & engineering, and, as of publishing this, have worked in various software capacities (full-time, contract, etc) at a total of ~15 organizations (industry, seed-stage, & research). One of those organizations was a software startup accelerator, at which I worked closely with a cohort of 12 early-stage startups.

Since undergrad, I have mostly worked in <50 person startups. I am currently balancing burnout, health, & personal life by alternating freelance work with self-directed projects.

I occasionally write to my personal code blog here.

Support the author

I’m keeping this article free to the public because I care about making information available and I don’t have the bandwidth to formally publish a book right now, but it’s also ridiculously valuable information I’ve synthesized over a decade of trial and error. It can literally save you from years of job dissatisfaction, exploitation, and degradation.

If this information helped you out at all as an employed software worker, kindly cite my article, and consider leaving me a tip at Ko-fi that’s proportional to the number of salary-hours I saved you from banging your head against systemic organizational incompetence!

If this helped you out as a software executive, and led to actual process changes within your company, I expect it will save you tens of hours per engineer per month, so I suggest tipping me a minimum of 10 L5 wage-hours.

Thanks for reading!