Interestingly, I've heard many instances where interviewees asked startups about their revenues and the startups just wouldn't tell them, saying that it's growing, or some other vague nonsense. Even in the case of inquiring about the amount of equity one gets, many startups would not tell them the actual percentage of the company they'd get, instead opting to tell them the number of shares, without actually telling them the total number of shares. Well, 1000 shares out of 10k is very different than 1000 out of 10MM.

This is a huge red flag in my eyes, of not being open enough to see the books. It signals that something is quite wrong at the company, and even if it weren't, that they are not truly honest with their employees.

One time I had a CFO yell at me for asking questions like you mention. I obviously passed on the job. The hiring manager called me soon after and said he respected my professionalism and understood my decline of their offer. They were out of business < 6 months later.

It depends on the stage of the startup, but the books should probably be open to people who have made it to the offer stage until at least series b.

if they're not, I'd be worried about the financials, the culture, or both.

Refusing to disclose the number of outstanding shares is a huge red flag.

It's a huge red flag, and it's a hugely common red flag.

A startup was peeved I valued their equity at zero when they wouldn't share. I got strong hints my equity was worth at least $100k in extra annual salary, but they wouldn't budge on disclosing anything I could hold them accountable to. I think they were being honest, but I didn't take the job.

I did take a previous job like that, and when the company sold, we were all surprised management was honest. Management gave a used-car-salesman vibe, which was just wrong. I think with transparency, people would have worked much harder.

I don't have insights as to the reason for the extreme opacity.

The reason for the opacity is obvious, they want you to think the equity is worth more than it is.

People constantly assume good faith in these things when they shouldn’t.

Obviously number of outstanding shares is a bare minimum, but things like cash reserves and cash flow should also be shared but they don’t want to share that information, often times because it’s not good, they just wasn’t people who believe in the “mission” or that it’s a rocketship or whatever.

The secondary reason is that there are still too many naive engineers who assume good faith, drink the startup koolaid, and take these offers . Sometimes even declining public RSU grants to do so. One company out of ten thousand have ISOs that are worth anything but those are the only company in the headlines so the mystique continues.

The only solution is education. ISO (Incentive Stock Options) are one of the biggest scams of all time and you’re financially illiterate if you value them more than zero. They are carefully designed by venture capitalists to screw employees. NFTs of monkey pictures are infinitely stronger financial assets than startup ISO - I mean, as least the monkey jpegs have liquidity and volume, and no liquidation preference coded in to screw you over.

That's the thing, though. It's not always a scam. You never know whether you're being scammed. I /didn't/ get scammed, but everyone working at my first company out of school thought we /would/ get scammed. We've all seen a lot of people get scammed.

Not everyone in a pyramid scheme loses money, but that doesn't make it not a scam.

ISOs worked out well for me. It wasn't a huge windfall, but the preferential tax treatment is actually quite nice.

Really the best strategy is ISOs that convert to NSOs with 10y exercise windows when you leave. best of both worlds.

> ISO (Incentive Stock Options) are one of the biggest scams of all time and you’re financially illiterate if you value them more than zero. They are carefully designed by venture capitalists to screw employees

Given the number of millionaires and billionaires who can credit ISOs for their current wealth, I think that's too broad a statement. At the end of the day, a well-run company that can eventually go public because they have a strong business can be worth joining and the ISOs can be worth something someday. Admittedly, many will not, but if you pick the right one, you could do well.

Survivorship Bias at its finest. You don’t hear about the other 90%+ who got absolutely nothing.

> Admittedly, many will not

You mean, "there's a chance".

Have you looked to see if they're still around?

I just checked:

* They IPOed and are still in business.

* If I had taken the offer, the stock would have been worth between 50k and 150k per year, depending on when I sold it. Their estimate of 100k per year was spot-on.

So they were being honest. Good to know! They were late enough stage when I was applying that they could do a fairly reasonable valuation. I think I would have been much more likely to take the offer if I had information like this in writing.

I still think I was right to value the equity much lower, since I had no way to know if they were being honest at the time.

The job I have now includes options. When the job offer was being negotiated, the recruiter called the options "monopoly money"- worthless and having no known value. Just 1000 pieces of nothing. I was frustrated at the time, and negotiated purely on salary.

Ultimately, I came to respect their opacity. They didn't try and deceive me into "millions that could be mine if only X happens"

I have been in this situation post-hire. I asked for outstanding shares and other documentation about my options. I never received anything. Just a single "You have X options" line on my pay summary.

Unsurprisingly, my options turned out to be the typical startup-style employee incentive options which were invalidated/worthless upon the company being acquired.

I was young and new to the industry so didn't know any better at the time.

Experienced basically this while working for a startup. Equity turned into shares, which turned into "incentive points" that could be revoked at any moment and for any reason and were otherwise worthless. Same deal, 15k "incentive points" out of some unknown number. We pressured them on that for a while, because it was completely unacceptable for the amount of work we'd done for them, but then the entire dev team left.

Ok. They tell you their revenues. What good does that do if they don’t have a profitable business model?

Because then you can at least choose the company with 50MM ARR over one with 5M ARR if you have multiple offers

And what if that company with 5 million in revenue has a net profit margin of 20% and the company with 50 million in revenue has a negative profit margin?

There are a lot of what-ifs. The point is you can only decide on information you have access to, not on secret information you dont have access to. The best thing would be to know someone at the company who can share more details informally.

It also comes from feeling financially secure enough to be comfortable asking those questions. Early in my career I wouldn't have, but at this point I have enough money that I can afford to be more discerning.

Ultimate test of a good place though if you ask when young.

I asked for my first grad role. I asked a lot of probing questions. 3 years in I was running teams and setting up operations for the business in another country for them. I even told them I’d be leaving to start my own business after this job (and did). This resonated because I was speaking to their founder at the time and knew we’d be cut from the same clothe.

Holding yourself back at a young age can just stunt your career development. Asking such questions will appeal to the right employer.

Unsurprisingly this one went from 35 to 150 staff, profitably in the 3 years I worked there. I was 22 when setting up other parts of their business. I’d started at 19.

I wouldn’t advise folks to avoid such questions just because they’re young or “need the job”. Stand out! You’re even more likely to get the job.

As noted by others here: if they react poorly to this in the interview, you already won by dodging a bullet.

I think you missed my point, some (possibly most) literally can't afford to do what you're suggesting early in their life. It comes from a place of financial and psychological security.

I suppose it also depends on your country, but at least here in the USA, that's hard to come by (especially for the lower / middle class).

Being able to be discerning about a job is a privilege that not everyone has. As someone who finally can, I'm happy to acknowledge that rather than pretend other folks are doing something wrong.

I don't disagree that they'd be dodging a bullet, but some folks have to take a bullet to get health insurance, pay the bills, and god knows what else given their circumstances :)

Why? I work to exchange labor for money. They hired me because I generate more value than they are paying me. The company doesn’t “care” about me. It’s purely transactional.

If I got hit by a bus tomorrow, they would send flowers and “thoughts and prayers” to my wife and have an open req before my body got cold.

Say amen to this, guys!

I agree. I've had a couple of stints as a manager, now as a CTO for a small startup, and it's giving me so much insight into thinking about engineering from a business perspective. As an IC it's hard to get that birds eye view, but it's possible.

>As an IC it's hard to get that birds eye view, but it's possible.

Unless you actually have a consultancy which is based on seeing the ways in which you may plug a hole in the dyke...

And IC should ADD value to the org, not just slurp off of a need the company needs to fill.

Can you mention one or two such insights about thinking about engineering from a business perspective?

1. A developers job is not to write code. You happen to write code as part of your job, but your core responsibility is to implement solutions to business problems. Sounds simple, but it's harder to realize in practice. Case in point was a recent freelance job I took on. This client had paid some devs for months of work on a Stripe integration. They had built all this custom code on the front-end and back-end. I came in, read the docs since I was new to Stripe, and quickly learned that a custom solution puts the company on the hook for 300+ security requirements for PCI compliance. I scrapped all the code and directed users to Stripe's own checkout page. Not as nice of a UX, but that company's customers are now much more secure, there is less code to maintain, and the client is happy.

2. Your managers aren't perfect people, but their livelihood is in your hands. It's incredibly stressful to be a manager, so try to have compassion and empathy for the position they're in. They have to explain to the executive team the progress you're making, and if no progress is being made, they take the blame.

3. If you can't connect the dots between what you're doing on a daily basis, and the overall trajectory of the company, then something's wrong. There's a broken connection somewhere, and no one other than you is going to realize it. Speak up if you don't think what you're doing is useful.

> . A developers job is not to write code. You happen to write code as part of your job, but your core responsibility is to implement solutions to business problems.

My job is to write code. Nobody is interested in my opinions about business problems.

I have to be aware, of course. I propose code to write some times, and I have to have some idea that it is a vaguely practical thing in business terms. I want to write code in groovy system A but mundane system B has a better chance of success then my desire for system A goes by the wayside.

But it is my job to write code. That is all.

Code is an expression of a business solution. The meat of any application is in the business rules it enables and enforces. In a very well oiled machine it might be possible to just receive some behavioral requirements and get to it, but in my experience that isn't the norm. To be an effective engineer, you need to have a solid understanding of how the code you're writing solves the needs of the company.

Unpacking that:

> Code is an expression of a business solution

At some very high level that may be true. The person who makes the final decision on what code I work on (who happens to be the brother of the CEO, poor fellow!) may have to consider "business requirements", but only lightly. We implement what we are told to implement. I am a worker.

> The meat of any application is in the business rules it enables and enforces

No. That is crazy, and very high level. Where I work the "meat" is tight loops, memory allocation, network latency, data reliability....

> To be an effective engineer

I have not been to Engineering School. I am not an engineer. Engineers are people who have been to engineering school. I am a computer programmer working on low level iOS plumbing. "Engineer"? Huh! Putting on airs, I do not do that.

> To be an effective engineer, you need to have a solid understanding of how the code you're writing solves the needs of the company.

To be an effective computer programmer I have to understand the requirements that my firm has of the hardware. I can give very good advice about whether the hardware can be persuaded to do what they want. I cannot give (good or valuable) business advice about whether the things the firm wants are the correct things.

I understand a lot of people here really want to be successful "founders" and come at it from an engineering perspective. Very good. It is different for them than for me.

A lot of us (at least one of us...) here are workers who want to do a job, for a salary. Happy to work for one of those founders if the money is right. (I have to make a business decision about who I work for, in the best scenario. In my case I took what I could get, and got lucky - thank you universe!) I am not qualified (I am actually, another story) and am not employed to give business advice, or to care. I am more valuable to everybody if I stick to my knitting.

You’re not unpacking anything in what I said, you’re just disagreeing with each point, and each disagreement is mostly rooted in a misunderstanding of what I’m saying.

My point is that the code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I’m not sure how much experience you have, but if you have enough, you should know how easy it is for an engineering team to become disconnected with the goals of the company. I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to.

Now, you could look at that situation and envy the job security. Sure you could just see yourself as just a cog in the machine, with no responsibility whatsoever in wondering why the fuck you’re doing what you’re doing. But I certainly would not hire you.

> code, and all it’s material constructs that you pointed out (loops, allocation etc), do not exist apart from the business, because it’s the only reason those things exist in the first place. I

What else is that true for? All the way down. Biology, chemistry, physics, quantum physics.... All that we work on exists in those contexts too. Yet we just swim in the sea and ignore the water. The same is true of business matters. They are the ocean I swim in

> I’ve seen devs waste literal months on things that, had the primary stakeholders known about it, they’d never have agreed to.

That is poor communication. Communication is a necessary skill for all cooperative endeavours.

I am a cog in a machine. Unusually for some one in my position I actually have a good understanding of business (studied it for years) and I prefer computer programming. Having computer programmers stick their oar in over financial matters, unasked, is not good. So I do not do it. I know my place, I like my place.

Do you honestly think I’m being so literal when I use the term “business” that I’m talking about devs getting involved in financial matters? I’m talking about developers approaching their job with the understanding that they work for a business, and that their output is intended to drive business results. If they don’t understand how their work affects the business, there is an issue.

> That is poor communication.

…yes…as I said, there needs to be a tight chain of command with clear directives at each layer, in other words, good communication. When there is a break in the communication chain, the only thing you can rely on is an individual developers judgement.

> Sure you could just see yourself as just a cog in the machine, with no responsibility whatsoever in wondering why the fuck you’re doing what you’re doing. But I certainly would not hire you.

But there are lots, and LOTS of people who would, and want EXACTLY THAT. They want people to be told what to do, and do it, and not question why.

Yep, and maybe I was being too harsh in how I said it. It's an understandable sentiment; I've just never seen it work in practice. Inevitably, the team (over time) begins to move orthogonally to the company. Like I said above, you'd need a very well-oiled machine, ala a super tight chain of command with clear directives at each layer.

I see it in the same way I see security. A company is only as secure as its most vulnerable employee, so everyone must be vigilant about their own personal security practices. Same goes for "product security" - ensuring that the micro-actions taken by each IC reflect the company's objectives. It's an all-hands-on-deck practice.

I really like #3. If you don't know why you are doing something, it is very unlikely that somebody else knows better.

I've got this bookmarked: https://github.com/kuchin/awesome-cto

If you're going to be paid in equity and not asking those questions, unless it's a publicly traded company (where you have these answers ahead of time) or you are getting compensated well above average in cash equivalents, it would be just plain irresponsible to not ask those questions.

Even if you are getting paid an extremely good salary, who wants to start working for a company that's potentially months or a year from becoming insolvent? The fact that this might not be standard due diligence as suggested by your comment is mind boggling to me.

It’s statistically irresponsible to think your equity is going to be worth anything in a private company and give up cash compensation.

I never ever again am going to count equity promises as part of my remuneration. My pay is all I count on, once I have banked it.

Otherwise I become shark bait. Been there, done that.

> an above average developer

I'm average and have always asked these questions :) When I got my CS undergrad I almost had a minor in business, so that side has been an interest from the start.

How the company is doing, what is their core business, and how will my position fit in that business have always been key questions for me when interviewing a company.

I don't really "care" about the business, not in any sense similar to the founder or CEO at the very least, but as a contractor who usually works long-term for one client, I always make it a point to ask what their runway is during the interview process as that will pretty clearly tell me how long, in the worst case scenario, I will have this client for.