For many years I gave a talk titled "Questions Engineers Should Ask"
This list is missing the two most important [busines] questions:
1. How do you make money?
If you can't understand, or the interview can't explain, then I'd run away. This can also lead to interesting questions about risks, competitors, etc.
2. What's preventing you from making more money?
The answer that you want to hear is engineeringeffort. If not, you're (at best) a wallflower at the party. Don't be the chump that's at Goldman Sachs acting as a code monkey for the traders. Don't be writing code at a company (like Enron) which has its success based on digging holes in the ground.
That's highly disrespectful to software engineers working outside of software companies. There are many of them and they are not necessarily less smart than others.
Working in the profit center of a company is often enviable, but let's not forget that cost centers in large companies can also offer benefits in things like work/life balance.
I don't think the GP intended to call engineers at those kinds of companies lesser. I think the point that was made was that working at companies where the company makes more revenue by having better software is a better company to work for. If your role is a cost you're treated (explicitly or implicitly) as such. It's a lot easier to show your value to a company by being part of the revenue side of the equation. Reducing costs is great but there is a bias towards investing to generate revenue vs investing to reduce cost.
I've been at companies that were "engineering-driven" that were total disorganized messes and totally immature workplaces.
I've also worked somewhere at a "lesser" company where I was firmly on the cost-center side of things, but my work was seen as absolutely business-critical, I was treated well, I survived all reorgs and department layoffs and had my salary tripled from the time I started.
Working in unsexy companies is a tremendous opportunity because if you're good at what you do, people literally think you work miracles.
This. I've worked for an ISP as a software engineer for almost 3 years and even though the company doesn't directly make money from what we do, we are quite respected for the value that we provide.
Also that last statement hits way too close to home.
Fair point. There is a better way to phrase things if there was no intent. And is evident in this thread, intent doesn't change impact. Having colleagues, that I respect, who work in similar roles I perhaps should have considered this better.
--companies where the company makes more revenue by having better software.
You can get vibe of a company by asking if IT is seen as a cost center. If software is a competitive advantage you know that it's green pastures for your and yours. But places where culture holds back engineering, like being slow on the uptake of GIT or CI/CD which is often talked about online, these are places to be wary of. Those latter companies are either going to have growing pains or will die out as digitization starts to take them on.
I think this may be a better way to phrase what I was thinking. It doesn't have to be directly related to revenue. The revenue relation just makes it easier to be counted as core to the business model. I think it's important to say business model too. IT is core to essentially every business now, but when IT is core to the how the company fundamentally positions itself in a market it really changes things.
Though in the context of this thread, I don't know a good question to ask in an interview to tease out that information when it's not already clear. If you simply ask "is IT/engineering considered to be vital to the business model or core to company success", everyone will answer yes regardless of how the IT/engineering is actually viewed.
A version of this line of questioning that in hindsight I sort of wished I had asked interviewing at one previous employer is something along the lines of "How much do you think your executives believe that you do in software they could go back to doing entirely on paper if they had to?" I don't know the precise wording yet, and I know it's not a universally necessary question for every "all of IT is a cost center" firm. IT can be a cost center, fine. Software development can be rolled up under IT for a number of reasons, sure. But IT shouldn't be seen as an "optional" cost center, "software" as some accidental by-product of a business dealing with a lot of "paper" when the company scaled to millions in annual revenue on the back of software-based productivity. There's entire industries, such as Insurance, that have some weird delusion that if they lost all their software overnight they'd just go back to do everything on paper and imagine they'd have zero re-scaling nightmares, brownouts, burnouts, or profit loss. It's so weirdly out of touch with reality, and I think a huge part of the disconnect (including the pay gap) between the ~post-70s C-Suite and the day-to-day operations of the majority of modern corporations.
I'm not even sure had I figured out exactly what that question should be if it would have helped that younger version of myself in the place that I was at, but it's still a useful lens moving forward if I have to stay in the "dark matter" parts of software development in the parts of corporate America that don't consider themselves software development companies.
Why does it matter? You negotiate your salary and in a couple of years if you find your salary not matching with your market rates you find another job. Salary compression is real regardless. A job is like dating not a marriage.
Financial markets companies are now engineering and quant driven. Machines place 80% of orders in US equities exchanges, not humans. The company you mention just announced a $100M project to rewrite its core equities trading platform to optimize latencies at scale across markets. Great engineering culture too. Meritocratic, respectful, and you won't find people there going around referring to developers in other industries with the disrespect you do, for example.
In response to folks feeling that I'm being disrespectful of developers in other fields: you're right. And I apologize.
By way of explanation, this phrasing came out the slide deck itself, which was used as part of a recruiting effort at colleges for new hires. In many cases we were competing with offers from finance firms and felt the need to distinguish ourselves to compensate for their salaries
Having said that, I stand by much of my statement: assuming you have a choice between those two types of roles, you'll end up in a better place where your job is a path to more revenue rather than a cost to be minimized.
Seems very rare that it will be the case that engineering effort is what’s stopping a company from making more money ... almost all companies will have sales pipeline or finding pmf as the answer to that. (If they know the answer.) Trading firms actually seem like one place where there is often a direction connection between code = money.
I'd love to include those questions with links to the talk if you can find it!
(Like the siblings comment, I may disagree with "The answer that you want to hear is engineering effort", but the questions are definitely valid in some situations)
I often see your response to #2 brought up, and I would generally agree with it.
With that being said, in my experience of working at companies that actively sell software, whether it's as a product or a service, you are still incredibly likely to be as much of a wallflower as you are at a non-tech company. Your perception of freedom is higher, but ultimately your time and budget is limited by whoever manages you.
I'd be interested in the slides to see if your questions dig into one of the most common issues I see at tech-centric companies - micromanagement? Is it a thing - and if you say no, would a random selection of three of your developers tell me the same thing?
This list is missing the two most important [busines] questions:
1. How do you make money?
If you can't understand, or the interview can't explain, then I'd run away. This can also lead to interesting questions about risks, competitors, etc.
2. What's preventing you from making more money?
The answer that you want to hear is engineering effort. If not, you're (at best) a wallflower at the party. Don't be the chump that's at Goldman Sachs acting as a code monkey for the traders. Don't be writing code at a company (like Enron) which has its success based on digging holes in the ground.
I can dig up the slides if anyone is interested.