I'm curious, what questions do you think are the most important before you accept a job offer from a startup? I'm curious, how do you know when to join or not to join a startup?
How would you know if their stated runway is realistic? What I mean, I feel that startup is gonna try to get you no matter what (in some cases), so how do you know if they are telling truth or not?
They should be able to answer in a fair amount of detail what their runway looks like (i.e. cash in the bank, burn rate, projected hiring figures, etc.)
Of course, you can never know for sure if someone is telling the truth or not, but they way they defend their answer says a lot in my opinion. People who tend to lie usually don't like getting into the numbers, and people who are honest about runway tend to pay pretty close attention to them.
I didn't ask this when I joined my current company, but have since learned my lesson. For future offers I will be sure to ask about the outside work project policy and pass if I feel it is overly restrictive.
I also recommend you consult a lawyer on this. I did on a recent one that seemed overly restrictive, but it turns out they did it poorly so I was told I could do what I wanted and they could try to fight it but they would lose, and that would only be it they found out and cared. Since my side company I've had for years isn't related, I took the job and risk. Also keep in mind non-compete are often extremely difficult to enforce as we'll, another thing people sometimes get hung up on.
>> Also keep in mind non-compete are often extremely difficult to enforce as we'll, another thing people sometimes get hung up on.
haha right... a colleague of mine just was sued for attempting to join a company considered a competitor...we all had to sign NDAs that prohibit working for a number of companies in our field after we live current employer..
If company wants and there is an NDA/non-compete in place they can bury you in legal costs even if they dont win.
Be careful with highly restrictive NDA/non-competes.
It isn't really about how enforceable it is for me personally. Sure a strict policy may not be enforceable in the sense that they can't straight out fire me or sue me with a chance of winning. But at worst a company can still pile on stress and legal fees trying and at best it can just ruin my relationship with my employer. That still sucks, and isn't really a position I'd be interested in getting into in the first place in the future.
I would infer this to mean a foundation of informed technology choices, working code, and systems that run the code to an acceptable SLA, probably with well-thought-out logging and monitoring.
Many factors have to align for a startup to succeed, but the most important of all is that there is actually market demand for the product. You can have the best team in the world and fail because you aren't making something that someone wants to buy. Conversely, you can make a lot of mistakes and still succeed if you have a product in high demand.
So aside from all the questions you would ask about working conditions, tech stack and financial runway, think long and hard about if you truly believe that there is a market for the product that the startup is making. And likewise, would it be possible to ever make a profit delivering that product?
So many startup ideas are honestly pretty bad - they are chasing tiny markets, they are chasing non-existent markets, or they are chasing low-margin businesses and would have to take over the entire world to be profitable, etc. If you don't completely buy the idea of the company as an eventually profitable enterprise, don't join.
Finally, make sure you get something in return for the risk you are taking - either in immediate pay or real equality. It's so, so common for people to work at a startup for 3-4 years, have the startup "succeed" in the sense that it gets bought up by someone, but in the end all the employees get nominal rewards (say less than 100k) or nothing. That is not worth years of giving up a good salary at a bigger company with better benefits.
I see that's also a smart way to look at it. How do you figure out that there is a market for the product if you don't know much about the specific industry? Let's say I like sports, but I don't know much about that industry, how would I know that there is a market for it?
You don't have to be a market domain expert, and even if you were, markets shift. Sometimes there actually was demand at the pre-seed stage, and by the time series A rolled around, incumbents have entered with competing products, or tastes have changed, or a million other things.
You have to put yourself in your (potential) customer's shoes. And more than that, you need to try and judge the founders' ability to do that, to see whether they can develop product relevancy as the company (and market) matures.
In other words, emotional intelligence is a valuable asset for early-stage companies.
I want to figure out if their team is strong in areas I won't be involved in. If they have crappy code at least I can fix it. But if their sales strategy sucks, I'm be stuck with the consequences without having much opportunity to improve matters.
There's not one specific question I'd ask to figure that out. Depending on how the conversation goes it might be asking about the background of the founders, or their plans for the coming months, or how they assess their threats.
I cannot stress this enough. Every single starup I worked with that has failed, has failed due to poor performance of the sales team, and/or leadership choosing the wrong path at critical points. Unless the product is highly technical, engineering mostly just needs to execute at a high level to do their part. They usually can't save or sink a company all on their own.
If your role is in engineering you may be at the mercy of failures which you have no control over. I've found those to be the most frustrating and stressful periods in my career.
Watching another department make bad choices or have poor skills/work ethic without being allowed to go in and correct it myself was very painful. Especially being in a small organization.
To be fair, this is true of all departments and all people. Sales can't be successful if engineering and product don't build a good product with product market fit.
The idea of going somewhere where the biggest blockers to success are under your control makes a lot of sense if you have confidence in your ability to execute.
That's a great point. I should probably clarify a bit.
I was really talking about how frustrating the proximity of that failure I could not control was. In a larger or more stable organization, when a different department is failing of struggling, you can at least have confidence in the future. That eventually those people will either improve or move on to something that might be more appropriate for them. Or possibly be replaced with people that are better suited for the task at hand, and things will get back on track.
When I was involved in high stress early companies, where founders and early sales employees are often unlikely to be removed, it can be a especially difficult to deal with emotionally. At some point you are forced to chose between sinking with a ship you are not permitted to save, or bail on something you've poured so much work into.
The product matters little in some cases. Marketing can succeed with vaporware. Sales can succeed without an actual working product as long as they focus on the decision maker and have vender lockin. HR, c.level execs don't need a working product just a concept.
Product development rarely provides features that can be self fueling for marketing/sales. Brands rarely need killer product features they need a targeted story.
It is much easier to have a successful company without a product than it is to have a successful company that trys to use product features as a marketing department.
It’s really important to talk directly to someone who would be considered your peer to understand the team and the day to day. Bonus points if you can speak to them privately to get candid answers.
I can't boil it down to 3 because there are many things you need to understand, some details can be gleaned via observation too.
So some of the top questions you should ask IMO are below:
- Runway left
- When was the last raise, what was the amount and time to raise it? What is the makeup of the investors (Angel vs. VC etc)?
- What is the next milestone on the fundraising side?
- What is the biggest competitive advantage/product feature the company has?
- What are the biggest issues facing product/development?
- How do you see my role helping the company?
- How can I best help the company if I come aboard?
- What is the biggest opportunity you feel the company has?
- What is the biggest risk the company faces?
- Who do I report to? -- this trips some startups up, but can highlight potential issues.
- How many employees are there today? How many do you plan to hire in the next 3, 6, 12 months? How many employees have left since founding?
- Equity and the vesting schedule details. Share class information as well. Current dilution, outstanding shares issued and reserved is nice to know too as well.
For what it is worth and this applies to any size company not just startups, you should also ask about what agreements they want you to sign and get them as early into the process as possible without being unreasonable. e.g. outside work policy, NDA, non-compete, non-solicitation, compensation, equity etc. Some of these they may not give you until you agree at least conditionally verbally, but there should be no reason you can't see them once you do. Companies that hide these until your first day make me nervous, at the same time that doesn't mean they are bad, just maybe been given bad advice or have a lack of understanding themselves.
I get that, and frankly I've worked with startups in the past that failed at a lot of these because I felt the culture and people were good even if there were lots of rough edges.
The questions just give you data, choice is still yours. But at least it will be an informed choice.
Only if you consider all of them hard requirements and failure of any of them to be a showstopper.
The _do_ all make complete sense in the context of evaluating the risk of accepting an offer, which you can then trade off against your own personal acceptable level of risk and the rewards/benefits of the things you might love about that role.
For an early-career engineer, a company with less than 12 months runway and a poorly explained share allocation, but with a friendly/compatible team with a great mentor, and the ability to make contacts and connections in the industry - might be a great choice. Probably not so good for an established mid/senior engineer with a family and a mortgage though...
A company with no clear product market fit, and poor or ordinary answers for the business-related questions, but with a smoking hot technical idea/capability - might be really fun for someone who's had a recent successful exit which means payroll not being made isn't too problematic, and a swing-for-the-fences high-risk/high-reward/high-visibility project is something that sounds exciting and rewarding (even if it plows into the ground spectacularly).
These are all great questions. However, it is important to understand why you're asking some of these questions. For example:
- Runway left and when was the last raise: are important because you'd like to know when the company will run out of cash, but more importantly perhaps is to understand whether there's a dilution hit on the horizon so you can negotiate accordingly.
- Equity and the vesting schedule details..: if a startup company doesn't answer or provide you these details when you ask, then you might want to reconsider joining them. Getting 10K or 20K options might seem like a lot, but without knowing how many shares are authorized and issued you don't know how much equity you're really getting.
Most early-stage startup employees should price the equity grant at $0. If everything works out great, it'll be a lot of money you can't do anything with about 5 years from now and often only turn into actual cash a decade or more out. In the meantime, your personal finances has to work based on the cash salary you receive, without any raises (because "raises" for a start-up are achieved through equity grants becoming more valuable).
Yes, the grant has a positive expected value. This value is too uncertain and too illiquid to significantly affect your planning, which ought to care a lot more about what the maximin strategy suggests for your course of action.
I can’t say with an absolute. But in all likelihood no. The equity portion must be spelled out in detail. There are different ways to spell it out but it has to be specific.
- Understanding the company's place in the market & how they make money
- Understanding their expectations for you -- have they thought them through?
and finally
- How well they respond to questions that they won't answer. They won't show you the cap table, but how the conversation goes is a good indicator of how well you and the future manager will be able to communicate.
They offer you any sort of stock as compensation, and are privately held and won't show you the cap table it is a polite thanks but no thanks and exit.
Any company that isn't comfortable sharing that information isn't going anywhere fast -- or they are about to go public (but you would know that already as well).
No need to be that drastic - just treat the compensation package as if the equity grant is worth $0. With the liquidity and uncertainty involved, you probably want to do that anyway, since you care a lot about "how far away am I from not having enough money" and an equity grant that pays off with a power distribution a decade out helps you very little on that front.
Regardless of what the cap table says you should treat that grant as a $0.
I have heard "we dont have one". A sign to run.
I have heard "we dont share that sort of info with staff". Major failure to understand the information I would be entitled to owning even a SINGLE share.
No speaks volumes about management, about its confidence, about it's openness. These are thing that one who is going to work for a company should be HYPER concerned with.
One thing I'd add is if they don't have clear answers to any of these questions it should be a hard pass unless it's a brand new company. It's a huge red flag if they refuse to answer, skirt the question, or can't get you an answer.
Honestly, I understand what you are saying, but early in most startups founded by younger people this just is the case.
I certainly wouldn't rule out the company if I felt the people were good people and just inexperienced as that is why they have to bring on new people.
Where it is a warning sign IMO is if they are well funded and have the money to hire experience and they still choose to not, then I still can't say an absolute no, but I'd be far more cautious and picky.
This is so helpful for those not just asking but those who will have to answer as well. Thanks.
Which questions/responses are most critical to get right and should make someone run for the exit? I imagine there has to be a little flex on some of these.
- What's the current burn rate and projected runway?
- How have you validating or going to validate product market fit?
- What sets your product and its key value proposition different from others in the market?
Assuming you are 1) excited by the people you'd be working with and 2) excited by the problem and tech stack you'd be working on, I'd want to assess:
- Does the product have traction? Are there paying customers or people who are very excited about what you are building?
- How much runway do they have? Perhaps related, if they aren't yet profitable, does the company act like they are (salaries, fancy perks, etc.)?
- Are you getting a reasonable amount of equity comp and is it structured such that you'll likely be able to benefit from future upside? Startups can change rapidly and stock options are notoriously tricky: you don't want to have to leave stock behind or stay too long at a company that you grow to dislike. This is complicated but http://stockoptioncounsel.com/blog/joining-an-early-stage-st... and http://stockoptioncounsel.com/blog/early-expiration-of-start... are good resources if you really want to dig in.
Some good questions, you won't get answers to all:
What's your runway? Are you profitable? What is your yearly revenue?
What's the biggest problem you're facing right now? What could kill you in the short-term? What's your plan for this year?
How does your Product team work with your Software Engineering team? Do you have x-functional teams? Do you do semi-regular retrospectives?
What's the background of your leadership team? Eg. has your Head of Product worked as a PM at a FAANG? What's the best thing and the worst thing about working with the CEO/CTO?
Those points aren't necessarily in disagreement. I've known a lot of people who thought they were ready for the next level or two steps up but weren't. So they went from an A+ IC somewhere solid to a C- "director" at a startup as soon as they got the chance.
(disclosure: former PM, current Head of Product, have almost certainly made this class of mistake)
It really depends on why you want to join a startup/where you are in your career. If you are young, you probably want to focus on gaining experience and build your network. If you are older, you may value financial aspects more.
Another good one: What share class are my options, and are they the same share class as the founders?
As an employee you won't have a ton of insight into things like dilution or liquidation prefs as the company raises more money. Knowing you have the same share class as founders is a good way to ensure there is someone on the board is looking out for your share class.
Agree. I'd say this question shouldn't be the one to weigh the decision.
Safer assumption: regardless of number of shares/options given or class of these - assume the value of these are $0 (unless these are RSU grants of publicly traded company).
I'd say get into the nitty-gritty of their tech if you can.
For example:
- What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
- If they do automated testing find out if it's the whole code base or just on an isolated part.
- If they have QA, are they writing automated tests or just performing manual QA?
- How long does it take to get code deployed?
- What do they think their biggest technical issue is and how do they plan to address it? In your experience, do those things line up?
- Are you personally impressed by the knowledge level of the engineers interviewing you? That's not one you can ask directly, but you can get an idea by seeing how they answer.
Understanding what their processes look like in practice and in detail, as well as why and how they make decisions, can tell you an enormous amount about the effectiveness of the organization.
I agree with most of these, except the last point here:
> What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
Certainly knowing what frameworks are used is useful, but in some fields it's ignorant to assume that an organisation doesn't know what they're doing because they use older versions of software. And asking "when are you going to update", might be the wrong question.
That said, it's a good conversation prompt from both sides. It lets the interviewee gauge if the reason is valid e.g. you build mission critical software and LTS is sensible. It also lets the interviewer gauge how strong the candidate is. Can they have a pointed discussion about software reliability or are they just looking for a cool outfit that runs the latest whizzbang libraries?
Yeah, that's a great clarification. The way I've phrased it implies that they're somehow incompetent for not immediately jumping to the newest version, which is not my intent.
I more so meant it as a way to figure out what their plans are for software lifecycle. All common languages (as far as I'm aware) deprecate old versions at some point, after which there are security implications for not updating. Asking what the long term plan is for changing versions and keeping up to date (however big of a priority that is) can provide some insights into how aware they are of technical chores that may be important but aren't feature related. I'm personally more interested in how a company thinks about their answer than what the actual answer is.
For example, I once spoke with a company that used PHP 5.5 with substantial tech debt. Their long term plan was to rewrite the whole platform as Go microservices. They didn't seem to realize that this would be a multi-year effort if it ever happened and that PHP 5.5 was already past its end of life date. The solution didn't fit the circumstances. That told me quite a bit about their engineering organization.
"If I end up not being successful at this role in 6 months, why will that have happened? What will have gone wrong and what can we do now to prevent that?"
I'm surprised this one hasn't been posted yet, because it can be a huge signal:
- Is there a plan for a liquidity event? or
- Does the company have a liquidity event target?
And some follow-ups, if so:
- What date is it planned for?
- What are the conditions the company is planning around?
It's important to know what a startup's goals are. Some exist purely for a liquidity event down the road, while others want to "change the world," etc. Taking a job with a startup that was targeting liquidity in a year or two means you have to balance your offer very carefully and understand your compensation package.
123 comments
[ 2.5 ms ] story [ 171 ms ] thread- how flexible are you guys (wfh, etc)
- ask about holiday allowance
- confirm how perks work
Of course, you can never know for sure if someone is telling the truth or not, but they way they defend their answer says a lot in my opinion. People who tend to lie usually don't like getting into the numbers, and people who are honest about runway tend to pay pretty close attention to them.
If they don't wanna show you the business data, then, that's not somewhere where you should work.
If you don't trust that they are actually using accurate data, the business will definitely fail and you shouldn't work there.
haha right... a colleague of mine just was sued for attempting to join a company considered a competitor...we all had to sign NDAs that prohibit working for a number of companies in our field after we live current employer..
If company wants and there is an NDA/non-compete in place they can bury you in legal costs even if they dont win.
Be careful with highly restrictive NDA/non-competes.
- what is my equity (potential)?
- is there already a technical platform/process to do my work, or does this need to be build first?
So aside from all the questions you would ask about working conditions, tech stack and financial runway, think long and hard about if you truly believe that there is a market for the product that the startup is making. And likewise, would it be possible to ever make a profit delivering that product?
So many startup ideas are honestly pretty bad - they are chasing tiny markets, they are chasing non-existent markets, or they are chasing low-margin businesses and would have to take over the entire world to be profitable, etc. If you don't completely buy the idea of the company as an eventually profitable enterprise, don't join.
Finally, make sure you get something in return for the risk you are taking - either in immediate pay or real equality. It's so, so common for people to work at a startup for 3-4 years, have the startup "succeed" in the sense that it gets bought up by someone, but in the end all the employees get nominal rewards (say less than 100k) or nothing. That is not worth years of giving up a good salary at a bigger company with better benefits.
You have to put yourself in your (potential) customer's shoes. And more than that, you need to try and judge the founders' ability to do that, to see whether they can develop product relevancy as the company (and market) matures.
In other words, emotional intelligence is a valuable asset for early-stage companies.
Personally, I only consider offices I can reach by bike, and try to avoid bro-culture companies.
There's not one specific question I'd ask to figure that out. Depending on how the conversation goes it might be asking about the background of the founders, or their plans for the coming months, or how they assess their threats.
If your role is in engineering you may be at the mercy of failures which you have no control over. I've found those to be the most frustrating and stressful periods in my career.
Watching another department make bad choices or have poor skills/work ethic without being allowed to go in and correct it myself was very painful. Especially being in a small organization.
The idea of going somewhere where the biggest blockers to success are under your control makes a lot of sense if you have confidence in your ability to execute.
I was really talking about how frustrating the proximity of that failure I could not control was. In a larger or more stable organization, when a different department is failing of struggling, you can at least have confidence in the future. That eventually those people will either improve or move on to something that might be more appropriate for them. Or possibly be replaced with people that are better suited for the task at hand, and things will get back on track.
When I was involved in high stress early companies, where founders and early sales employees are often unlikely to be removed, it can be a especially difficult to deal with emotionally. At some point you are forced to chose between sinking with a ship you are not permitted to save, or bail on something you've poured so much work into.
Product development rarely provides features that can be self fueling for marketing/sales. Brands rarely need killer product features they need a targeted story.
It is much easier to have a successful company without a product than it is to have a successful company that trys to use product features as a marketing department.
- How much of my IP/side projects will belong to you?
- Could you walk me through an average day for a $position? (better to talk to an actual $position if possible)
So some of the top questions you should ask IMO are below:
- Runway left
- When was the last raise, what was the amount and time to raise it? What is the makeup of the investors (Angel vs. VC etc)?
- What is the next milestone on the fundraising side?
- What is the biggest competitive advantage/product feature the company has?
- What are the biggest issues facing product/development?
- How do you see my role helping the company?
- How can I best help the company if I come aboard?
- What is the biggest opportunity you feel the company has?
- What is the biggest risk the company faces?
- Who do I report to? -- this trips some startups up, but can highlight potential issues.
- How many employees are there today? How many do you plan to hire in the next 3, 6, 12 months? How many employees have left since founding?
- Equity and the vesting schedule details. Share class information as well. Current dilution, outstanding shares issued and reserved is nice to know too as well.
For what it is worth and this applies to any size company not just startups, you should also ask about what agreements they want you to sign and get them as early into the process as possible without being unreasonable. e.g. outside work policy, NDA, non-compete, non-solicitation, compensation, equity etc. Some of these they may not give you until you agree at least conditionally verbally, but there should be no reason you can't see them once you do. Companies that hide these until your first day make me nervous, at the same time that doesn't mean they are bad, just maybe been given bad advice or have a lack of understanding themselves.
The questions just give you data, choice is still yours. But at least it will be an informed choice.
The _do_ all make complete sense in the context of evaluating the risk of accepting an offer, which you can then trade off against your own personal acceptable level of risk and the rewards/benefits of the things you might love about that role.
For an early-career engineer, a company with less than 12 months runway and a poorly explained share allocation, but with a friendly/compatible team with a great mentor, and the ability to make contacts and connections in the industry - might be a great choice. Probably not so good for an established mid/senior engineer with a family and a mortgage though...
A company with no clear product market fit, and poor or ordinary answers for the business-related questions, but with a smoking hot technical idea/capability - might be really fun for someone who's had a recent successful exit which means payroll not being made isn't too problematic, and a swing-for-the-fences high-risk/high-reward/high-visibility project is something that sounds exciting and rewarding (even if it plows into the ground spectacularly).
- Runway left and when was the last raise: are important because you'd like to know when the company will run out of cash, but more importantly perhaps is to understand whether there's a dilution hit on the horizon so you can negotiate accordingly.
- Equity and the vesting schedule details..: if a startup company doesn't answer or provide you these details when you ask, then you might want to reconsider joining them. Getting 10K or 20K options might seem like a lot, but without knowing how many shares are authorized and issued you don't know how much equity you're really getting.
Yes, the grant has a positive expected value. This value is too uncertain and too illiquid to significantly affect your planning, which ought to care a lot more about what the maximin strategy suggests for your course of action.
- Understanding the company's place in the market & how they make money
- Understanding their expectations for you -- have they thought them through?
and finally
- How well they respond to questions that they won't answer. They won't show you the cap table, but how the conversation goes is a good indicator of how well you and the future manager will be able to communicate.
They offer you any sort of stock as compensation, and are privately held and won't show you the cap table it is a polite thanks but no thanks and exit.
Any company that isn't comfortable sharing that information isn't going anywhere fast -- or they are about to go public (but you would know that already as well).
No need to be that drastic - just treat the compensation package as if the equity grant is worth $0. With the liquidity and uncertainty involved, you probably want to do that anyway, since you care a lot about "how far away am I from not having enough money" and an equity grant that pays off with a power distribution a decade out helps you very little on that front.
I have heard "we dont have one". A sign to run.
I have heard "we dont share that sort of info with staff". Major failure to understand the information I would be entitled to owning even a SINGLE share.
No speaks volumes about management, about its confidence, about it's openness. These are thing that one who is going to work for a company should be HYPER concerned with.
I certainly wouldn't rule out the company if I felt the people were good people and just inexperienced as that is why they have to bring on new people.
Where it is a warning sign IMO is if they are well funded and have the money to hire experience and they still choose to not, then I still can't say an absolute no, but I'd be far more cautious and picky.
What are good/bad answers to this question?
Which questions/responses are most critical to get right and should make someone run for the exit? I imagine there has to be a little flex on some of these.
"are you using lombok with java ?"
if the answer is yes run away because you would be working with a bunch of retards...
- Does the product have traction? Are there paying customers or people who are very excited about what you are building?
- How much runway do they have? Perhaps related, if they aren't yet profitable, does the company act like they are (salaries, fancy perks, etc.)?
- Are you getting a reasonable amount of equity comp and is it structured such that you'll likely be able to benefit from future upside? Startups can change rapidly and stock options are notoriously tricky: you don't want to have to leave stock behind or stay too long at a company that you grow to dislike. This is complicated but http://stockoptioncounsel.com/blog/joining-an-early-stage-st... and http://stockoptioncounsel.com/blog/early-expiration-of-start... are good resources if you really want to dig in.
What's your runway? Are you profitable? What is your yearly revenue?
What's the biggest problem you're facing right now? What could kill you in the short-term? What's your plan for this year?
How does your Product team work with your Software Engineering team? Do you have x-functional teams? Do you do semi-regular retrospectives?
What's the background of your leadership team? Eg. has your Head of Product worked as a PM at a FAANG? What's the best thing and the worst thing about working with the CEO/CTO?
The worst heads of product I've had could all answer yes. None of the best could.
Do you actually seek this out?
(disclosure: former PM, current Head of Product, have almost certainly made this class of mistake)
https://news.ycombinator.com/item?id=18533592
- In the main projects I'd be working on, how many new files are necessary to consume data from an outside source (say JMS) and log the result.
- What is the frequency of your releases
- How long does it take for a minor feature request to make it from initial conception to delivery to the user
These aren't actually specific to a startup largely because I haven't been burnt by a failed startup. YMMV
As an employee you won't have a ton of insight into things like dilution or liquidation prefs as the company raises more money. Knowing you have the same share class as founders is a good way to ensure there is someone on the board is looking out for your share class.
Safer assumption: regardless of number of shares/options given or class of these - assume the value of these are $0 (unless these are RSU grants of publicly traded company).
- What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
- If they do automated testing find out if it's the whole code base or just on an isolated part.
- If they have QA, are they writing automated tests or just performing manual QA?
- How long does it take to get code deployed?
- What do they think their biggest technical issue is and how do they plan to address it? In your experience, do those things line up?
- Are you personally impressed by the knowledge level of the engineers interviewing you? That's not one you can ask directly, but you can get an idea by seeing how they answer.
Understanding what their processes look like in practice and in detail, as well as why and how they make decisions, can tell you an enormous amount about the effectiveness of the organization.
> What version of the languages and frameworks are they using? If they're not current versions, why not and when do they plan to update?
Certainly knowing what frameworks are used is useful, but in some fields it's ignorant to assume that an organisation doesn't know what they're doing because they use older versions of software. And asking "when are you going to update", might be the wrong question.
That said, it's a good conversation prompt from both sides. It lets the interviewee gauge if the reason is valid e.g. you build mission critical software and LTS is sensible. It also lets the interviewer gauge how strong the candidate is. Can they have a pointed discussion about software reliability or are they just looking for a cool outfit that runs the latest whizzbang libraries?
I more so meant it as a way to figure out what their plans are for software lifecycle. All common languages (as far as I'm aware) deprecate old versions at some point, after which there are security implications for not updating. Asking what the long term plan is for changing versions and keeping up to date (however big of a priority that is) can provide some insights into how aware they are of technical chores that may be important but aren't feature related. I'm personally more interested in how a company thinks about their answer than what the actual answer is.
For example, I once spoke with a company that used PHP 5.5 with substantial tech debt. Their long term plan was to rewrite the whole platform as Go microservices. They didn't seem to realize that this would be a multi-year effort if it ever happened and that PHP 5.5 was already past its end of life date. The solution didn't fit the circumstances. That told me quite a bit about their engineering organization.
- Is there a plan for a liquidity event? or
- Does the company have a liquidity event target?
And some follow-ups, if so:
- What date is it planned for?
- What are the conditions the company is planning around?
It's important to know what a startup's goals are. Some exist purely for a liquidity event down the road, while others want to "change the world," etc. Taking a job with a startup that was targeting liquidity in a year or two means you have to balance your offer very carefully and understand your compensation package.