Hacker News new | comments | ask | show | jobs | submit login
Questions to Ask Before Joining a Startup (hharnisc.github.io)
777 points by hharnisch 56 days ago | hide | past | web | favorite | 329 comments

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

5 - Finding out how they do deploys / devops

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...

If your CI breaks every time you change the build you are doing something wrong.

It usually happens when tests are not fixed.

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".

Not everyone's app is a web page.

WiX is a nightmare from which I am feverishly trying to awake...

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.

Pardon me, but this reminds me of https://www.monkeyuser.com/2018/workaround/

>> numerous things that increase velocity for a large team, but decrease it when the product is just getting started.

Irrespective of the team size, if the speed of delivery has to grow, a decent CI/CD helps make it faster, IMO.

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.

> circle back around and do it the way the big boys do.

Things that never happen.

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.

This is very true.

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.

If we agree that CI is nice, and it's essentially free, then why not have it?

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.

What use is it if it is too dangerous|volatile to use?

> Talent, not time, is the enemy of quality.

What a refreshingly interesting perspective!

How did you come upon this?

Anyone care to disagree?

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.


As I always say, "If you are building a startup, over-engineering is a far bigger sin than creating technical debt."

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.

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.

If you are writing a web app maybe, if you’re writing a VR app, it’s definitely not that easy.

True to that. Software engineering isn’t just web apps.

That's just a cop out! Such a tired meme!

It's true though. What's your counterargument?

Tired memes can be tired because they're true.

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.

> middle ground exists here

The point is the middle ground exists closer to shitshow than well-oiled shop. If the CEO doesn't understand this, they won't be CEO for long.

Isn't over-engineering a type of technical debt? At the very least both can exist simultaneously.

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.

Yeah, that’s pretty easy for a web App. Things aren’t that simple for companies with more complex stack, like embedded systems for example.

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.

Then leadership isn't capable.

I wonder if it's simply the balls to tell top management that we need to invest in training, refactoring etc. And selling it that it will payoff.

The usual answer I get when I propose this, is that "we're too busy with projects".

"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.

Automated deploys aren't a magic bullet and can still break production, even at a big megacorp with tons of infra and tests to keep prod safe.

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'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.

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.

In scenario of:

- If you get the money and opportunity to hire really senior/well known dev to lead your eng. team, would yo do it

- Ummm no, we believe in our team, and their strong knowledge, there is no problem they cannot solve (or something along those lines)


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.

Exactly, thanks for clarifying.

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.

I've found the 12-item Joel Test to be great.


PS: Yes! Shockingly not all startups use source control.

Re: source control, this was also written in the year 2000...

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)

open office plans are so terrible. I am job #3 now with them. Thank god for Bose QC35's but still its so unproductive

Some of these are actually good points because as a software engineer I pride myself in thinks like code documentation, comments, logging, etc.

Another idea would be to see their event and analytics dashboard for their infrastructure KPIs.

If they don't have one it's a bit of a red flag.

This is almost like meeting your future team-mates. After all they too have to cope with this day to day. So this paints some practical context.

Would you always avoid an open office ?

>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.

only financially, which isn't one of the reasons you should work for a startup!

I think getting paid (preferably well) is always one of the reasons why people work for any company, including startups.

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.

[1] https://www.holloway.com/g/equity-compensation#_there_are_no...

> $80k

Oh, wow! Worked three years of 80 hour weeks and here's 80K.

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.

Could you also add two lines: 0.008% of a $100 million company and 0.025% of a $1 billion company?

When you join early stage start-up you know only how much %% of a company is offered to you at the moment, not the future exit value.

>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.

Real talk: most companies aren't gonna exit for $1B.

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.

This is far more likely scenario.

To counter this perspective, usually founders take FAR less salary if at all.

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).

> should gross me $1M (house money).

That's more than my FIRE number haha, real estate in the Bay Area is so silly.

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.

You are correct in theory. However, as the shares are not publicly traded share_price is very likely a bs number.

> I have no idea why dilution attracts so much verbiage that's out of proportion to its mathematical importance.


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.

Because that split is the difference between control

preference is, on the other hand, extremely important.

This is good stuff.

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.

> And, remember, you can't pay your rent or buy groceries with unvested options. You need cash money for that.

You can't pay your rent or buy groceries with vested options either.

You can leverage it in salary negations i.e. I have options on xxxx £1 shares of a private company which would only sell out at say 30x 40x.

Then again the UK is saner when it comes to employee shares - and I am lucky that I have EMI options - which are taxed at 10% CGT and 0 income tax.

I agree wholeheartedly with your last point.

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?"


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.

Option piece is misleading.

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.


This is the Key #1:

"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.

great link

Can you elaborate on why your payoff is $0 if you have 1% vested common stock in the company?

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.

SEE: https://www.nytimes.com/2015/12/27/technology/when-a-unicorn...

Typically preference = invested capital, but there are exceptions where it could be more (usually only if investors were investing in a distressed situation)

Can't you ask for preferred stock instead of common? Isn't it a common case?

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.

It is definitely not common to get preferred stock as an employee

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.

Founders don't typically get preferred shares. If employees are wiped out in an acquisition, the founders likely are too.

Of course, the acquiring company can always opt to pay large signing/retention bonuses to founders if the acquirer believes they're valuable.

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.

1. https://www.businessinsider.com/how-liquidation-preferences-...

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...

Charles Yu wrote a really great article about it here: https://medium.com/@CharlesYu/the-ultimate-guide-to-liquidat...

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 you have to pay $10 a share and the shares are worth $10 each, your payoff per share is $0.

Good call. I was going to suggest they should be able to see: * preference stack * strike price * last valuation with board/investors

If you can't get those, then unless the equity is just butter to you, walk .. as you don't really know what the comp looks like.

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.

so are you saying you’ve ever been able to get those numbers? i never have.

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.

[0] https://en.wikipedia.org/wiki/Non-commissioned_officer

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?

I've only ever heard of one company with a public cap table. After a bit of googling, I found them again: https://open.buffer.com/buffer-open-equity-formula/ . EDIT: lol the same link is in TFA.

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.

> Usually companies (and employees) don't want everyone to publicly know everyone else's salary.

Actually, employees would love to know everyone else's salaries. This gives them a stronger negotiating position.

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.

I have... but you have to be within the first 10 employees or so.

well, within the first 10 employees you are coming in just before or just after series A. You can just assume what the stack looks like.

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 answer to every question on this list:

"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.

I'm sorry to hear about your experience.

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.

Edit: grammarz

Unfortunately, they aren’t avoided by VC’s, which means that as a potential employee you quite often run into them.

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.

> In my wife's case, they just said to trust them that it was a valuable offer.

Wow, that's rich! You trust us, but we can't trust you. That dissonance pretty much makes it an auto-fail.

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).

Delaware - where most of these startups are incorporated - does have a way for employee-investors to get this information

Except you have to be an employee share or options holder already

And you have to sue for it (or launch an administrative proceeding)


Not a thing in the US for private companies.

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.

I don't think it would be a stretch to think the ones that can answer most of these would be the outliers that make it past two years.

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.

The company doesn't have to answer every question but it would be a huge red flag if the company could not answer any of them.

and your lack of higher salary history will be a huge red flag to your rental, credit, auto, mortgage, and accredited investor application

Joining a startup is not how you get a higher salary. For many, it’s a pay cut.

nit: there's no such thing as an accredited investor application.

Some issuers need more robust information than a self certification

Getting this information is done in the form of an application

I don’t understand what you’re (sarcastically) trying to get at here. That if you ask questions you can’t get a reasonably high salary?

oh it means that you won't get hired

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.

So if you ask questions about the company, you won't get hired?


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.

I assume high pay. Personal financial troubles don't really put you in a negative negotiation position with an abundance of job options.

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:

How you will be managed/evaluated and the mission of the company: https://www.themuse.com/advice/8-questions-most-people-dont-...

How your founder/manager will navigate conflict, which is inevitable: https://www.thebalancecareers.com/interview-questions-to-ass...

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.

> GitLab may be an anomaly and YMMV

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.

Do you have links to any data that shows the statistics on my luck?

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.

would you mind sharing how much equity was granted at gitlab ?

How old are you? Are you supporting a family? Where do you live?

What's the amount of your salary? What's the value of your equity compensation? How much time do you get off?

(your benefits may not be as good as you think)

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.

That is nominally a series A startup, but actually a bootstrapped since series A startup. Big difference.

"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.

If you've got board control after the Series A and are profitable, they have zero leverage over your future decisions.


Subjective meets subjective. It's the appropriate context. I hope it helps college grads make an informed decision that's right for them.

So do you have some kinda data breakdown on the typical startup, or just other anecdotal experience?


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.

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.

> this is reality in a startup

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.

The context in this sub-thread is specifically seed or series A startups.

> 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.

> You need experience and you have no other option to get experience.

I don't know how else to get the kind of experience you get at a startup. A big company will give you depth, but a startup will give you breadth.

Also, if you ever plan to be a founder yourself, working at a big company might not give you any useful experience at all.

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.

Better to be a contractor at large companies and move around. Then you get the depth, plus you can change role when you stop learning.

> 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.

100% agree - which is part of my point...it's a very irrational view that more often than not doesn't net a high return.

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.

Well, sure, but those are not specific reasons to take a job in a startup, which the comment was about, those are reasons to take any job.

>You are getting a significant title bump that moves your career forwards.

The title bump rarely moves your career forwards.

You would be surprised. Added responsibility can help you understand things from next level perspective.

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.

Do I like going to work every day? Do I like my coworkers and the kind of work I'm doing?

These questions have always guided me well.

I'd add one more to the "valid reasons": rehab

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.

I'm currently deciding whether or not to go with a startup for the first time and this post really resonated with me. Thanks!

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.

> I guess I'm an object lesson in the value of a college degree!

As well as the really innefective way we judge talent in the US

pretty sure college degrees are beneficial to getting a visa/work permit in other countries, like Canada or China.

> 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.

Stability is bad yes, but work life balance can definitely be good in a start-up.

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.

I agree with you, though I'd say that this may not apply fully to late-stage startups in Series C or Series D.

This is more seed / A stage. Once solid revenues are established it's a different game. I edited the original comment to reflect this.

> late-stage

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.

> You need experience and you have no other option to get experience.

This was me and I paid for it. Right now I'm on week 8 of 30 hour weeks. It sucks.

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.

I learned some very valuable lessons at least!

I thought standard work weeks were 40 hours (at least in the US)? Are your work weeks normally shorter?

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.

in the UK 37.5 after accounting for lunch is common at BT it was 36 hours a week on average (not counting lunch).

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 don't think that is true in general. Heavily depends on the employer, industry and country. Also unions play a big part in worktime.

> 30 hour weeks. It sucks.

Sounds terrible

30 hour weeks — Do you mean in addition to a regular full-time job?

Do you mean you're being worked too hard or not hard enough?

omg 30 hour weeks sounds perfect


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact