I had written a post previously on the interview question, 'Why do you want to work for us?', that was very well received and I had received some positive feedback. That prompted me to share some more insights into what goes behind making a decision when I look to hire software engineers to work for start-ups.
For the last 4+ years, I have had the opportunity to work for a company that provides engineering services to start-ups. What this means is that usually founder(s) who have the funds and an idea, seek our services to help them build out the minimum viable product. We provide a dedicated team of high-performing software engineers who can work with them to build out the product within a specified time-frame.
I have had the opportunity to work with many such start-ups in various stages over the last few years and have hired software engineers to ensure that they are able to build out products for our customers and enjoy the journey while doing so.
In this article, I have documented my learning while hiring software engineers for working with start-ups and usually how certain skills possessed by engineers work well for start-up ecosystem. Please do note that, this is in no way an exhaustive list or this is how one would/should work, but rather the article is my learning based on my experiences which I'm hoping would benefit others.
If you have ever worked with start-ups before, you would be familiar with the various stages such as pre-seed, seed, post-seed, Series A, B, C, etc.
However, for the sake of simplicity, let's go with the following definitions:
- Bootstrap - Projects executed by Start-ups in pre-seed, seed (and sometimes post-seed) will be referred to as bootstrap projects. The main distinction here is that product and engineering does not have any definition at this point. You are trying to figure everything ground up.
- Scale - Projects executed by start-ups that are in Series A & above are generally referred to as scale projects. Usually at this stage, the start-ups have active customers. They are looking to expand their engineering team internally to add more features to the product and externally to acquire more customers.
When I interview a software engineer, I usually ask a set of questions that help me determine the kind of strengths the candidate possesses that can help him/her to be successful in one of the types of projects mentioned above.
The candidate should possess the basic technical knowledge for the position that he/she has applied for. You can determine the technical skills and knowledge through the coding tests and problem solving skills.
For example, if the candidate has applied for a front-end developer position, I would expect the candidate to have a strong grasp of the fundamentals of HTML, CSS, JS and possibly a framework such as Angular, React or Vue based on the job description listing.
The candidate must be able to showcase that he/she is able to apply the knowledge he/she possesses. A good way to test this would be giving them a small requirement and asking them to build a solution for the same.
This is like an open-book test, he/she can google or find any resources online to arrive at the solution. But, the candidate must be able to explain the solution which will give you an idea about the thought process and the approach.
Before trying to find out the solution, a very good practice and often that comforts the interviewer is asking questions upfront about the requirements. This ensures that as a candidate you have a sound understanding of the problem and ensure that the requirements have been analyzed enough to arrive at a solution. There might be cases when you’ll have to make assumptions to arrive at the solution. All of these are strong indicators that the candidate possesses sound application knowledge.
In most of the real-life projects, the requirement isn't always full proof and a software engineer must have the basic intelligence to be aware of how the requirement will evolve. This is one of the most under-rated skills in Software Development in my opinion.
While this is inherently a part of every software engineer's career (not necessarily meant only for start-ups), the ability to learn on the job is a very necessary skill to have to survive in a start-up. Simply put, if you are a frond-end guy, if there's an opportunity to dig into the backend code, you should be willing to.
The software engineers who are ready to embrace change and are willing to learn things fast are very highly rated in the start-up world.
Showcasing personal projects, showcasing Github projects, etc. are all ways through which you can demonstrate your ability to learn continuously and more importantly you can learn to pick up new technologies which is very essential in the start-up world.
Behavioural questions are quite hard to assess but luckily we have a formula that can help in assessing them. The responses from the candidate are indicative of the behavioural traits possessed by the candidate.
For example, if you want to find out if the candidate has taken any initiative on his own, the question can be phrased such as "Have you done something that was not asked of you?"
Typically, a good response to a behavioural question can be framed using the STAR principle. Here, STAR stands for:
S - Situation
T - Task
A - Action
R - Result
An example answer to the above question using the STAR principle.
- Situation - In our web application, the quotation screen had a poor response time and was taking longer than 10 seconds to load.
- Task - So, I decided to check the DB queries to find out if I can optimize it further.
- Action - I did find that by adding an index on column, the response time improved to less than 5 seconds.
- Result - I showed the demo to my team lead and got an approval for a code commit. The customers noticed the change immediately and sent out an appreciation email.
Watch out for some false or partial STAR responses that usually have these catch-phrases:
- I usually.. (not specific)
- I think that.. (opinion)
- I would, would have.. (theory)
- We all did.. (no clear indication of your contribution)
Values differ from company to company, but it is essential that every employee in the company possess the same set of values to ensure that they are a reflection of the company.
Some examples of values:
- Learn Continuously - A company will hire candidates who have this value system deeply imbibed. This can be verified easily by what the candidate has done in his past to ensure his knowledge has been updated continuously.
- Customer Excellence - A service-based company must ensure that all employees are focused towards delivering outstanding customer service.
Bootstrap projects have limited resources and have enormous pressure to build the idea in a short span of time to fail-fast. Generally there's always a constant pressure to deliver the software, and the candidate must have the temperament to handle this pressure.
The reward in such kind of projects is that you get to experience creating something from ground-up and have enormous satisfaction once the idea takes shape and becomes an actual product.
This is a little hard to judge in an interview, but usually, it is good to set expectations upfront and talk to them about the rewards it entails.
In bootstrap projects, the product is at the inception stage and is beginning to take shape. That is, a product in its most basic form needs to be built out as quickly as possible to ensure the customers can test the hypothesis.
Most often the idea the founders/co-founders had in their mind might not solve the problem in hand as they had imagined once the product starts to take shape. In such cases, the product management team will decide to pivot around the idea. This process happens one or more times until the customers are convinced that the product has the potential to be successful in the market or until they run out of funds.
This will require the engineering team to possibly throw away what has been built until this point or change the underlying design to a very large extent. This can get frustrating if it happens repeatedly. In my opinion, this is the single most difficult thing for any software engineer to adapt to. The biggest take away from such an exercise is that it helps the software engineers develop a product-first mindset and become much efficient solution providers.
While the ability to adapt to change is difficult to judge in an interview setting, usually if the candidate has prior experience with working for an early stage start-up, he/she is likely to be aware of the uncertainties that accompany working with a bootstrap customer.
While this a requirement in most of the bigger companies, engineers coming from a start-up background are generally not so great on software processes. This is because there are no processes defined in an early-stage startup.
Once you have a larger team and you are looking to grow, one of the first things that needs to be established is a set of well-defined processes.
An example of a process could be as simple as ensuring that every merge to Git release branch happens only through a pull request.
Software engineers who have worked with early stage start-ups have a lot of experience building things ground-up. However, there have been a few instances when they have struggled to navigate through existing code bases.
For a project at scale, there would already be an existing code base and you wouldn't need to reinvent the wheel or be a hero at the word go. Instead, the engineer would need to invest time to understand the existing design, architecture, and coding principles that were established to build the software.
As the product features are being built rapidly a lot of technical changes required to support the underlying infrastructure of the product are captured as technical debt. A very essential skill required in this stage is to balance the act of writing code for feature development and ensure that the technical debt doesn’t pile up significantly.
This is also a difficult skill to assess in an interview. However, the software engineers who have prior experience working in large projects are likely to have gone through the above processes.
To summarize, working with start-ups needs a different mindset. Before getting into the start-up scene, I had previously worked with large enterprises for over 10+ years and it took me almost 6 months to get used to the pace and dynamic nature of work.
You are challenged continuously and it is both a rewarding experience and at the same time can be very demanding. If you get an opportunity to work with a bootstrap customer, you get to experience the end-to-end of software engineering from inception to launch. It is one of the most rewarding experiences I can think of.
From an engineering manager's perspective, the fitment is extremely important to ensure that the engineers have the right motivation to work and that in gives confidence to the founders that they have passionate set of people who are giving it all they have towards realizing their dream.
I hope I could share my experiences working with start-up and also touch up the kind of skills that are suited for start-ups at different stages. Do let me know your feedback and comments.