Are You a Good Fit for Working in a Startup? Ask Yourself These 5 Questions
Before applying for a startup job, make sure to ask youself these questions.
Working for a startup is not for everybody.
A startup is a new company, usually of the age of 3 years or less. It is like a baby company and still needs to explore and understand the world. This implies both good and bad things.
Before applying for a job at a startup, it is essential to understand whether you would be happy working there.
Here are five things you can ask yourself to decide whether you are a good fit for the startup world.
1. Are you comfortable with experimentation?
A startup is an experiment.
The entire company is based on an idea that might or might not work. Most startups are just ideas that some people (the founders) decide to transform into a product. So, after a while, these people might end up with something working.
If this thing sounds promising, someone else might give these people money to keep working on the product.
From this moment on, everything is a series of experiments to understand how to make the company successful. Who is the target user for the product? What are the following features to develop? What is the best market to start with?
There will be failures.
During the startup’s life, it is perfectly normal to experience failures. A feature your team considers essential is not precisely what the customers want. After a while, founders might realize the market they wanted to start with is not ideal for their product.
I’m oversimplifying, but the concept is valid.
Are you comfortable in an ever-changing environment? Do you like experimentation? Or maybe you prefer working with a well-established product?
2. Do you like working with legacy code?
The first goal of a startup founder is to validate the idea.
When a founder wants to validate their idea, they must do it fast. The goal is to create something clients can start using. The result could be a codebase that is not so well structured.
Even if the codebase is small, it might be very messy.
While we are used to seeing a Big Ball of Mud, you could find a Small Ball of Mud in a startup. While a Big Ball of Mud results from many changes over several years, a Small Ball of Mud is created in a few years, rushing to reach a specific goal.
The reason behind the Small Ball of Mud is not necessarily a lack of competence.
It is possible that if the founders are not so experienced engineers, they could fall into familiar code smells and anti-patterns. But this is not the rule. Sometimes, even seasoned developers might fall into the rush of creating a working product and starting to sell it.
If you spend years creating a product no one wants to buy, you waste your time.
When joining a startup, your main job could be documenting and testing existing code. Do you enjoy diving into a messy codebase to understand it? Do you like writing tests?
You might need to create standards for the company, so do you like researching to find best practices?
3. Are you okay with giving feedback to your boss?
You should always give feedback to your boss, but it’s crucial in a startup.
When you work in a startup, there is a high chance that some people, especially the founders, are not experienced in their roles. People don’t create new companies every day. So, people building a startup might have zero experience as executives.
Feedback is a crucial tool to improve.
You shouldn’t wait weeks to speak to your CEO while working in a startup. The C-level schedule is not so full when the company has 20 employees or fewer. The feedback loop in a startup is very short compared to a big company.
Being proactive in giving feedback can make a huge difference.
If you have questions or feedback, message your boss and ask them to schedule some time to talk. This is also valid for everyone working in the company. Take time to speak to everyone.
A startup might not have a manager separating you from your CTO.
Can you be proactive and reach out to your CTO or CEO?
4. Can you work with no defined roles?
Having clear roles is unnecessary in a company with 6 or 7 engineers.
It is expected to find startups with a flat hierarchy. This is not a bad thing, and it makes things smoother. Maybe one team lead, and the other engineers are on the same level.
Working in a startup means you can’t see your career path immediately.
Your career path might not be defined if you work in a company with fewer than ten engineers. This doesn’t mean you won’t have one, but you might need to wait a year for the company to start structuring it.
Not having a strict hierarchy can help you grow faster.
When you work in a team with few engineers, it is expected to work in all the parts of the codebase. There are no clear boundaries yet since there is just one team. You don’t need to ask permission to change the code owned by another team because there is no “other team.” Working on the entire codebase can help you quickly get an overview of the product.
That is your chance to learn everything from the domain to the deployment.
Are you comfortable working with no strict hierarchy? Or do you need structure? Is it okay to wait one or two years before understanding your career path?
5. Can you be a product engineer?
When you work in a startup, you can’t only write code.
Again, this should be true everywhere, but it is crucial for a startup. When you work in a startup, you must use your expertise to build a better product. This doesn’t mean you must write good code; you must also question product decisions.
You must help create a better product by understanding how users use it.
Ensure you understand the problem you are trying to solve for the users. As an engineer, you must provide technical context when solving a problem. You must be proactive and question the proposed solutions.
To be an effective product engineer, you must know your product.
When your entire company counts 20 people, ensure you know everybody. Speak to people and understand what they do in their daily job. You must understand how users use the product.
Do you like researching to understand competitors’ products? Do you enjoy finding and discussing different solutions to solve user pain?