Ask HN: How to find companies that build sustainably?

YMMV but I think it all boils down to incentives, institutional maturity, and leadership. Here's what I look for:

1) What industry it is. A banking or security company typically has strong incentives toward building secure, stable systems.

2) Maturity. Experienced organizations may still have the impulse to hack things together, but at least have had a chance to internalize the value of security, testing, and realistic ship dates, and to hire sufficient staff to actually look after those things.

3) Who leads the organization. Nontechnical cofounders can be indispensable in their own way, but technical cofounders are more well equipped to appreciate why good software takes time and should be built robustly and securely, and balance other voices in the organization that may not have the benefit of that same background.

Business risk can come from a failure to innovate in some situations and a failure to provide stability in others. I've been at both extremes of this. It sounds like you're at one now. I prefer to be somewhere in the middle - pushing myself, learning, but not burning out.

Fortunately my current company fits this criteria. Anecdotally:

1) Tests are included in the scope of tickets

2) We have institutional memory of what happens when you build too quickly

3) Leadership is rich with experience in security and engineering

Good luck in your search!

> Leadership is rich with experience in security and engineering

I think this is so important.

Thank you

Great question and I’d be very interested in knowing what to look for as I pursue future opportunities. Because I have seen multiple times that usually non-technical upper management doesn’t give much of a crap about the tech debt that piles up around a “done fast not right” production stack, and wants to continue operating as lean as possible to attract further investment, and you will continue to operate your franken-MVP in perpetuity.

exactly! the business has to actually value employee satisfaction and system reliability.

My two cents:

Find a company that is profitable and hasn't taken VC money. This can either be a bootstrapped software company or a company for which software is an enabler.

In both those cases the software is an asset like any other, so maintenance and quality can be built in. There'll be trade-offs of course, but in these environments there is a most of some kind and you can put better practices into place.

It seems your perspective on the industry has been built over the hype of "Software will eat the world".

Aell, I'm not discussing whether this is true or not but just remember that building software is about building automation and experience. What I mean is that you must look for a company that enables or offers leverage to an existing company or industry. What it will provide you is the understanding that software is not the beginning and end of all things. It's a tool. A very valuable one, but still a tool.

And then, you will leave the vicious circle of hype and software centrism and maybe you will land in a much less fancy, much more interesting, software project in which you can commit for a longer term and actually feel like you have an impact.

FYI: it feels good.

Ask in the interview! Some ideas to get you started:

• How do you make money?

• Do you make more money than you spend?

• What’s the size of your market?

• Who’s your biggest competitor?

• What do you do better than them and vice versa?

• What’s the biggest threat to this company being around in 10 years?

Thanks for this, I do have some (EDIT: A LOT) other questions around this that I'll be asking.

• What is your company's relationship with velocity?

• Do you find yourselves doing more slowing down to be more careful, or speeding up to win a competition?

    • What slows you down?
    
    • How do you accelerate?
    
    • What is the expected time scale of a typical initiative?
    
    • How many initiatives does a typical engineer work on simultaneously?
    
    • How was a recent initiative measured for success?
    
    • How do you know when to stop an initiative?
    
    • How do you decide when to start an initiative?
    
    • Describe the company's philosophy about planning work in terms of top down VS bottom up planning.
    
    • In your experience, does the company behave in accordance with its philosophy?

• Describe your approach to on-call shifts?

• How many alerts does an engineer receive on a typical on call shift?

    • How do you make sure that engineers are not succumbing to alert fatigue?
    
    • Describe a situation where I am getting an alert as an engineer. What does it look like for me to successfully respond to that alert?
    
    • How do you document the steps necessary to take when responding to alerts?
    
    • How do you decide when to create a new alert?
    
    • Do you have a central list of all alert policies for your system?

• How do you know that everything is working or not working in your system?

    • How many subsystems do you have? How do you determine ownership of your subsystems?
    
    • Describe your approach to observability and instrumentation.
    
    • Can you show me your observability system?
    
    • Can we pretend to solve a problem in the system together, using your observability platform?

• How do you do deployments?

    • How long does a deployment take, assuming approval?
    
    • How long does it take on average to get approval?

• How do you ensure code quality?

    • What's your worst section of code? What makes it bad?
    
    • Can you show me part of your codebase?

• What is your approach to onboarding new engineers? How long does it take to get a dev environment set up?

• What is your current architecture?

• How do you make architectural decisions?

    • Where is the architecture going?
    
    • What are the downsides of the current and future architecture?
    
    • How much work is driven by “deep integrations”, in other words how much code supports unique partners?

• What is the onsite culture like? Do coworkers typically become friends?

• How many hours does the average engineer work per week?

• How many weekend days does the average engineer work per month?

    • What is the typical cause of after hours work?
    
    • How much time does a typical engineer spend in meetings per week?
    
    • How many days off does a typical engineer take per year?

This reads like a list of questions designed to avoid the things you hated about your past job. Which is totally understandable, but this is way too many details - you won't get time to ask all these. I'd try to narrow this list to more general questions that will still give you the answers you desire by letting them talk more about themselves and you taking on the burden of reading between the lines for details. Aside from being more time efficient, it also is better psychologically speaking - helping them to talk about themselves in a positive light makes you look interested and makes them feel valued vs. making you look cynical and wary.

Thanks for that feedback! I definitely do not intend to point blank ask all of the questions. Rather, it is a checklist of things that to find out about.

> helping them to talk about themselves in a positive light makes you look interested and makes them feel valued

I really like this thought. I'll definitely think about how to do that.

I think most of this comes down to leadership. The company I work for is trying to grow rapidly in terms of users and doesn’t make a profit currently, but does care about quality and does have some slack and most importantly cares about its staff and its users. The company is in the mission-driven social enterprise category so maybe that helps.

The main issue is that barriers to entry in software are very low. If there is a successful company doing something with software then there is no way to lock someone else out of building a similar service with some slight variation. So I'd say that as long as you are looking at for-profit companies then there is no way to avoid the issue of cutting corners, bad system design, and burning out engineers with stress and overtime because the leaders at these companies know that all the other companies are doing the same thing in order to stay ahead of their competition.

You might have better luck if you start looking at non-profit companies but you'd have to actually figure that out for yourself and work at one to see if it was a better fit for what you are looking for in terms of work.

> The main issue is that barriers to entry in software are very low

Great point. This is such a double edged sword because it is the reason that I got into software in the first place.

I have been looking for 3 years and haven't found one. I think only bad companies are hiring because only they have money. It's hard to make a profit from quality software products.