I've been thinking about low-friction options for getting a sense of the engineering quality. I don't think I'm alone in thinking that technical debt and bad software development practices are a top concern.
Being quite senior now, I'd feel comfortable asking:
1 - To see their CI dashboard
2 - To see a sample of their production systems stdout & stderr
3 - Asking to review a recent non-trivial commit (with the person/people who wrote it)
4 - If you're interviewing remotely for an on-site position, finding out if they have an open office
In the context of a startup, I would expect almost all of those to be disappointing. But maybe that's what you're hoping to see.
In my opinion, if you're a start-up and you've got all those boxes checked, you're possibly doing the right things in the wrong order, and that's a red flag for me. What I hope to hear are responses like, "so this is how we're doing CI. It's awful, almost non-existent. But that's because at our scale it just wasn't important. But as we grow it will become VERY important, so here's what we're thinking about doing in the next 6-12 months..."
I've experienced a start-up with lots of tooling and process , none of which matters when you take forever to ship (and stay shipped).
I would expect most to be disappointing too, and it's a good idea to avoid those.
Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say:
we don't have time to do it right
Almost always mean:
we don't know how to do it right
Talent, not time, is the enemy of quality. (at some point that stops being true, but most companies (startups or not) are soooo far from that).
If we are talking about a really young/small startup and you're a senior person, then you need to have a discussion about it with whoever you answer to.
If we're talking about a really young/small startup and you're a jr person, you'll just learn a bunch of shitty habits.
If we're talking about an older/larger startup, then you have a problem.
For the first year or so, the only way to get builds of our software was for me to click "build" in Visual Studio, on my laptop.
I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature.
There are numerous things that increase velocity for a large team, but decrease it when the product is just getting started. Joel Spolsky wrote about something similar almost a decade ago, https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
It usually happens when changing the build means something like "Let's package the installers with WiX instead of NSIS, so we can provide MSIs for enterprise clients".
That doesn't make any sense. Setting up the CI pipeline should be the first step, before writing any product code. It doesn't cost you any time, it saves time and allows for building more features faster.
That sounds completely unrealistic and utopian to me. Before I even consider how to deploy a product, I want to experiment locally to find out if I even have a potential product. Most of my experiments never amount to being anything more than an experiment. If I had to set up a CI pipeline before writing any code, most of them wouldn’t even amount to that!
Maybe, if I were executing on someone else’s vision, I could justify taking time up front to set up CI. But I still think it’s a little dogmatic to state that this has to be the first order of business, always.
Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say:
we don't have time to do it right
Almost always mean:
we don't know how to do it right
You're not wrong. But we're talking startups here, not established companies. It's publish or perish time.
When the company has enough breathing room, circle back around and do it the way the big boys do.
I disagree. Publish or perish includes time to triage issues, bugfixes, and new developer onboarding.
If logging is fubar'd then all 3 of those are impacted.
If you're pushing a PoC out the door. Sure, go on ahead and forgo proper logging. But if you're secured some form of series funding and need to scale. Fix your boat before you launch.
Disagree here.
You can go without lots of tooling and aim for simple and effective. You can even let in code that won't be perfect in the future (probably you'd be prematurely optimizing for the unknown future). But defensive programming will save you time.
Non shitty logging takes minimal time, like, so minimal. It will make many bugs and customer issues trivial to fix.
In the least, use something like Sentry. Makes up a lot for not logging because it adds the context with your uncaught exceptions.
I think the point Waterluvian is making is that if a startup has all its development practices buttoned down right, it's either not a startup or it's going to go out of business soon. Most people (who are even thinking of working at a startup, at least) would rather have a job that's organized chaos than not have a job at all.
The ideal order of tasks for a startup usually looks something like this (and I say "ideal" because very few startups actually take paths resembling anything close to this):
1.) Figure out what & for whom you're building the product. The founders should do this before hiring employees.
2.) Validate that the people for whom you're building the product will use it, and ideally will pay for it. The founders should do this before hiring employees.
3.) Take investment. Ideally this would get pushed as late as possible or skipped entirely, both because you get better terms for that money when you've made more progress and because it often comes with strings that prevent you from going back to step #1 if necessary, but it's usually a prerequisite for step #4.
4.) Build the product. If the founders can do this themselves, they're at a huge advantage, because oftentimes you find you need to go back to step #1 after this is complete. But usually you need employees for this.
5.) Charge money, so that it becomes a sustainable business.
6.) Everything else that goes with being an actual business, from getting HR policies right to development practices to career ladders for employees to working out company mission statements.
And if you're doing step #6 before you've completed step #5, there is a very large chance that you've made a critical error in judgment that will kill the company. Why? Because you haven't actually validated step #1, and all the work in steps #4-6 depends upon getting that right. You might have setup a beautiful CI dashboard with 100% test coverage, only to find that all your unit tests & continuous integration need to be thrown out because your product needs to be rewritten in another language because the product concept requires a large & critical library that's only available in another language. You might have spent months developing & building relationships with employees only to find they need to be fired because you need a completely different skillset to build a different product for a different market.
It's fine to want a nice, orderly, 100% tested with CI setup and a robust release process development process as your working environment. At an earlier point in my career, I certainly did. But if that's what you want, I would highly recommend not working at a startup and going to Google instead, where you have a full test suite run on 1000s of machines on every commit and the results of it are instantly visible on their code review dashboard. That's what I did, and it was only when I realized that Google in 1999 was about as far away from that as it's possible to get that I became more comfortable with the codebase being a complete mess as long as it works & has happy users.
But setting up CI is a day's worth of work, and pays off almost immediately.
Having reasonable logging in an app of any serious size is a cultural thing; it takes exactly as much time to write as bad logging, and saves oodles of time every day when you have to discover and fix issues.
Compare it to building a motorbike. Yes, you want a prototype fast. But if you have all your tools stored as one big pile, or have oil and fuel spilled next to your welding machine, it does not speed you up; it sets you for an accident after accident.
The issue with all of these things is that in a startup you don't know what the expected behavior is. You only can find that out, for sure, by putting it in front of customers and having them pay you for it - which often requires building the product or at least some approximation of it first, and may need to be repeated dozens to hundreds of times before you find something that is a.) useful b.) worth paying for c.) can't be found cheaper elsewhere and d.) has a large enough market to be worth building. You can and should short-circuit some of this with non-code development (eg. talking to customers, putting mockups in front of them, getting sign-ups on a landing page, signing LOIs), but you never know for sure that your product is worth it until people give you money in exchange for using the product.
Unit/acceptance/integration tests, if done right, capture requirements. They verify that the code does what it should do, and continues doing it even when changed. You can't write meaningful tests until you have some basic idea what the code should do - what would your expected results even be?
Logging, if done right, is about being able to quickly answer questions about the operation of your system. You learn which questions to ask only through the experience of having people actually use it. Logging can easily tell you fine-grained details about how much wall-clock each phase of your program takes. Should it? Well, depends - if you're about to rip all the code out and rewrite it, or if it's just something that runs once to generate some data and never again, it doesn't matter if it's slow.
Similarly, good logging can tell you precise details about how people are using the product. Should it? Here's a counterintuitive lesson learned the hard way: not until after you've answered the question of are people using the product. If you're getting a bounce rate of 100% (which you can determine by slapping Google Analytics on the front page), you need a completely different product concept, and it's a waste of time to instrument each user action with fine-grained logs until people are actually using it. You can always go back and add the logging then.
A motorbike is a poor analogy. The consequences of failure for most tech startups are significantly less than the consequence of a motorbike crash, the software is a lot easier to change than motorbike parts, and the goal of what the software does is a lot more ambiguous than what a motorbike should do. Rather, I'd use the analogy of a novel. Your first draft of a novel is going to suck, it'll barely make sense, and the goal is just to get your thoughts down on paper. When you do revise it, you revise for plot & character first, then pacing and voice and realism and sensitivity, then you might clean up dialogue & wording, and only then do you look for typos. Why? Because there's no point in fixing typos for passages that are going to get ripped out and replaced anyway. Spelling and grammar is the part that everybody thinks of because it's the part everybody can do, but it's really the last part of putting together a finished story.
Similarly, unit tests & CI & logging & one-click builds are the parts that everybody thinks of when they hear "development" because they're the parts that everybody should be able to do, but they're the last phase of building a worthwhile product. The first questions are "Who is using this? What are they trying to accomplish? How does it deliver value? How is it different from other alternatives available?"
I've been telling people this for years. Automated tests are a good way to ensure that updates and iterations don't break existing expectations. But expectations come from users, so if you don't have users, you don't have expectations, you only have guesses. You're usually better off getting your guesses out in front of users so you can establish expectations, and then build your automated tests around that.
I say "usually" of course, because there are certain things that constitute expectations that precede users, such as apps that handle sensitive information. Expecting that the app handles sensitive information appropriately before users confirm that they want their sensitive information handled appropriately would properly not be considered a guess.
That might have been true 20 years ago but today basic development practices are a solved problem. Any competent senior developer knows what to do. There's no need to start with chaos and repeat the same unnecessary mistakes.
It's a solved problem for a given problem domain. The "best practices" for software development depend very heavily on which particular industry you're writing software for, and senior developers in one industry are basically incompetent when it comes to working in a different industry. I've worked in finance, I've worked on search, I've worked on casual Javascript games, I've worked in compilers & devtools, and I've worked adjacent to people who are doing avionics. There is no way in hell I would apply the development best practices for Javascript gaming to making a plane stay in the air, and similarly there is no way in hell I would apply avionics standards to casual games.
The point is that in a tech startup, you are attempting to solve a previously unsolved problem. If the problem has already been solved before, why shouldn't your customers just use the existing solution? And there's a generic set of best practices for startup coding, but it basically amounts to "Do absolutely nothing that doesn't help you validate the key unknowns of your business hypothesis." Basically if you know that something is going to work, you shouldn't be doing it - you should be integrating the library/service/tool that already does it, or hiring the person that's done it before.
The vast majority of software startups are attempting to solve previously unsolved business problems using mostly the same technology stacks as everyone else. The basic principles of CI/CD are pretty similar regardless of language or tooling, and should now be understood by any competent senior developer regardless of whether they work in gaming or avionics or whatever. Applying those CI/CD principles absolutely helps with validating the key unknowns of your business hypothesis; it doesn't waste time, it saves time even at the beginning.
There will of course be some outliers where these best practices don't apply, but I assert that those are very rare. Most startups aren't special.
Sure. If the technology involved in your software startup basically involves putting a web or mobile app in front of a Rails/Django/Node appserver in front of a RDBMS or equivalent NoSQL database, and the primary business questions are "What data do we need to store, and how do we present it to the user?" then getting your CI up is important. This was a large fraction of viable startups from 2005-2013, so it certainly was a large number of startup jobs.
However, my experience is that those opportunities are largely getting tapped out, and the ones that still exist in the market today are increasingly niche. Between YC & accelerators, services for startups (Clerky/Gusto/Stripe/AWS/etc.), availability of capital, and the amount of open-source software available to build systems, it's become incredibly easy to found a startup - which means that lots and lots of people have, and picked clean most of the markets where a viable product can be made by gluing together these components.
Continued success under capitalism means doing new things that haven't been done before. The web, mobile, and tablet were new platforms that opened up computing to huge new markets. However, all the new platforms since 2010 have fizzled and failed to get mass adoption - wearables, realtime web, AR, VR, cryptocurrency. That leaves tech startups founded today trying new things, either leveraging AI & data science for new insights, trying to get access to increasingly unruly data sources that have not yet been tapped, exploring variations on blockchains & cryptographic proofs, or combining various platforms & libraries in new ways to find new uses. All of these take a lot more experimentation and have much less defined best practices than web and mobile development, but the potential upside is much higher than leveraging a database-backed webapp to solve a new set of business problems.
Just because you change the acronyms doesn't mean that you can completely forget about CI/CD. It's still relevant. Even more so with the newer technologies. You'll probably use different build tools and testing tools. But everything else is still the same.
You will, and I'm certainly not objecting to the use of CI once you know what product you're building and what its architecture will look like. But the whole point of this discussion is that you don't know that in this phase of startup development. There is a non-trivial chance that you will have to swap out your entire tech stack or drop whole components from the product. Building extensive infrastructure around code that gets run 2-3 times and then deleted entirely is a waste of time.
If you've started building software that you're going to have scrap that quickly, your problem isn't with the tools. You've messed up big time with planning. Either way, you're still going to need CI/CD.
I'd agree that most are but if you move into scientific computing startups the problem domain is much different and
CI is a nice to have. It's much more about R&D.
It's not really free - for CI to be useful you usually need a test suite to run, particularly with the interpreted languages like Python that are commonly used for scientific or exploratory programming. Test suites are a waste of time when you can't define what the expected behavior is, and we're talking about a particular problem domain where the goal is to find the expected behavior.
From experience. Not to beat a dead horse in this thread, but logging is still the simplest example to grasp. Good logging takes 0 extra time over bad logging, the only difference is talent.
But you'll see this across the board. People who write well organized, readable, low coupled code do so naturally and at more or less the same speed as people who write piles of poo. They might both achieve the same functional output, but the clean code will pay dividends in the future (and not just long term, even next week when you have to make a little change)
Also, quality is pretty core to a number key principle of the Toyota Production System (which many startups _attempt_ to emulate). Kaizen, muda and jidoka.
Fred Brooks might have written "plan to throw one away; you will, anyhow." But he also wrote: "Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude. "
Maybe the context of the answer is more valuable than the answer in this case?
i.e. we have 95% coverage on our core IP and CI setup for all of our source code. But, we integrated X for that service to get off the ground quickly, which will be too expensive at scale so we didn’t implement testing around it yet.
> In my opinion, if you're a start-up and you've got all those boxes checked, you're possibly doing the right things in the wrong order, and that's a red flag for me.
In my opinion, that depends on the experience/background of your staff. I have even seen open source projects (not backed by companies) get all the boxes checked in a very short period of time. For a project maintainer who has prior experience, it just takes several hours at most to set up a git hosting server and the CI/CD infrastructure.
The time saved for fixing a single regressing can easily pay off the investment.
But having CI, proper logging, and code review isn’t over engineering. The time, effort and bugs saved by spending 1-2 days putting these policies and procedures in place is valuable early on.
Of course, each of those pieces is at risk of becoming over engineered. But hopefully the team has a leader that knows when to move forward and when to pull back.
Particularly CI. If you want to be able to release fast and often, having that automated is going to save you a lot of time.
And CI doesn't immediately have to include everything you'll eventually want; just having automated build and deploy will make your life a lot easier. Add some automated testing as soon as you can afford to (which hopefully is right away, because it's not that hard to set up), and you're ready to move.
Unfortunately I’ve met some people that take that mentality to a macho extreme in the form of “if you want to be STARTUP, you should actively avoid doing anything that resembles forethought.”
And in many places they go hand in hand - some pieces of code will be massively over-engineered and genericised for a future that will never come, while other, important (but possibly less interesting) pieces will be peppered with // TODO and // THINK ABOUT THIS LATER.
If you want your startup to run for more than a year (= roughly the time the effects of technical debt start to kick in significantly in my experience), you need to find a good way how to handle technical debt, and keep it in check.
I have seen my share of startups where a platform plagued with technical debt was the main limitation for growth, which is a very avoidable situation.
> If you want your startup to run for more than a year
I've never seen a start-up fail on account of technical debt. Re-engineering is expensive, but it means you have something worth re-engineering. I've seen lots of start-ups fail because money that should have been spent attracting and retaining users got burned on an elaborate engineering process.
> I've never seen a start-up fail on account of technical debt.
That's because noone ever says "XYZ startup failed because their code quality wasn't good enough." It's usually something closer to "Their customers didn't renew contracts, they had to slash headcount, and went into a death spiral from there."
If you press for details, the deeper reason might be "they couldn't turn around features fast enough" or "the app was slow or their servers went down too much" which is a symptom of too much technical debt (either directly, or because the better engineers on the team choose to leave as a consequence of the technical debt).
I agree that early startups don't fail because of technical debt, but I'd bet that many mid-size startups do fail because of it.
I've been in startups since the late 90's. Not once have I seen a startup fail due to technical issues. Several of these made it to the double digit million raised, 100's of employee phase.
Failure was always related to the wrong product being built or a bad business model (poor product/market fit, pricing is screwed up, some sales, but not enough to cover cost, no plan for marketing, etc.)
Poor code quality is rarely perceivable by customers, except in the most extreme cases.
Ok but like middle ground exists here. There is a huge difference between thinking carefully about what you need to do right and planning what bits are going to end up as technical debt, and how you can fix it later - and what actually ends up happening in my experience where everything is shit because we're too busy being a s t a r t u p to practice engineering.
Setting up CI is basically as simple as adding a small .yml config file to your git repo (if you are using a service like Travis or Circle CI) and clicking a couple of buttons to give the tool access to your github repo.
I don’t disagree with you, not entirely. When I was younger, it was all about sprinting full out as long as possible and that is a company that is either going straight to the moon of more often bursting in to flames. I’m quite a bit older and more senior now too and I think there are two slices of startup time, you put in your 45hours doing whatever it is the company needs, often running like hell. Then there is the 5-15 extra hours a week a startup can take and I absolutely think those need to be spent on dividend earning things, logging, ci, documentation, better testing, tooling, etc.
Thing is, it can go to the moon or it can flame out but there is this giant middle part of the spectrum where there are good exits and those exits often involve supporting your product and having well documented and tested technology is a positive. Trust me on this, it really sucks to get bought and then explain that it’s going to be a year and a rewrite to do the 10 things the buyer wanted yesterday.
Dunno...one man band here until very recently. I had Github > CircleCI > Heroku automatic deploys on pass implemented on my own with LogDNA + Sentry.io to catch errors and monitor output.
Using Clubhouse to manage mine and the other dev's work now and it all seamlessly links up.
Took at most 30 mins to a few hours to setup each integration. Only downside is the monthly cost of all of the above but in all honesty if even a small startup doesn't have most of the above I'd consider that worrying.
I disagree with your checklist. Assuming you are interviewing for a very early employee (first 10 at most), then all those are technical issues that you will be able to fix. That's not a problem, that's your job and you are good at it.
I would worry a lot more about the business itself. Does it make sense? Do you see a credible path to paying customers? And the most important of all: are the founders the right people to grow and lead this thing? Could be experience or passion (ideally they should score high on both).
I disagree - tech debt and bad practices can be fixed with good leadership. But poor leadership will never give you the opportunities to make such corrections. I do agree that knowing the status quo is useful, but the trajectory the organization is on is more important than today's exact position.
I ask questions more along the lines of what is wrong, and how are they correcting it. Good answers there can show a good long-term result. Bad answers there... run away.
Isn't it a matter of ones preferences though? Even if the leadership is capable if a person finds day to day work with crappy codebase and poor tooling a drag there is no point in joining.
I'd like to say this is true, but I think in practice, you want early engineers to have the right technical + mental frameworks around good software development practices, and the current implementation may not reflect this (false negative). It's a good to have, but not a top concern imo.
One of the startups I worked with didn't have "good" practices just like what is listed above, and it took a while to get there. The thing is, we're still pulling quite healthy numbers, and we have paying customers. What made it bearable was our engineers knew what needed to be done, and had the technical chops to get there. You'll probably want to avoid very elitist engineering cultures that aren't open to what's considered good practices.
Many successful startups run on the shadiest software architecture in the early days, but market pulled product out of the startup. Today, they have the engineering resources to make it a lot better.
"How do you feel about Friday afternoon deploys?" is a great question for that. Many interviewers assume you want to hear about how they refuse to do them in order to protect your Friday night and weekend time. Really, the answer you want is that they've automated the deploy process and made it robust enough not to break production so it doesn't matter when a deploy happens.
Of course not, but the process of automating deploys (or anything really) makes you think through what can go wrong, and ways to mitigate problems, and put tests in place to make sure things worked, and add metrics, and test your rollback procedure, and so on. A company that doesn't have automated deploys is much more likely to have manual processes for more things than just deployment.
It's not a magic bullet, but in my experience it's a very good indicator of how a company approaches an obvious problem, so you can get a really clear signal about whether or not you'd enjoy working there.
I think if a company has good answers to these questions, then they aren't really a startup. More often than not, if they're hiring you (being quite senior) it's because they need you to do all those things.
But I do get where you're coming from. In my experience, it's better to ask about the team and its CTO to understand how decisions get made, and if the team is capable of recognizing quality. I don't care if CI isn't in place when I join as long as the team recognizes its importance and knows they need to get to it.
Most early stage companies would have had terrible answers to these questions. Including Facebook/Google/Uber/Amazon. Which just indicates that it might not have been an ideal role for you which is fair. Being the first 2-3 engineers at a startup is not everyone's cup of tea. The risk in most cases makes no sense for a sane individual. Your questions indicate a sense of "safety" that an engineer might want from their next gig.
They might not even be able to hire a Senior Engineer in most cases. Maybe you wouldn't even want to talk to an early stage startup at your current seniority level.
Having said that for anybody who really wants to join an early stage startup the only thing that should probably matter is what is it that you're trying to do and how can I help you reach your goal? Will you be able to pay me enough on time and for how long?
CI/CD can be set up pretty quickly with modern tools. You can of course spend time over engineering with lots of different environments that you can create with scripts but just setting up a basic pull request->build->run tests->automatic deploy->promote to higher environments is like one days work for one person these days.
I think I understand what you're saying, but I think you're oversimplifying, and that would do a disservice to people who may be new to the job market. Just because someone is a big name doesn't mean they're the right fit to lead a team - some of the best engineers I've ever met have no interest in leading teams, but are very valuable to have on the team. Hiring well, and believing in the team that you've hired is important, and I think it's a red flag to see management churn.
To me, the red flags are absolutes. i.e. "Yes, we would absolutely replace our team lead because we only want the best" sounds like a toxic place, and it's not the kind of place I would expect to find (most of) the best engineers that I've worked with. And "No, we would never hire that person because our team is the best" sounds arrogant or naive.
I've seen this behaviour where existing employees were forming a "cult" to cover each other, and promote one another, while technical debt piled up, and at the end basically brought products to a halt.
I'm not saying that VIP hire is some magic stick that will fix everything, but if they consider a taboo to even mention such a thing, this is not a environment to be in.
Idea: Startups, even moreso than mature businesses, behave similarly to organisms and exist on a fine balance between life and death. Corollary #1: all startups, almost definitionally, have the maximum amount of technical debt possible without dying (otherwise they would "move faster and break more things"). Corollary #2: Startups whose core business is selling to developers (as opposed to applications of software) are much more sensitive to technical debt.
> 2 - To see a sample of their production systems stdout & stderr
That's a good one, definitely gonna ask this at the final interview stage of my next job. It very much indicates how people work, whether they spend a lot of time fitting in features into a difficult code base or if things are just working a features a developed at a predictable pace. (On prod won't stop working on weekends)
>It is also important to note that early employees experience more dilution events. An example of a dilution event would be raising another round of funding. This is another reason why joining a company early should offer more equity.
I disagree that it's important to note that early employees experience more dilution events. I know you're trying to educate but this type of advice unintentionally misinforms people and causes people to pay attention to the wrong thing. Ultimately, the more important math is number_of_shares multiplied by share_price. As long as that goes up, dilution is not as important. What employees will care about is whether the total money wealth went up and not whether their 5% ownership turned into 4% because a new investment round bought 20% of the company. I have no idea why dilution attracts so much verbiage that's out of proportion to its mathematical importance.
I disagree. The most common way to predict payout is to compare to other companies' exit valuations.
E.g. "Oh, company X got acquired for $250 million. We do something similar. If I own .025% of the company, I'd make $62,500 if we exited at that valuation. Cool."
It's important to be aware of dilution events so that you realize when you accept the offer that your .025% will be more like .008% if you're lucky enough to have a successful exit.
>It's important to be aware of dilution events so that you realize when you accept the offer that your .025% will be more like .008%
But you're repeating the same error of prioritizing the wrong thing: dilution.
What employees ultimately care about is their wealth calculation: shares_multiplied_by_price.
Example of the type of math people actually care about:
0.008% (because dilutions) a $1 billion company is $80k
0.025% (no dilution) of a $100 million company is $25k.
People would rather have $80k than $25k. The dilutions that dropped them from 0.025% to 0.008% is irrelevant trivia.
For most employees that are minority shareholders, dilution is a side-effect calculation in the realm of academic trivia. Dilution is not a purposeful strategy in this situation. Highlighting "dilution" in advice for employees in an attempt to make them more financially more sophisticated has the opposite effect!
The scenarios for dilution to be a calculated strategy would be something like a founder considering 2 different offers from potential investors. One VC offers $20 million for 15% of the company. Another offers $30 million for 25% of the company. Or some founders selling too much of a percentage such that the dilution crosses some boundary such as 51% ownership where they collectively lose control of the company. These deliberate decisions around dilution are very different from employees realistically worrying about dilution dropping them from 0.025% to 0.008%!
You’re entirely (technically) correct. The issue is that side-effect often comes into play because employees like to calculate potential future outcomes, and that’s done based only on overall company value (since that’s one of the only data points that’s available from past acquisitions).
I’m sure you get this and I know the psychology of what an employee might hope for shouldn’t be relevant, but unfortunately it is.
(For those who don’t fully get this - what I mean is that folks often look at a potential outcome and say “other companies like this have been acquired for $1-2B vs $100B, so if I’m being given 1% at $10M my stake could be worth $10M!” When in reality after dilution, that stake might only be worth $2M, which is a very different outcome after 5-10 years of hard work at below market salaries.)
What you are saying, I think, is it is important to figure out what the expected future value of each of your shares are. All you have to go on, in general, is "what do companies like this one generally sell for"? From that, assuming all the preferred stock get converted back to common stock, you can figure out what each unit of stock is worth. The problem is, the cap table you have now won't be the cap table you have when the company gets bought out.
It's not dilution that is the problem. Dilution is just what happens when you bring in new money. It's that it is very hard to predict what a reasonable upper bound is for the future value of your shares.
Quite frankly, it is one of the big reasons I think trading salary for stock options is a horrible idea. Much better to treat those options are lotto tickets--the odds they pay out in any meaningful life changing way are very small.
Startups don't like to hear this because the truth is, when you work for a startup you almost always take a sizable hit to your salary.
Another aspect of this is that if you join an early stage startup and work there 5-10 years without any new equity grants (such as the annual refreshers that many companies give) while the company grows and does new funding rounds, then you're getting screwed badly.
I also think this downplays the liquidation preferences that come with taking venture money that also brings dilution.
A "billion dollar company" that raised $500M with a 2x liquidation preference will put many fewer dollars into an individual employee's pocket than a $100 million company that only raised $10m.
There’s a gotcha here. The VCs can disproportionally dilute early employees that they think are worth less by issuing new shares/options to founders or new hires.
It’s not true that everyone will always be diluted equally. Someone who isn’t involved in politics or paying attention to investor terms (oh, like an engineer maybe?) is more vulnerable to this.
> For most employees that are minority shareholders, dilution is a side-effect calculation in the realm of academic trivia. Dilution is not a purposeful strategy in this situation.
No, your logic would only hold for a public company with shares priced by a liquid market.
For a startup, percent ownership of fully-diluted shares is the key metric. (Other secondary factors, e.g. liquidation preference are also relevant.)
The strike price of the options is derived from the price that the most recent lead investor paid for the last shares purchased. This is not a market price -- the underlying value of the shares is often less.
But the options are effectively worthless until they are vested and a liquidation event, usually an IPO or acquisition, occurs.
>, percent ownership of fully-diluted shares is the key metric.
We are talking about different things.
I was talking about "dilution" as a verb/action that describes a _change_ from a starting % of ownership to a lesser % of ownership. The post I responded to was talking about dilution events.
Employees cannot realistically make calculated strategies around dilution _events_ because they are not on the board-of-directors and can't veto the founders to not accept additional round of funding. In any case, whether the employee's shares experience 1, 3, or 4 dilution events is not something people typically care about. What they want to really know is if they get wealthier.
On the other hand, if an employee is offered a # of shares as an incentive to accept a job, then yes, it's good to know if that means 0.10% or 0.05% ownership. It's smart to know if an employee is getting typical equity percentages in the industry that's commensurate with the role and timeline of the startup. (Some examples.[1]) However, that's a metric at a particular point in time and it's not a "dilution event" from the perspective of the employee.
Yeah, considering what I've heard about startup culture, I'd hope such equity payouts are a bit more than this. Anything less than $100k (note, a future expectation, and far from certain) is not worth accepting lower pay or long working hours for.
>you know only how much %% of a company is offered to you at the moment, not the future exit value.
But this "future exit value" is the same unknown for co-founders, angel investors, VCs, etc. Employees share the same unknown as everyone else as to what the eventual IPO or corporate acquisition valuation could be.
E.g. if an angel investor buys 5% of the company, he only knows his % ownership at that moment and not the eventual IPO price in 7 years. The angel also doesn't know what his eventual dilution will be. It really doesn't matter.
The angels and VCs ultimately cares about shares_times_price and that it has grown multiples of their investment. They already know they will get diluted because every owner gets diluted in the normal course of events. Selling equity to help it become a more valuable company means getting diluted.
E.g. When Accel Partners invested $12 million for 15% equity of Facebook in 2005, their investment got diluted when Microsoft later invested $240 million to buy 1.6% equity in 2007. That's how it mathematically works and it's normal. Dilution is a downstream math calculation side-effect of selling equity. The Accel partners didn't complain that they got screwed and owned less than 15% because the Microsoft investment diluted them. Also, neither Accel nor Microsoft knew what the eventual IPO price would be in 2012.
>how much %% of a company is offered to you at the moment
To be more precise, employees are typically offered a number of shares or options to buy shares instead of an explicit % of ownership. The % of ownership is a derived calculation at a point in time that's based on the number of shares. From that moment on, it's the price of the shares that ultimately matters and not the dilution because everybody's % of ownership will decrease as a normal event in growing companies that raise additional funding. Presumably, the startup hired employees that can contribute value so everybody's share price goes up which more than offsets the dilutive effects of accepting extra investment money.
A dilution event is always bad for the current stockholders. Of course getting investor money is a positive, but it can be a bad deal or the money can’t be wasted just leaving you with less overall ownership.
Don’t also forget you can have down rounds that can lower both your ownership and your share price.
I'm glad you said this. Many got burned including myself due to dilution events. When your 2% stake turns into 0.25% over time and you get paid last, there needs to be a very large buyout/IPO for you to get anything substantial. Add in the taxes paid on that and I would have been 10 times better working a corporate job with less headaches.
most companies dont ever reach billion dollar evaluations. say they get sold for a reasonable $100M after 4 years. my 1% stake as a founding engineer should gross me $1M (house money). but since there were 3 rounds I generally end up with car money.
I've been through this several times, and ended up with car money or nothing, and I dont think I'm alone. a warning to fresh grads that they may not end up retiring after spending years of putting in time and a half seems in order.
This is a great point. I think that on average you're unlikely to recoup the difference in wages in the event that the company is sold. I worked for a startup for four years and got nothing.
But without those 3 rounds, your company likely wouldn't have gotten to the $100M valuation. Sure, if you can get a company to a $1B exit without raising any funding and avoiding any dilution, that is the best case. But, in reality most companies need to raise capital to grow. You accept dilution because the value of your shares should go up assuming the company is executing well and putting the capital to go use (i.e. increasing the company value).
If the value of your stake goes down, you shouldn't just blame dilution. You should blame the company for performing poorly.
Right, but consider if OP's other option was a Google/Amazon/Apple with total compensation at $250k a year.
They could have worked in a stable environment with guaranteed $1M in compensation after 4 years, vs unstable and very demanding job with a low likelyhood of $1M total compensation over the same time horizon.
Sure, but that is a separate argument. I agree that working at Google/Amazon/Apple probably gives most people the best income over time. The point is that if you work at startups dilution is not your enemy.
Early Uber employees got diluted like crazy, but they will probably do well when they cash out (or already did in secondary offers).
I think your overall point is fair -- you own less, but of a more valuable asset now, so you should come out ahead. However, in my experience the ones that say dilution doesn't matter are often the ones that are likely to be "made whole" at dilution events or have anti-dilution protections. If you're not experiencing dilution the same way that rank-and-file employees are, I think it's a bit disingenuous to tell them that it doesn't matter.
As for its overall importance, most companies simply aren't going to be homeruns. I was at one company that passed on an acquisition offer of $X and opted to take an additional round of funding. A year later, the company sold for the same $X that it passed on. For sure, it was hoping to go much bigger than it ultimately did. But in addition to having to wait for all liquidation preferences to be settled, the employees all got to experience additional dilution for no additional gain.
It's great to shoot for the stars and everyone joining a startup hope that's the outcome. But I don't think it's out of place to also think about the median case. An early stage employee takes a lot of risk with few protections.
It's important to note dilution events because startups typically pitch their equity based on hypothetical future exit scenarios, without accounting for dilution.
It's not quite as straightforward as you're implying either. If you graph the total value of an employee's shares over time, dilution drops the value of that graph. You can say after the fact "look, after six months your total share value was higher than it started" but it doesn't change the fact that that graph has a big drop somewhere in it. If share price is constantly growing, dilution is always a bad thing for an employee. The pretense that they care about what percentage of the company is owned is specious.
The real reason employees should put up with dilution is because the share price doesn't always grow. Sometimes, the company runs out of steam and it drops to zero. They should put up with dilution because it gives the company a better chance to end up profitable and for their shares to be worth anything at a liquidity event.
> I have no idea why dilution attracts so much verbiage that's out of proportion to its mathematical importance.
Emotions.
It's the same reason why many SMB owners get caught up in the 50/50 vs 49/51 split (when there are other, better ways of resolving the voting right aspect) or squabbling over a couple of percent in an investment deal.
Logically, the differences are trivial, are likely to be diluted out anyways, and ultimately matter little compared to other factors.
Emotionally, it feels huge. It "feels" like you're giving something up. On a pizza, "50%" is better than "10%" because it's clearly more of the pizza. Same with many tangible things in life.
I want to emphasize one point. A company may offer you options, or restricted stock units, or any sort of equity in the company.
When they do this, they are asking you to invest in the company. They are asking you to buy your shares with your scarcest resource: time.
Do NOT be the slightest bit embarrassed to ask any question you want about the company's capital situation, funding prospects, premoney valuation at the last funding round, amount of "runway" left before they need revenue or another round of funding, names of major shareholders, preferred shares outstanding, etc.
Warren Buffett would ask lots of questions if they asked him to invest; so should you. Mr. Buffett probably would ask better questions, but that's OK. The company should encourage questions from YOU: they're asking YOU to invest.
If they bristle at your questions, it's a red flag. They may say, "look, that's confidential, can't answer specifically," and that's OK. But they shouldn't get annoyed.
And, remember, you can't pay your rent or buy groceries with unvested options. You need cash money for that.
At my last company they had no equity going in, and added it on Jan 1st a year later.
When I spoke to the founders about raises for the engineering team, the CTO looked at me funny.
"we just gave everyone stock options, why do they need a raise?"
Why?
Because a few of the engineers had young kids that were just starting school, and equity on a 1 year cliff won't pay those fees.
Because in Sydney there are enough start-ups that any one of the engineers could get an offer for 10-50% more base salary with options on top.
The founders were genuinely great guys, but they couldn't see the wood for the trees.
You own 1% of options and company is bought for $10m.
Your payoff?
Likely $0.
He forgot to mention preferred shares given to VC’s with liquidation preferences that likely never disclosed to new engineers.
This is what makes new engineer to sacrifice his salary for a possible liquidation even that likely either never happens or there is no money left for him after VCs took their xN ratios off the payoff.
Always ask about the preference stack. You'll rarely discover anything interesting, but if you do, it'll completely change how you value your equity grant.
"How much would the company need to sell for before my equity has value?"
Key #2 (not mentioned ANYWHERE):
"Can you guarantee that my equity will always be worth at least that in case of acquisition for the above value?"
Key #2 stated in writing (congruent with typical verbal promises of implied future wealth) will actually protect you and possibly justify your salary sacrifices.
Without Key #2 guarantees - the next round of funding will likely push your equity value out of existence.
The answer is hidden in your question: you own common stock. The investors got preferred stock. As the name implies, their stock has privileges. A common one is liquidation preference. They get their money back first, then the common shareholders get whatever is left.
For an extreme example, say the VC invested $10M for 10% of the company, and then the company doesn't manage to grow, and gets acquired for the same $10M amount. The initial VC gets the $10M back from the acquisition (they make their money back, no profit). Then there is $0 left, and the common shareholders (early employees and often founders) get nothing.
It's a contrived example, and there are many other complexities to such a deal, but you get the idea.
Let's say the company gets acquired for $20M. Is it still possible for the other 90% to make $0? Or is the preference amount exactly equal to the invested amount?
Yes, it is possible to have 1.25 or 1.5x first money out liquidity preference. I'm not sure how common that is though, but I've seem it multiple times.
Also note, you can end up with negative returns since you may have paid taxes on the options.
Typically preference = invested capital, but there are exceptions where it could be more (usually only if investors were investing in a distressed situation)
Common stock is the common case... Unless you are in a strong negotiating position, common stock is what you'll get.
A company can't easily give you preferred shares. Someone has to define what preferred includes: rights to elect someone on the board, right to oversee spending decisions from the CEO, etc... It costs money to structure preferred shares. You also can't piggy-back on a preferred class that already exists, unless the investors that "own" that class are happy to dilute their privileges with you (highly unlikely).
Common stock always exists, by definition, in a corporation. So it's easy to give it to you.
Liquidation preferences mean that some shares have rights that others don't. In a liquidity event (IPO or acquisition), the people holding the "preferred" shares get paid out first, according to the number of shares and the valuation of those shares. If all the cash and other assets from the acquisition are given out to them, then anyone else holding the less-preferred shares get nothing.
Usually, the founders and VC have the preferred shares, while someone writing unit tests at 3am does not.
>He forgot to mention preferred shares given to VC’s with liquidation preferences that likely never disclosed to new engineers.
>Usually, the founders and VC have the preferred shares, while someone writing unit tests at 3am does not.
This. I moved into a VP Eng role at a startup and had options for common stock worth about 0.7% of the company. When we were acquired, those were worth zero, though I was decently compensated by the acquiring company with cash and stock. The money I made was due to my role/position rather than my equity.
Are "liquidation preference" shares just tagged as being worth more than their actual value though? I can't reconcile how they could get paid "according to the number of shares and the valuation of those shares" and have there be nothing left over for the non-preferred stock. If the founders/VCs have any n% of a, say, $10M acquisition, that still has to leave money for everyone else, unless the total number of shares is >100%, someone has a funny idea of a $10M company being worth more than the $10M that was paid for it, or there is something else going on.
My understanding is that you're perfectly correct, however — I'm just trying to demonstrate how I don't really "get" it. I presume there's some other number involved in the "liquidation preference" that is visible to those involved that make it more than a mere n% of company calculation.
Edit: Googling this, it seems like these special investors get to recoup their investment if the company is selling for less than what they valued it at at their time of investment. (And since it seems like this generally applies to VC firms, I gotta say, this is really lame. It was a bad investment, but you know the actual employees took a lot more risk in it, and yet the VCs get a better return — albeit a loss.)
Yes, preferred shares are worth more than shares of common stock. They are valued more highly because of the liquidation preference and other rights. In a great exit, the preferred shares are typically converted to common stock and everyone wins. In a not so great exit, the preferred share rights kick in and the folks with common stock may not get paid.
If you have preferred shares, you often have a "2X liquidation preference"[1] or other multiple. This means that you are guaranteed to get at least two times your initial investment in a liquidation event, even if the value of your shares at the time is less than that amount.
This can (and often does) eat into the common stockholders' (e.g. employees) liquidation amounts.
In my experience (~ 20 years at institutional VC funds), 2x preference (or anything above 1x) is extremely rare. It comes up only when there is a distressed situation, and the investors do not believe that they will receive any money beyond their liquidation preference (i.e. other junior liquidation preferences will consume the rest of the proceeds from the sale of the company).
I saw it around the dot-com days along with a lot of other extremely dubious terms for extremely desperate founders - at least in NYC.
Agreed that more than a 1x liquidation preference these days would generally be surprising, but in a low end scenario or with a few big rounds, all it takes is a 1x to wipe out any upside for founders and employees, but if you're deemed worth it, the acquiring company can offer you a worthwhile incentive to stick around.
I don't even understand what half the words here mean and the alienation of human beings still comes through. We can offer advanced college calculus in public high schools but we can't teach basic finance. I don't think anyone but a handful of workers at my job understands any of this
Something tells me it is less about basic finance or accounting but more about private contracts between the founder team or whoever has control of the company and private investors.
Most of the employees are not given access to those terms. For example, in my last job in start-up , senior only celebrated each investment rounds but never detailed any of its terms. So, I had no idea whatsoever of the actual reward I should expect and that seems to be the norm from what I hear.
If you can program computers you can definitely understand startup finance. It sounds more complex than it really is! Unfortunately, all the jargon confuses people and they wind up getting screwed...
This is why a lot of folks from Good Technology got screwed. Valued at 1.1 billion .. sold for 425 million. Preference stack was skewed to investors + mgmt.
Let's say an original investor bought 50% of the company for 5 million dollars with a 2:1 payout.
This means that on an acquisition the original investor gets a minimum of 2x their original investment. In the case the start up is acquired for anything less than $10 million the original investor gets everything.
The thing is you don't have 1% of vested common stock.
When joining the company, you might be granted a set of options which are described as comparable to 1% of total shares, but the number is almost always effectively lower than that.
If the company does well, future funding rounds will lead to dilution of your ownership.
If the company does poorly, VC's will have liquidation preferences meaning that they get paid back first. This can easily bring your ownership down to 0%.
if the company won't share the preference stack with you, look up the total amount of capital the company has raised (or ask the question that way - that may be more likely to get an answer). In most cases, the preference stack = total capital raised.
I _think_ you mean most cases preference stack is _at least_ total capital raised... and therein lies the rub... if you have some latecomers coming in at 1.5 or 2x that drastically affects payouts.
I see this advice bandied about, and I have to assume that I've just never hit on one of those companies, or there are somehow two classes of interview candidates. Because I'm 0-3. And, when I think about it, hell no I'm not handing a cap table to some senior dev candidate. Higher up the chain, maybe, but not some NCO[0] with a fancy title.
Taken another way, when companies refuse to give you the numbers to properly evaluate the potential value of equity, then you properly value it at zero and ask that salary be bumped up. And, yes, that works and much better than asking for numbers you'll never get.
What happens if your cap table is public? I would imagine if your wooing investors, they will get to see the cap table + more even if they never invest. And VCs talk to each other, so they can probably find out if curious from other VCs. Why all the secrecy?
The problem with a public cap table is that it amounts to a public salary database. Usually companies (and employees) don't want everyone to publicly know everyone else's salary. When people do jobs you don't understand (like marketing, for the tech crowd here), or are perceived as underperforming, removing all doubt about their compensation breeds contempt.
Anyway, even buffer doesn't publish enough information as they don't publish the "preference stack". Whether by design or an oversight is hard to say. And you can't really publish it as it will lead to difficulty recruiting as candidates get soured by the prospect that investor's real equity is better than their sweat equity.
Sure, VCs talk but (speaking as a not-VC) I doubt they are going to share cap tables and such. They are busy people. If you, as a VC, care, talk to the company yourself. Even if they would share peer-to-peer, you are not a VC so you are not going to be privy to this VC-public info.
I think not revealing individual employees stocks is probably fine with most employees if the company doesn't have public salaries. You would put that in a summary 'employee stock' category in the cap table.
"difficulty recruiting as candidates get soured by the prospect that investor's real equity is better than their sweat equity."
So basically looking for useful idiots as they really realize that the startup is definitely not a good deal? They are investors after all, but investors without full disclosures.
Yup. If I can't then I'm treating the equity as $0 as I don't have a realistic view of what's happening.
Which _can_ be ok... if salary plus bonuses are high enough... then you're not betting on your horse to come in anyways, you're betting on putting your nose down and getting things done.
Not really. Two startups can have vastly different cap tables, even before the A round, if they even make it there. I have witnessed this first hand. Some have trouble raising seed money and blow 50% or more of their equity just in the seed round alone. Others are more promising, may only give up 10 or 20%...
The only valid reasons for working at a seed-stage / series A startup:
You are a founder.
They are working with a technology or in an industry that you specifically want to work with and it is very hard to work on it professionally, and doing side projects are infeasible.
You need experience and you have no other option to get experience.
You are getting a significant title bump that moves your career forwards.
Invalid reasons for working at a startup:
Equity (getting rich off stock options) - this is very likely to be worthless unless you are a co-founder.
Salary - you would make (much) more at a big company.
Work life balance - you will work harder than you ever have.
Stability - does not exist.
Benefits - very bad.
Learning - they will not have any formal training nor time to train you, so be prepared to self-learn.
---
All that said, I enjoyed my time as an employee at multiple startups. Just go in for the right reasons and your eyes wide open.
I joined GitLab as #29. My work life balance has never been this good. I've been working here for ~3 years, my benefits have been excellent, I have learned so much. GitLab may be an anomaly and YMMV, but it has been the best company I've ever worked for, period. Nothing has comes close. In the end I love what I do. I don't agree with this post.
I think this is the crux of his argument. Of course there are outliers, but 90% of the time (I don't know the actual percentage, but I'd venture it's around there - if we're only talking about money I'd say 99.9%) someone will be happier if they go to a more established company.
And people are often disillusioned when their equity becomes worthless, because for years they were told that would be worth millions and they accepted low salaries because of it.
Of course sometimes it does work out great, and I'm happy that it did for you! But statistically, you are incredibly lucky.
There are a lot of assumptions in my argument, but the one with the hardest data will be how many startups succeed. Most people don't join startups thinking they'll fail (they understand it might fail, but if you knew it would fail would you still join?)
Of the high-growth tech startups we're looking at, here's an analysis pointing towards 92% failure rate - https://s3.amazonaws.com/startupcompass-public/StartupGenome... - I suspect the real number is actually much higher if we're including seed stage companies.
Beyond that though, it's mostly me piecing together anecdotal evidence of disgruntled startup employees who left for larger companies and regret not joining immediately after college. There are of course plenty of people who join for the experience, for the smaller team sizes, the autonomy, etcetera. But I think my argument is largely driven by equity. Unless you'd happily except the job offer without the equity it's pretty hard to refute that people join startups because they want equity. And that equity is almost never worth it. If you aren't a single digit employee number at a company with a 10 digit exit, and this is still assuming you didn't get fucked by dilution because of asshole investors, the math just doesn't add up.
The odds of being in that cohort is much less than 1/1000, probably closer to 1/10000. It would take me a bit of effort to find a hard number on it (looking at total number of employees at large exits, find large companies that failed, approximate number of employees at various other startups) - but I actually know people that were employee #X at a company with a 10 digit exit who didn't get screwed by investors and they still would've been better off going to Google in terms of financial compensation.
Also I think a lot of it is ignorance. Many people at startups don't realize how much better it could be at a FAANG company because they've never worked there.
34, yes, jointly supporting a family, DC, salary you can look up. I am staff frontend dev technically, unlimited time off. Can't speak to the value of my equity compensation.
I joined a series A startup years ago for none of your "valid" reasons and have never regretted it. It was a company that I already knew of and admired their product, and they had enough traction at that point to offer at least several years' worth of runway/stability ie I didn't have to worry about my job disappearing unexpectedly (at least not more so than any other California job). Work-life balance was always totally fine. I learned a ton right from the start, was able to make a big impact, and worked in the smaller "get stuff done" environment that I prefer over bureaucratic organizations.
"Bootstrapping" usually refers to funding the company (in the seed stage) without external investment, whether through pre-selling to customers, relying on founders' savings, doing consulting, etc. I think the term you're looking for is "profitable".
Not quite, since a "profitable" investor-backed company is still usually pushed by those investors to seek further investment, whether the company needs it to continue growing or not. (It just needs it to grow to the level that an investor would care about.)
The concept here is closer to "firing your investors" or "buying back your equity", but they haven't necessarily done that yet.
The flamey unsubstantive sort of comments you've posted in this thread are just what we're trying to avoid here. If you'd please review https://news.ycombinator.com/newsguidelines.html and follow the rules of the site, we'd appreciate it.
HN threads are conversation. Anecdotes are the life blood of conversation. This is an internet forum, not a peer-reviewed journal.
Noted. Thanks. I will quote you on `Anecdotes are the life blood of conversation. This is an internet forum, not a peer-reviewed journal.` in the future, if you don't mind.
valid: you do not enjoy big company politics. (you’d rather have small company politics)
valid: you want a sense of ownership and responsibility. if you don’t perform, there is a noticeable effect on the company.
valid: you want to be in an environment where others are just as committed as you to the success of the company. you want to treat your work as an endeavor, not as a means to a paycheck.
> valid: you do not enjoy big company politics. (you’d rather have small company politics)
Are there big investors? Welcome to big company politics.
> valid: you want a sense of ownership and responsibility. if you don’t perform, there is a noticeable effect on the company.
Responsibility? Sure. Ownership? Unless you're a founder or a big investor, haha, no. Unless you mean the corpo-speak "ownership," which is just another word for responsibility.
Responsibility might make the work more emotionally rewarding, but it also makes the work more stressful, so I won't sell it for free.
> valid: you want to be in an environment where others are just as committed as you to the success of the company.
They may measure the "success" in terms wildly different from you, the employee, though.
> you want to treat your work as an endeavor, not as a means to a paycheck.
Actually while I might want something more, endeavour doesn't pay rent.
I think the implicit point is that if you are NOT a cofounder those feelings of ownership are unlikely to be matched by reality. As a non-founder you do not have the input and upside of an owner.
please note that i am referring to the sense of ownership and responsibility that comes from being one of the important cogs. this is reality in a startup.
i don't mean it in a legal/financial sense, and i am not referring to any extrinsic reward, eg financial upside.
Five-year-old well-funded-and-profitable companies with 50 employees, where you as employee #50 are just there to toil away writing some dumb CRUD backoffice code—are still referred to as "start-ups."
And, in fact, since the other kind of startup dies more often than it succeeds and grows into this kind, most startups that are hiring at any given moment are this kind of startup.
Also, if you ever plan to be a founder yourself, working at a big company might not give you any useful experience at all.
Alternatively, from experience, while big company might not give you valuable experience it can give you some good people to have in your network. Even if its to ask your former company accountant for advice choosing a billing partner.
> You are getting a significant title bump that moves your career forwards.
To add to this. The title of "early member of <insert famous startup company>" holds a lot of weight in SV circles. Whether or not you legitimately helped those companies in the early days, it's a strong signal that you are valuable. And those <insert famous startup company> doesn't have to be a company that necessarily had a huge exit or has a strong economic reputation. For example - early engineer of Yahoo? Ya, people probably think you're worth one's salt.
IMHO - I think this is the main driver people join startups. It's taboo, but vanity feels much more tangible than equity.
The fraction of startups that achieve that level of name recognition is even more miniscule than the fraction of startups that achieve successful exits and let you break even financially.
Salary - you would make (much) more at a big company.
Benefits - very bad.
Both of these are valid reasons to work at a startup, if you have a family to feed and care for.
Sometimes any job is a good job, even if it's only temporary while you try to find the perfect gig.
Edit to add:
I've been in exactly this position. I took a dev job with a startup I knew was a complete loser, run by scam artists. But I had to put food on the table. Fortunately, I was only there about eight months before I landed a real job with a real company.
The dodgy company imploded, exactly as I expected it to.
You see guys working late at their little startup and maybe thing you should tell them it’s not going to happen. Because honestly for most of them it’s not.
But... I want to make the case that it's OK.
Even if it’s never happening they may be happy. If one stops viewing startups as $$$ opportunities and starts viewing them as rehab from the soulless corporate jobs full of soul-wilting mediocrity, politics, legacy, same old shit over and over, and backstabbing, then it might make a kind of sense to work at a startup instead. Take a pay cut and "try some different shit out" with a tightly-knit team.
It’s a chance to work with things that are greenfield and/or new/different/experiment. Maybe it works. It’s a chance to not be bored. You aren’t wedded to it and don’t need to do it forever. Stay up late and code for awhile. Have pizza. Debug. Try. Care.
The gotcha is if people focus on the IMGONNARICH including the management (where it translates to UNDERMARKETYOURCOMP, though maybe one doesn’t care). That’s poisonous but I think there are lots of options where this isn’t true.
The more people I talk to outside the Bay Area, the more I encounter who I think are doing it right. A lot of them are not crazy, they don’t really think IMGONNARICH. They don’t end up in the FEELINGSWILLBECRUSHED state after it doesn't work (because, honestly, it doesn't).
I like people and being around them. I love the feeling of a team pulling together and exploring the dark corners of a problem. So when a break is in order, the answer might be startup rehab. It's cheaper and better for your career than a full-on year off.
While we are talking anecdata, I can personally vouch that startups do move your career forward. However, one should be willing to take more responsibility and demonstrate leadership.
I guess this might fall under "You need experience and you have no other option to get experience.", but I ended up on the path of working for startups because
1. I never graduated from university (life came up, and I couldn't afford to keep going); but, also,
2. I don't live in the US (I'm Canadian.)
Any of the US bigcorps that want to hire programmers, expect them to get a visa and move to the US.
You know what you need, to get a work visa as a programmer coming to the US?
A college degree!
So, my employer pool was instantly limited to non-US companies. Mostly local Canadian companies. Most of those are very conservative and also expect a college degree. The only ones that aren't, are startups. So that's what I had to do.
The really annoying thing is, I ended up doing work for these Canadian startups that would netted me a $300k USD salary if I had been doing it for a US bigcorp. But, because Canadian salaries are lower, and startup salaries are lower, I was only getting ~$60k.
After years of doing that, I'm a Canadian startup founder... and still only making (i.e. paying myself) $60k.
I guess I'm an object lesson in the value of a college degree!
Actually you dont need to have college degree. I don't have high school diploma and I got L1B visa.
In case you have enough years of experience, this experience is "translatable" to years of college/degree.
There is companies that specialize in writing letters for US Visa applications in which they are go through your experience and how it translated to visa degree requirements.
My 18 years of experience were placing me somewhere between BS and MS. Letter for visa application supporting it was 6 pages long.
> Learning - they will not have any formal training nor time to train you, so be prepared to self-learn.
Disagree with this one - yes you will need to self-learn, but learning to self-learn is an invaluable tool in itself. You will learn to be extremely non-reliant on other people, and you will probably need to learn about parts of the stack you did not know about before, and fast. You might learn about project management or giving sales pitches. If you are thinking about starting your own company, you will learn a huge amount about how this happens, and what that means (I learned that I didn't want to do it for example!)
I have learned a huge deal from my startup experience, probably double the rate I was learning at the bigger company I was working at before.
Is "stability" in terms of overall job security, or day-to-day chaos?
Because I would add "chaos" to the list of negatives. The odds are likely you're going to get a C-suite or board that has ADHD-like tendencies, especially when chasing large customers and/or funding rounds.
You will continually be dropping or delaying long-term work for short-term projects to help the company achieve other goals.
At that point, it's just another job. Unless the company is clearly headed for a unicorn IPO, your tiny slice of the company is unlikely to be worth much.
30 hour weeks? Don't most people work 40 hour weeks? My first job I worked 60 hour weeks for basically 2 years straight (average, we'd work a ton of hours for a month, then work normal for a week or two, then back up to a ton of hours) and I should have started looking sooner. Instead I waited until I was burnt out and got fired. Only took me two weeks to find a newer, better job where I didn't work more than 40 per week and with a significant pay increase.
Everyone should look for a new job sooner (don’t wait for burnout, don’t wait if you’re not being promoted or seeing comp increases, don’t wait for the promise of reasonable hours). Congrats on the soft landing, sorry to hear you burned out first.
Even outside of US, 40h is standard, some places have 35 hour work week. 30 is less than 4 days a week, or 5x6h. I actually think that _might_ be more efficient _and_ healthier, but it's unusually little, I think it's a typo.
40 hours is the target. In practice, most salaried employees work around 50-60 hours a week -- more if you count checking and responding to email after work / pager duty / etc
While I'm aware some would call this a rather contrarian opinion, I truly believe that if you're in a salaried position and routinely required to work 45 or more hours a week, whether by actual mandate or "but that's just what we all do here" cultural pressure, there is something wrong with that company, more than likely starting at the top. Many companies have extraordinary crunch periods for one reason or another, and that's fine, but if you're in a crunch period more often than you aren't, that's no longer extraordinary.
I'd also ask questions to get a sense of the "soft skills" of the founders or whoever will be managing you. It's a truism, but "people quit managers, not companies."
There are tons of resources online for questions to ask, and I think the company/viability questions from the post are good, but I would add to them some of these types of questions:
Major omission: Does the business model make sense to you?
More specifically: Is there a demand for the product? Are there competitors? If not, why not -- are you sure the product is actually something that somebody wants? If there are competitors -- how will your startup compete with them? Do you trust the people running the company to guide it to success, either directly, or because they have plans to hire people who can? Is the technology feasible, or are the founders embarking on an R&D project?
There are no guarantees of course, and you can learn a lot and have fun at a startup that fails, but do your best to join with your eyes wide open.
Having worked at several start-ups, I'd say the employment risks are not worth the cost. In most of my cases, when the start-up hasn't raised enough money, you end up with a poor work environment - pissed off/stressed bosses, weird work hours, "do anything" to save the business mentality... Generally layoffs/firings occur pretty abruptly and you're left filing for unemployment without a "thank you". My advice would be to wait for a start-up to be "derisked" / 3-5 years old with a solid run rate above $100m in revenue.
The few success stories, such as Airbnb and Facebook, are the extreme exception.
I think a willingness to take on the risk is assumed by the author. Once you've made that choice, then how do you evaluate one startup vs another. (as an employee)
i think we'll look back a decade from now and realize 90% of the start-ups from 2008 to present were small businesses in disguise with MUCH MUCH smaller markets than forecasted by founders.
i think hopping to a startup and back to a big tech company is fine. i've done it for career advancements, but it was grueling.
3-5 years old with $100M revenue is deep into unicorn territory already. I'm sure you can count companies that currently fit those criteria on one hand.
Bouncing off this comment with an example from the last job I worked at (a startup).
> Do I trust the founders?
At first, I did because I was too green about small businesses. I thought the worst they could do was pay me lower wages. Oh, boy, was I wrong. Not only did I get 1099'd, but also had my hours and wages cut two months in. (The 1099 was resolved, though, thanks to the IRS's contest process.)
> Can I have healthy debate with the founders?
I found out after joining that the founders were married. So no to this one.
> Will my feedback be considered by the founders?
It was, but then promptly discarded since the founders lied about their technical skills (they knew enough to sell tech but not to build it). So everything was a game of "why can't you just drag/drop this X thing like we can in Photoshop".
> Am I compatible with the founders?
One of the founders sold me on the fact that he played guitar. But then I found out that they blasted the office with very light AM classical music for the whole day. So nope, not compatible.
> Are the founders compatible with each other?
They were married, so no.
> Are they able to work together constructively?
See the above comment.
------
Anyways, my experience is only anecdotal. But yeah, really dive into the founder's dynamics to see if you can tolerate them or not before accepting a job.
And make sure you are present when everything is sent to the copier. If the boss tells you that he/she needs you to sign two copies, don't do it. The copy you receive could be a totally different document than what you signed for the company. If the boss insists on making a copy at home, don't sign anything either. Offer to meet at a Kinkos or something to copy stuff. You want to make sure you're getting the same document out that you signed.
Or just go work for a more established company where you don't have to deal with this stuff. Because, frankly, you're not ready for a startup if you don't have the mental intuition to ask for everything in writing.
The list of questions is great but I don't think there is a way to get to this kind of information for the majority of candidates.
1) A startup with marginal success and showing growing signs can simply ignore you and your questions and move to the next candidate. Startups where all these ducks are in a row has a strong candidate pipeline and they simply move on. You run the risk of standing out not as a diligent person, but as someone who is meddling in issues beyond his/her means.
2) A startup willing to divulge all this and walk the extra distance for you is probably too raw and desperately short of talent. When you get hold of all of this information, you might feel this startup is not worth it, given you now know where the skeletons are buried.
In the end, you really kind of have to wing it. Just like the VCs, the founders and everyone else is at an early stage of an endeavor. It is a high risk game, period.
My 2c is often towards ignoring all this math and doing your best to learn more about the founders, their motivation and if they will take care of you. Good founders always find a way to compensate you for your hard work whether by financial means or by paying it forward in other ways.
One of my friends works in a startup in Berlin where he was offered equity as one of the founders (10th engender or sth like that). Chances that he will be able to liquidate them in foreseeable future is non existing.
Nobody else that I know was offered an equity, even though quite a lot of my friends work for well funded startups. I worked in some and nobody offered me anything else but a salary.
If I relocated near SF? Sure, there would be a possibility. If I was a rockstar and one of first 5 cofounders? Also yes, but I am not famous.
I am really skeptical about any such post, as I saw myself that some strategies that works in Silicon Valley do not work anywhere else and I am not into moving to the most spoiled IT region in the world.
FWIW, Germany specifically has complicated tax laws that make equity tricky. Namely: if your equity ever increases in value — e.g. if your startup raises a round of funding and gets a higher valuation — you owe capital gains taxes on the increase, even if the equity itself isn't liquid (which it might very well never be). There are workarounds, but they're a hassle. None of this is an issue in the US, where you're only taxed when you sell.
I've never been an employee of a German company, but I'm in the process of founding a startup here in Berlin. I totally get how saving early employees from having to deal with that headache would be a blessing.
(In general, the advice in the article tracks with my experience working not just with SF-based startups but companies in other top-tier tech cities like London and NYC. If you get a job at a startup in SF, you'll absolutely get equity as meaningful part of your job offer, even if you actively don't want it. A large part of startups' ability to hire depends on them being able to convince you it's okay you're being paid literally less than half of what Facebook pays because someday your 0.01-0.1% equity stake might be worth something)
> None of this is an issue in the US, where you're only taxed when you sell.
Nope. In the US, you may be taxed when you exercise, and will be taxed again (against the new basis) when you sell. Whether or not you are taxed at exercise is a very complicated matter.
Keep in mind, when you are granted stock options, you don't actually have any equity. You have an /option/ to acquire equity. The taxable events are the acquisition of that equity and the subsequent liquidation of it.
You’re totally right about options. I was thinking more explicitly about stock itself (e.g. RSUs in the case of employees at companies that issue those instead of options, or founder's stock in my personal case).
Separate from that, things are still more fraught in Germany: whatever your US taxation situation is, I'm not aware of any situation where a valuation change in stock/options/etc you're holding will trigger a taxable event for you, as I understand to be the case with Germany. As I understand equity taxation in the US, you'll only ever be taxed when events happen that you yourself have initiated (e.g. exercising options or selling stock).
Well, I know people working not only in Berlin, but also in USA, just not in SF. One blockchain startup from Utah wanted to develop some advanced stuff, got investors hyped, ICO and stuff.
They paid their employers quite well, really good rates. All of programmers (besides 2 founders I believe) are contractors - no equity. They negotiated their hourly rates pretty high, because they knew that even if it will be a great success, they won't get anything else than a salary.
I’d argue that even in NYC, people associate less value with equity compensation. But, when most of the multi-billion exits have happened in SV, isn’t this entirely justifiable?
I'd treat the specific questions here with a grain of salt but directionally the emphasis on making sure you inform yourself about the things you care about is good. I wouldn't expect that asking questions of the prospective employer is the best way to inform yourself about a lot of things though. A lot of devs for example could use some advice about options, how they work and what the tax consequences are when you receive or exercise options. Your prospective employer really can't give you this advice in any credible way - you need to seek it out independently and do your own research.
Some of the specific questions are not great depending on cultural context. For example if someone joining my dev team asked me to pay to ship their car somewhere I'd ask them why they needed a car to code. But I'm in London, where having a car has marginal/negative utility versus being essential in other places.
On the equity side, if someone asked these questions I'd know they don't understand equity. What would really help is to see the cap table so you get liquidation preferences etc but you're not going to get to see the cap table most places if you're just going for a dev job. As it is, he says you might not get told the strike price on your options, which in many/most countries your employer would be legally obliged to tell you as it's part of the valuation of your comp for tax purposes.
Equity in a startup is often used as a way to entice people to work without having to pay them market rates. If you suspect this is the case, definitely keep in mind that this equity could very well never be worth more than $0.
If you are interested in the value of the equity, then you have to be interested in the value of the business. You must understand whether you think the business value can grow. And this requires much more research and business strategy evaluation than most jobs offers.
The power dynamic: You're seeking a job and mostly at a younger/lower power position and might not be able to question the founder too much. It's the kind of soft power that the #metoo movement has talked about. Unfortunately, there are people who are ready to misuse that.
It's worse than when negotiating with a bigger company actually, cause there you're just negotiating with HR department employees who would follow the law more closely. At a large corp, you largely get what you expect.
Be very wary of what you're promised and told. I, unfortunately, was burnt by this. I largely trusted everything that I was promised/told about the company performance. But it was all hoax.
So an additional tip: Cross-check with your friends how they feel about the company. Make this effort even if you are a bit introverted and don't like discussing job offers etc with other people. Match what your research about the startup tells you with what the founders told you about the company performance. Look out for red flags.
> Cross-check with your friends how they feel about the company.
This is very important. I have a friend who took a job at a Mysterious Fintech Startup - he told our social circle in the pub and the entire table collectively groaned and encouraged him to find something more stable (red flags involved being paid pre-tax, etc).
They went bust a month later, a day after he decided jumped ship.
I like this as a great starter list. When I joined my first startup 8 years ago, I didn’t know to ask basically any of these questions. I just assumed I’d work hard and get a Lamborghini some day (only half joking).
On the fundraising side, I’d add, “What is your fundraising steategy” when talking to the founders. This massively changes potential value calculations in terms of equity. I know some founders who are focused on not raising funds and pure profitability, others who are focused on growth by any means. Part of the calculus here is that by not shooting for more fundraising rounds, the founders may be signaling that they won’t be selling anytime soon. In that case, you should look to understand what your exercise rights are for your options. Do you have to exercise within 90 days, or is there a grace period?
I'm about to agree to join a startup, but reading all the comments made me hesitate.
But I don't see a growth opportunity in a big company, the work is boring as hell and there are engineers, who joined 5 years earlier than I did, are still on same level as mine.
And the key engineering work is hold tightly by early members, unless they retire, I don't see a chance.
And I want to do robotics. Although my current company is investing in the area, they only need people with the right background, i.e. PhDs in robotics. And I have talk with google recruiters, they let me choose a position before the interview, but all my selections are as boring as my current position.
These are mostly offer stage questions. If somebody asked most of these in the opening interview I'd probably pass.
My most important preliminary questions are all trying to get to root of one issue: Does this company follow a theory x vs theory y leadership model. So many companies out there claiming to be team oriented but in actuality are top down, my way or the highway operations.
> How does the company collect feedback from customers?
I’ve read quite a few of these guides and they mostly focus on equity/benefits but I think product/market fit and feedback loops are a treasure trove for job seekers because they can show you the future as well as how focused the founder(s) are.
As a founder I’ve never been asked about feedback loops and rarely get asked about product market fit. We’re not technically a startup anymore, so that could be why. But I think those are useful questions for any company that isn’t a household name like Facebook or Apple.
What you should be looking for in an answer is whether it sounds like the company knows who it’s serving and is actively working to understand that audience even better.
Regardless of valuation, rounds of VC, or the flavor of popsicles you can find in the fridge, fit is what will ultimately get success. In my opinion/experience.
P.S. - understanding everything else is also super important for _you_, but this is important to understand to tell if there’s a future in which those would be worth anything.
> A good rule of thumb is 25% of take home pay should go towards housing and up to 40% in the Bay Area. 40% can be done if you minimize costs like going out or have a second income.
This is an interesting, and perhaps telling, assertion. 40% can be done if you minimize costs, not only in the Bay Area, but anywhere else. Thus, the implicit point here is apparently that the opportunity set in the Bay Area is so great that it's justifiable to allocate an additional 15% of pretax income just to live there, relative to anywhere else on the planet.
I'm not sure if I buy that, especially within the context of taking a job that you've already been offered that has a defined comp package vs. moving somewhere to find a new job.
I am not seeing that this document addresses the important concept of timing. That is when to ask the questions. I am not certain that (as in any negotiation) it pays to ask everything initially. It would be like going out on a date with someone and hitting them with a list of questions prior to even having the dessert. Timing is critical. For one thing depending on how well they like a candidate they might be more likely to agree to something that they initially say they can't do. Especially once they have invested enough time.
There is no clear answer for the correct time other than to not assume it's simply ok to state everything upfront (vs. time wasted on the part of the applicant).
I think it’s important to note that in many situations, money > equity.
90% of startups fail.
If you have two options, one being getting payed your preferred rate, and another being taking a huge pay cut for equity.. experience tells me to take the money every time and you’ll have made the right choice 90% of the time.
For most people money on hand today is way more important than future money that may never even materialize. And if you’re not most people, there will be future opportunities to buy into the company one way or another if you want to be an investor. You don’t even need to invest in the company you work for, there might be better investments that your real money that you get from the job can afford.
Awesome post. Definitely good timing as I was about to start an Ask HN around this as I go through the process.
I've also asked about early exercise (83(b)) and term sheets, if there are bad terms i.e. liquidation pref, anti-dilution etc but not all companies are willing to share this info.
Also, I am curious about why companies don't just have a black box formula output generator, with your equity offer value, saying this is our projection and based on our current termsheet if the company exits at this value your options are worth X, with the option of dilution built in.
>> Technically there are 23 questions but I grouped the last one together as a question for new potential teammates. Also 23 questions to ask before joining a startup didn’t have as good a ring to it.
This is great if the assumption is that the startup will be successful, however given the failure rate it feels like the focus should be on risk management. How much risk should I as a developer be willing to invest knowing that statistically things might not work out.
Additionally, it would be great if there was material like this that was much more approachable by someone early on in their career.
With regard to equity, I wouldn’t join a startup unless it’s cheap for me to buy the options. If you get your cliff, and it costs 50k to buy your options, you are sol. You options are to throw away your equity, or be stuck at a shitty job.
Whether it’s worth it “to get rich”, is kind of a bs argument. If the opportunity exists to be a founder go for it, if not take the next best possible option.
I think this is unnecessarily cynical. A third option is to keep plugging away at a great job in a great company. If at 1 year, you find yourself at a shitty job and/or shitty company, leave ... regardless of what the options cost. And who cares if they are cheap then. Shitty company = going nowhere. Any money spent exercising is money thrown away, which is even worse than walking away from it.
Your decision point around the cost of those options seems poorly thought out, besides being a victim of a false dichotomy.
There are no engineering questions on this list, and the more I think about it, the more correct I think that is. Unless you're stretching the definition of a startup, most of what passes for current engineering is volatile and subject to lots of change. Better to ask questions about the team and their experience so you know what you'll need to build.
I guess the only real valid question that you can ask in this situation is "Does anyone here currently contribute to the code?". If the answer is yes, start asking questions about the dev process. If the answer is no, then they're trying to use you for a cheap "computer person" and you should move on.
I remember a similar list of questions being posted in the past that were for any engineering position. Couldn't find the one I was looking for but this was posted a while ago and seems pretty nice: https://www.keyvalues.com/culture-queries
Here's some advice. Don't feign passion. If you could give to shits about the product wait for a better opportunity. Next. Your coworkers are competition. Treat them as such. Next. Ask for at least 20% more than you'd settle for but only after you receive an offer. Last. Don't become a JAP. You're welcome.
Questions 4 through 14 are likely not to be answered, or founders will be cagey about it. IMHO, if you get stiff-armed and you're applying to be in the first 10 employees, then run.
My general view is if you're in the first 10 or so employees for a VC-backed startup, you deserve near-founder benefits (including financial transparency).
It's not clear to me if these are intended to be startup-specific questions only.
It asks "How does the company collect feedback from customers?", which sounds like a pretty generic question, but there's nothing at all about working conditions, which I'd consider a top priority at any job.
+1 for finding out how much power individual board members have, although you may have to dig into the history of the startup, press releases, and ask rank and file staff members about recent events. The Board can easily kick out the CEO and anyone they hired without much notification.
In 2018+, it doesn't make sense to accept an offer that includes options without knowing how many are outstanding.
one late round "startup" i worked for, 300-ish employees and series F (just before I started), but still very much a startup, actually gave very, very detailed info in the option/RSU packet as part of my offer, without me having to ask for it. It included per-round valuation and dilution info, shares outstanding, other good stuff. Not liquidation prefs though. I've never seen an offer packet like that before or since.
Every startup that's offered me options or RSUs has told me (upon request) what percentage of the company that represents, or given me the total number of outstanding shares and let me do the math. They usually won't share a full cap table, but without knowing the total number of outstanding shares, the dollar value of a share is meaningless.
I'd just value the equity of any company that won't share this information at zero.
Ask that all payroll be secured for at least six months and paid through a third party. Had a founder pull all the money out in 2009 and I lost $90k in unpaid work.
"We are a private company and don't share this information."
Outside of the room, the Engineering team laughs at your questions, Operations and the CEO give each other quizzical looks before laughing too, and they go on to the next candidate.
You get smug satisfaction for not going with "THAT Company who cant answer simple questions", until a reminder about the rent payment comes in due and all you want is a 30% pay increase over your last/current role.
Anecdata, but I interviewed for a marketing role at a 10-person startup in 2013. I asked questions #1, 2, 4, 5, 6, 7, 8, 9, 12, 13, 15, 16, 17, 18, 19, and 20 - and the company was more than happy to 1) answer immediately, or 2) say "I don't know, but let me find out." I should have asked the other questions (especially the relo package!), but I was young, naive, and not tactful enough to ask tougher questions in a "cooperative" manner.
IMO it's insane to work for a company if they're evasive about the value of your equity (#4-8). That's tantamount to lying about comp. You can usually find out how much they've raised on Crunchbase, and you can napkin-math their burn by eyeballing the team (#9-13; payroll is the dominant expense for most startups). #14 seems like a weird question to ask, but YMMV.
I would take their answer to the product-market fit question with a heaping pinch of salt (what are they going to say, "no"? and PMF means something different to everyone), and listen closely to the "feedback from customers" answer.
>Outside of the room, the Engineering team laughs at your questions, Operations and the CEO give each other quizzical looks before laughing too, and they go on to the next candidate.
This is such a short sighted perspective that it's laughable.
Good management will see that the candidate is thinking about joining the team as a long-term commitment and isn't just making a job change for a pay increase over their last/current role. It shows that candidate is showing up for the same reason the company exists -- to be fairly compensated for services rendered.
A leadership team that laughs at these questions are going to lose long-term, and should be avoided by potential employees and VC alike.
I don't understand why this comment is the top one right now. Has this been people's experience? I have asked all these questions (pretty much) and have gotten almost everything answered. Answers regarding revenues where a little obfuscate or a range was given.
Some startups are reluctant to tell you how many shares are outstanding in the company (happened to my wife). They say you get 100,000 options, but will not tell you the info needed to properly estimate the potential value of those options. In my wife's case, they just said to trust them that it was a valuable offer.
Not sure how this works elsewhere, but in the UK you can find public documents submitted by companies (including private ones) on the Companies House website and find out how many shares are outstanding (as well as some basic information about current shareholders).
In the US, corporations are filed with one of the 50 states. The information that becomes public record varies by state, but you can always get the registered agent and some basic information about it (date it was created, name, etc). Sometimes that includes share counts, sometimes it doesn't. You can also generally pay a nominal fee (tens of dollars) to get an official copy of filing documents.
Some people feel cagey about saying how many have been issued (or even what stakes the investors have), but anyone that doesn’t share authorized is either confused or deceptive.
I would say though, don’t assume malice! Some people really believe that they’re supposed to keep this secret to protect their investor info or something.
The context of the probing questions proposed is that of joining a startup.
If during the interview and negotiation process, a hiring manager (probably a large equity holder) at a startup company can't give me details regarding their equity, funding, board makeup, business strategy, work environment, competitors, challenges they're facing, and how I fit in to their strategy... why would I bother working with them? There are plenty of startup companies that will give me that information in order to sell me on joining them.
If they aren't serious enough to consider each hire vital enough to put some cards on the table, then I'm not about to waste my time working for them.
Further, there are plenty of non-startup companies I can go make a big paycheck at with 9-5 hours.
> "We are a private company and don't share this information."
I'm on the management side (was CEO CircleCI, now CTO darklang) and we would absolutely answer all these questions. It's a complete red flag for any company that would recruit an employee without telling them what they're actually getting.
It's reasonable to keep the answers to Qs 4, 5, 8, 10, 11, 14 and 15 until later in the hiring process when you're close to an offer, so long as you give directionally-correct answers first.
Personally, I would answer everything except 5 in a first interview (and that's only cause I'd have to look up the exact numbers).
So true! I've interviewed with several startups (about 50-60) in the past, over the course of 5 years. I had offers from most of them, while some of them rejected me after the interviews (for whatever reasons they had). Your comment is so close to reality (based on my interactions). Some laugh, some genuinely have no clue, some act arrogant (you can either join based on whatever limited information is provided, or leave), and some say they don't share any such information.
I've worked at two startups in the past. The first startup tanked. When interviewing for the next role, I did ask these questions, but had no luck. Ended up taking an offer with 15% increase over my last role. Two years of work, and I find out that this startup too, is on its way down. Eventually ended up moving to a big company.
You must have been doing multiple interviews per month, every month, for those five years in order to get to the stage of getting an offer from a majority of the 60 companies. That sounds exhausting!
I did. Once I joined the companies that did not openly answer my questions during interviews (about finances, strike price, etc.), I ended up realizing all the negatives/problems of the companies from the inside.
Then on, I had only two choices: (1) ignore the problems and not worry about future, or (2) act fast and start interviewing until I have options if something goes wrong. I chose the second option, and hence a lot of interviewing.
I would answer all of those questions. I have, in fact, answered versions of many of them in interviews.
I've noticed candidates who have had a bad experience at a previous startup often try to find a circumspect way to ask if we're profitable and if we're going to run out of money. Those are good and fair questions that I'm happy to answer.
I'm sure some companies would demure on some of these if the answers are uncomfortable. I hope not many would laugh!
For an engineering position I suggest candidates also ask if they can review some of the code they'd be working on like a recent pull request.
It seems like you have the perception that top talent is easy to hire. In my experience that hasn't been true at big or small companies, and if a candidate is exceptional companies will go the extra mile to get them. And if we're talking about early stage startups the power dynamic is totally reversed - the senior candidate actually has a ton of negotiating power because a startup can't compete on salary with FAANG companies, and good candidates know it.
Good senior people are selective and want to know a lot about the companies they might be joining. If they didn't ask perceptive questions I'd think it was a red flag.
I mean seriously, a startup is trying to hire a senior engineer, is offering less base salary than Google, stock with an average value of nothing and they don't even want to answer the hard questions? How would they ever hire anyone good?
The only people I'd give a pass on not knowing asking good questions in an interview are interns or new grads.
Exactly this. An employee who thinks he won't get hired, if he asks questions very relevant for him, is probably a bad hire in the first place.
And for the top talent employee the startup needs, not answering the questions is a huge red flag. If you are good, you can select between so many options and most of them pay better than a startup.
Seeing this as the top comment, I expected the questions to be intrusive or silly, but I actually found them to be almost entirely the table stakes of what I'd want to know before joining a small private company that proposes to offset a lower salary offer with equity. You need these questions answered because it's a private company with no public disclosures you can look up!
I understand the cynicism behind this comment, but hopefully if you have one offer you are considering, you have a few more offers as well.
If you are worried about making rent, then perhaps your evaluation criteria would be different, such as "will this pay the bills, and will I be okay working here for the next 2 years."
This is ridiculous. The vast majority, of not all, of these questions are easily and readily answered by interviewers day in and day out. Not asking any of them is the read flag that makes people wonder if your even serious about taking the job or just there for interview practice.
This is not my experience. All of the private startups I interviewed for gave me this information when I asked during the final stage of the interview.
I think these are all reasonable questions to ask a startup with no established reputation. If all you want is a 30% increase, these startups are probably not the fit for you to begin with.
Most of the questions are appropriate to ask when an offer has been extended (but not yet accepted). There are plenty of high paying jobs at companies that can answer these questions.
It has not been my experience, coaching/advising a bunch of people through interviews with tech companies over the last few years, that most of this information is hard to get.
Assuming these questions are asked in the offer phase, I don't see a single question here that is out of line or which is even unusual. I have answered all of them myself.
If you need to worry that much about the rent payment as a software engineer in current times you either lack skill (in interviewing or on job) or sold yourself way under worth.
There's a ton of circumstances that could put even a software engineer into financial trouble. Don't assume that a software engineer automatically equals a high savings.
5 years ago this would’ve been awesome, I asked all of this to 5 employers in SF. Now in 2018 Silicon Valley we’re treated like chattle as coders/lower so I don’t see the relevance of any of these questions beyond signalling. You can be laid off at any time and for no reason or because of prejudiced liars who want you off the team. Call me jaded, I’ve been screwed at almost every startup and told simply that the pattern is me and left to die on the streets. My #1 question is how we feel about lying, followed by how much I get paid per hour (no salary, no options).
Maybe off-topic here, but: you sound very bitter, and that bitterness is no doubt understandable. I'm currently being pushed around at work by incompetent people who have lied routinely, and it stings. I'm sure the same has happened to many if not most people in the industry.
But you and I both should let go of that bitterness and even forgive the liars if we're to move on as people. I'll quote an old saying, "Holding a grudge is like drinking poison and expecting your enemy to die."
(I think it's hilarious I'm being downvoted for making a factual observation...)
It amazes me how different startup culture, and tech culture in general, is from the rest of the country.
----
Every job I've ever worked at:
Relocation expenses? hahahaha
Equity? haha we'll wave your brokerage fee to buy as our stock purchase program but if you wanna sell, you'll be paying brokerage fees.
Responsibilities? You'll do what we tell you, when we tell you, and you'll live with it. If you don't like it, you're fired. You are disposable, we do not need you, we can replace you in a matter of days with someone that'll happily shut up, sit down, and do as they're told.
---
Then of course things like bonuses. I've never had a bonus at any job I've worked at in 17 years of W2 employment. Not once. In fact, I've never even had an annual cost of living increase just a 'merit based increase' at some jobs which is almost always less than inflation.
I think the dividing line here has nothing to do with tech or startups, and merely jobs where the employee supply is short of the employer demand. Or, higher quality workers generating multiples more revenue.
It’s true that if you’re not in a role where you have the ability to massively swing revenue for a business, you’re not going to receive the same offers. However, there are tons of opportunities out there beyond tech, people just need to want to go after them.
All that being said, situations are way different for traditional blue collar jobs and I get that. I wish my mom, who does not have a college degree, had the same negotiating power that I do, but she doesn’t. So, I help her out as best I can (she’ll probably live off and on with me for the rest of her life- 20 to 30 years).
Life across the globe comes with spectrums of challenges. While not comparable to lack of potable water, knowing the right questions to ask in a startup interview is still a challenge none the less.
It's worth noting that relocation expenses don't change too much depending on experience. They generally average around $10,000 from my experience, but it isn't paid out in advance, but usually as a reimbursement. Some companies will give you a card to do it on as a means of not having to be reimbursed, but even that's rare.
Being quite senior now, I'd feel comfortable asking:
1 - To see their CI dashboard
2 - To see a sample of their production systems stdout & stderr
3 - Asking to review a recent non-trivial commit (with the person/people who wrote it)
4 - If you're interviewing remotely for an on-site position, finding out if they have an open office
5 - Finding out how they do deploys / devops