What I Would Want From a New Job
I've been working as a software engineer for a number of years now, at the same company I joined after graduating as an undergrad. I'm reasonably happy with my current job, but I've been thinking lately about what another role could offer that would pull me away from where I currently am.
While I expect some of these would be pretty universal desires, note that this is a snapshot of my own personal takes as of January 2025.
Basics
- The job must be based in █████████1, where I currently live. I've got enough ties here that I'm not interested in moving any time soon.
- I want to work ≤40 hours a week, with little/no time spent "on-call".
- I want to work next to most of the people I'm working with. I'm glad that COVID has made work-from-home more common for those who prefer it. But for me, I prefer working in an office for two primary reasons:
- I like the physical gap between being 'at work' and 'at home'
- I find collaborating with people in-person much more enjoyable and fulfilling
- I want to work on hard problems that require stepping away and thinking deeply. I recognize every job has some amount of tedium, but the more of this kind of "deep" work, the better.
- I want to develop my technical skills, further honing my craft as a software engineer 2. I want to gain exposure to powerful, well-designed systems (programming languages / frameworks / databases / etc.), both because these are useful tools to use and because I can learn things from their design. Some of the following points on this list are instrumental goals towards this end.
Tech
- The codebase should all be under version control, and commit messages should be consistently good
- All code should be reviewed by at least one other engineer before being rolled out
- Documentation should be reasonably prioritized
- Unit and integration tests should be thorough, and kept green at all times 3
- Code should be deployed frequently/continuously
- Engineers should be expected to interact with the users of their system
If you're looking for more thoughts along these lines, check out this article by Juia Evans, which inspired some of these points.
Development Approach
- The people making architectural/design decisions should be the ones most familiar with the system. The engineering team shouldn't be worried about the company's CTO getting sold some bag of magical SaaS beans and derailing everything.
- The company should have a bias towards doing things right over doing things quickly. Care should be taken to ensure code remains readable and maintainable. If something needs to be half-assed to meet a deadline, time and effort should be put in to do it right afterwards.
- When something in a system goes wrong, the focus should not be on blaming an individual, but instead on identifying and changing the characteristics of the system such that another failure of the same kind can't happen again.
- The company should have a commitment to its employees' growth and learning in a sustainable way. In practice this could look like employees regularly attending conferences, or employees getting 20% time to work on whatever projects interest them, or even encouraging employees to take occasional sabbaticals.
People
I want to be surrounded by people who are more experienced and more knowledgeable than me, where I can learn and grow in a safe and relatively stable environment.
- The company shouldn't be growing its engineering headcount by a significant amount. If a company is doubling in size every years, then after years I will be more tenured than half the people there (even assuming zero turnover). This is a great situation if I'm looking to move up into management, but that's not currently where my interests lie.
- The team should have relatively low turnover rate. This limits the amount of manager/team churn, but also is an indicator that the company is a good place to work.
- The team should be hiring experienced devs, as opposed to hiring folks straight out of college
My current job fails the first and third of these checks, which has added up to a situation where I'm a few years out of college and I'm one of the most experienced/senior devs on my team. This is exciting in one respect, that I now have a decent bit of influence and respect within the team. But I don't know that much either! I feel like I have a lot more learning to do before I should be taking the role of the wise and knowledgeable expert.
Not Evil
My final condition is that I want to feel like my job has a net positive impact on the world. I want to help build some technology that solves a real problem.
This filter has gotten tighter for me over the last few years, as I have come to see more and more of the current tech ecosystem as malicious rot. So many tech 'products' suck not because of incompetence or because companies have failed to find good solutions to genuinely hard problems, but because enshittifying the product will improve the company's growth metrics. I'm sure I'll continue to be mad at the state of the tech industry in other posts, but suffice to say this filters out many 'big tech' companies, as well as many VC-funded, 'disrupting' startups. If your business is based on an exploitative 'growth at all costs' model, I do not want to work for you.
Another consideration on this front is been the strategy of earning to give. This is broadly what I've been doing for the last number of years4. My current job, to my estimation, has roughly zero net impact on the world. However, my employer has a generous donation-matching program, which I have been fully utilizing. From a purely utilitarian perspective, this seems great, but I believe I would feel much more fulfilled if my job were also adding some value to the world, instead of feeling like it's only there for me to earn money from.
Red Flags
If a company/team matches any of these, I am going to be wary of working there, even if they otherwise fit my requirements.
- The team blindly adheres to a specific development methodology without weighing the pros/cons of the methodology. If there's any required process that happens despite (almost) everyone involved understanding it's a waste of time, that's a very bad sign. Processes should be sufficiently flexible to suit the needs and desires of the team.
- The company offers unlimited PTO (unless there is genuinely a company culture of taking a lot of PTO under this system). From my understanding, "Unlimited PTO" is often used as a selling point, but in practice often leads to employees taking less PTO because there's no clarity on how much PTO you're expected to take.
- The company is not currently profitable and isn't going to become profitable in the very near future. I don't want to work on a sinking ship, nor a VC-funded loss-leading startup.
Green Flags
These are not requirements, but I'd be more interested in a role if the company/team fits any of these:
- The company contributes to open-source projects.
- The company demonstrates a genuine effort to hire and retain a diverse pool of talent. Iris at DeadSimpleTech has some good writing on what companies can do to help (or more often, simply not hurt) marginalized people. I don't have any magic barometer to measure a company for this, but the diversity of their existing employees seems a reasonable first-order heuristic.
- I've recently gotten interested in different programming methodologies, specifically Extreme Programming (XP), along with Test-Driven Development (TDD) and Pair Programming. I said above that blindly following a methodology is bad, and that is true for these as well. But, I've heard some good things, especially from former employees of Pivotal Software like Nat Bennett5 and Jesse Alford, and this has made me very interested in trying out some different approaches to collaboration on software engineering projects. This is something I could try to spin up on a small scale within my existing team too, and maybe I will try that at some point.
Conclusion
I expect it would be exceedingly hard to get a job that matches all of these requirements. I'm initially limiting myself to companies with an office near me where most employees work in-person. I'm also looking for somewhere without significant growth or turnover, which will inherently not have many job openings at any given time. And while I think my tech requirements are not a terribly high bar, I do expect that many companies would fail that as well.
I suppose the takeaway from this is that I should stay at my current job, or start something entirely new. Or maybe I'm too pessimistic about my assessment of how rare these qualities are in companies, and the grass really is greener somewhere else. For the time being though, I'm not looking to start my own business, nor am I eager to try applying to other jobs hoping to find a diamond in the rough. My current job fits my filters well enough. And in any case I'm sure there are other things I want in a job that I haven't explicitly thought of as requirements, because I haven't had a job without them!
Here's a HackerNews Link for this post.
Redacted for anonymity↩
Yeah yeah, maybe it's best I avoid putting such a solid label on myself but I feel like this is fine for where I'm at right now.↩
I read this article recently, and while it is blatantly an advertisement for this company's product, it also really makes me think about the powers you gain when you have truly broad test coverage.↩
I agree with some of the basic tenets of the 'Effective Altruism' movement, which has popularized this idea. But I'd like to clarify that, from what I've seen, the EA movement also fails to align with my values in some ways.↩
Okay maybe this article shouldn't be considered hearing a "good thing" about pair programming...↩