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.

Can they communicate organizational goals clearly?

  • ✅ 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
  • 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?

  • ❌ 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)
  • “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”
  • 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

  • ❌ “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
  • 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).
  • 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

  • ❌ 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
  • 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

  • ✅ 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”
  • 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”.
  • 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.
  • 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.)

Is actionable & constructive feedback normalized?

  • ❌ 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
  • 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

  • ✅ 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>”
  • 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?

  • ❌ 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)

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

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?”

Caveats & size/resource constraints

What about hardware companies?

How much does this all matter?

Author’s background

Support the author



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



autotelic polymath with an overwhelming compulsion to reverse engineer things I’ve never tried before