the fact that you stopped to ask those questions makes me think that you're at minimum, an above average developer.
caring about the business and its fundamentals is important beyond just slinging code.
caring about the business and its fundamentals is important beyond just slinging code.
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.
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.
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.
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.
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.
Really the best strategy is ISOs that convert to NSOs with 10y exercise windows when you leave. best of both worlds.
* 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.
Ultimately, I came to respect their opacity. They didn't try and deceive me into "millions that could be mine if only X happens"
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.
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 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 :)
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.
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.
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
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.
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.
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.
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.
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.
> 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.
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.
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.
Otherwise I become shark bait. Been there, done that.
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.