In my job hunt, it's incredibly common for me to run into startups that have say 3 people and then have the CTO tell me "We just closed a round of funding, so we're looking to hire 3 or 4 more programmers." Experience has taught me that more often than not, these kinds of companies are trying to solve their problems by throwing more people at them (and overestimating how much that would help). I mean, I oftentimes get the impression that too few of the people at these companies have stopped to consider the ramifications of doubling their staff. But at the same time, startups oftentimes just have a lot of problems that need solving and the sheer quantity of companies that say this is overwhelming.
When I hear startups say things like this, should I take points away from them?
When I hear startups say things like this, should I take points away from them?No, but you should start thinking. Thinking about the startup's product, market and people. And start asking further questions to get more information.
The information you're looking for as a possible new employee isn't in the "hiring fast" part. It's in the:
When I hear startups say things likeGenerally yes, although it depends. Personally I try to hire a new person after I'm happy with the last hire and his/her relationship with the team.
this, should I take points away from
If you are hiring 2-3+ programmers at a time in the middle of a project, there is a big chance that you are doing it wrong. If you are doing this to speed up in the short term or hit a deadline you definitely doing it wrong, and you should go and read a copy of Mythical Man Month.
They can have legitimate reasons but "we got money, we need to grow quick" hires are generally bad idea.
It's a problem if bottlenecks prevent you from using them effectively to complete large projects faster than you would have without them. You could have them tackle projects or address issues down the assembly line, but if that causes your startup to lose focus on clear goals, then reevaluate your decision.
"Zerg hiring" - What an apt analogy. The same is true for zerglings attacking a defensive wall in Starcraft. If the wall is too narrow (bottleneck), your zerg will fail to break through the wall and simply be picked off by marines on the other side.
Throwing people at a problem is a method as old as dirt. I've run operations in startups big and small. The bigger the company, the more likely they will be tossing some people to solve a problem. Rarely does it solve the issue. In my startup we don't hire in groups. We add one at a time. Once we have "indoctrinated" one employee in that functional area, only then do we think about hiring another one.
That said, if you like the people and you believe in the idea + execution, join them. Just make sure to value options and/or stock grants at ZERO. If monetary compensation and benefits meet what you think you are worth to this company (and what they think you are worth too) - join them. You might just get lucky.
Endemic in developer-driven startups is the attitude that says - we have some unsolved problems, so the next dev we hire can solve them. But if we keep doing what we're doing (only faster), we'll likely keep getting what we're getting (only worse).
You're right to be watching out for that. And at the same time, when things start working, this could be a sign of success.
So look at the team. What skills, expertises, contacts etc are needed, and who's covering what? Is that leaving gaps? What's being done about those?
I have a bias towards startups that tackle the commercial questions early, and build learning.
And I have a bias against startups where the founding team delay hiring into their own areas of weakness.
So I'd suggest getting the best view you can of the whole enterprise - why not ask to see the funding document that got them through that last round, so you can see how they've been pitching to investors.
In the end it will come down to some objective factors and a whole lot of subjective ones. If you're in the happy position of being able to choose between a range of opportunities, try and optimise on both axes.
I second Pierre's answer. This outfit may have plans for staffing that required funding, and they just closed a round. Who is the development team right now? Are the executives doing it until the engineering team can be built? Should the CEO and CFO/CMO/VP Marketing be coding along with the CTO that you spoke with? (It's a team of three, right?) Aren't there other duties required of them as the company grows, such that they need others to take over on the coding?
Pardon me if this hits a nerve but I spent 15 months in a 'temporary' engineering role until we closed a round of funding. That's because an investor became a no-show right after I joined ... it took a lot longer than a couple of months (how long we figured I would be on the development team) to find their replacement. That meant 15 months of development by day and doing my 'real job' evenings and weekends with whatever energy remaining, taking only one weekend per month for downtime.