I know a decent number of people I would want to be my first hire, and I think they might be interested. The biggest mental hurdle for me is "How can I ensure that I can pay them every month?"
You simply need to set expectations according to the truth. If you have 6 months of their salary banked, tell them that. If you're uncertain you can pay them, tell them and hire people who are OK with that.
Agreed. Also if you are hiring employee number 1 as a startup rather than just a small business, you are looking for a business partner, essentially. If you are applying for a position like this, it's important to ask all relevant accounting questions. If you are hiring someone, it's important to provide accurate information on the cash inflow and outflow on the business.
Also, my father always taught me, "the employees get paid first." That means if it is just an employee you are hiring, the question isn't whether you can afford to pay them, it's whether there is money left over when you get done to pay yourself.
It's starting to get to the point where I have so much work that I need some help, but on the other hand I'm ok with taking the risk of eating ramen and potatoes for weeks at a time if I have to (mostly if I have trouble collecting from a client).
A lot of people have suggested contracting out work, which seems good but it has its own problems. I would rather have someone completely on board.
I have half a mind to just jump in the deep end and trust that I'll be able to swim, but having someone depend on you for income is much different than just putting your own well-being and comfort at risk.
This raises the question, is it better to hire young unmarried developers with no kids if only to clear your conscience knowing that if things go badly you aren't putting an entire families well being in jeopardy.
I'm 27, with a wife and three kids. I've been working full-time on my own startup for the past 9 months. Without salary.
See, there are plenty of us who can kick ass and raise a family at the same time. Not to mention plan and budget responsibly. In fact, you might really want to hire people who are good at that sort of thing, rather than the Red Bull-chugging, couch-sleeping, college codemonkey stereotype. But I suppose stereotyping is what got us here in the first place, and that's not fair to Red Bull aficionados.
I guess I'd just rather you let me and other prospective employees assess the risks for ourselves. That means frank discussion about clear, accurate information. But don't curtail things because of personal bias.
I understand what you are getting at and I agree but I'm not really sure it would be in your best advantage to divulge that kind of information in interviews for instance.
I think it is, but you'd need to exercise this idea discreetly, as if you make this preference known you could run into discriminatory hiring practice issues. (The sad fact is, people still discriminate - they just don't talk about it anymore.)
I am a big fan of looking at the whole person, but I wouldn't put it in stark black and white terms like that. The fact is that as we age, and go through life changes, we think in different ways and this means we bring different things to the table.
A 22-year-old hot-shot programmer brings to the table something very different than an experienced 45-year-old software developer who used to be a hot-shot programmer. The former can code circles around the latter, but the latter brings a perspective to the table which can save a lot of time, energy, and expense down the road.
I don't think I'd want a software team with an average age of 26, which looks down on or ignores the advice and feedback of more experienced programmers.
Our industry is developing in strange ways. I know a bunch of good programmers who are unable to find work because of their ages, and who then start their own businesses, and are successful there. Then, I suppose they get brought in to the people who might have otherwise hired them as "consultants!"
* Marital status is a protected class. You can't consider it when hiring.
* Age is a protected class. You can't consider it when hiring.
* Pregnancy is a proxy for sex, a protected class. You can't consider it when hiring [1].
* Parental status is a protected class, but apparently is not applicable to Employment cases [2]. So you could get away with avoiding parents in some places. But man, what a great way to violate the No Asshole rule. Frankly, I'd rather not work for a startup that would want to go down this path.
Where the heck did you hear this? This means I could open a hardware store, and a black person would come in for an interview, and I could be like "Black people need not apply"?
In the US there are a wide variety of laws at both state and federal level affecting employment discrimination, but all of the laws I am familiar with have a "small business exception". See:
On the other hand, state and local laws may add additional restrictions beyond federal laws and as I've mentioned... I am not a lawyer. And I don't condone people being dicks.
EDIT: In California, the "magic number" of employees below which you can be an open bigot is apparently five. See:
I know what you mean. Personally I can live in a much smaller apartment and I don't mind sharing a kitchen so much (unless the other guys are complete slops and never clean anything) but if I had a SO I wouldn't risk it.
Don't do it. Go with contractors. Here's the thing: a contractor is running a business, just like you are. If you don't work with them any more, they are not out of "a job." Their livelihood is no longer your responsibility. You are only responsible for paying a set amount you agreed for specific work. If they do not deliver, you do not have to fire them. If you can't afford them any more, you do not have to fire them… you simply don't renew a contract. If it turns out you don't like them, you do not have to fire them.
With contractors, you can also afford to try lots of people without disrupting anyone's lives or running out of money. You have freedom and they have other clients.
Firing people is the absolute worst, I can tell you for a fact… and I'm a person who fully embraces difficult experiences and has no problem admitting when she's wrong.
Even if you want to keep the employee (and based on what I learned & then heard from EVERYONE, the chances you'll keep your first employee are about zero), you will have a hard time sleeping at night because they depend on you and you may find your whole job becomes ensuring you earn enough to pay them. (A good rule of thumb is that you must have at minimum 150% of their salary on a monthly basis. More for non-US countries.)
People will say xyz about contractors -- they're not invested, they have other pots on the stove, blah blah blah. The same is true of employees, but they are harder and so much more painful to get rid of, and it hurts them a lot more. The trick is the right people. Finding the right contractor is absolutely possible, and it's much less stress to be wrong than it is when you are wrong about an employee.
For one, you can hire people for small getting-to-know-you projects. You're not going to find it easy to do that with an employee. Moreover, once a person is an employee, their behavior may completely change… being employed (and being an employer!) brings out all kinds of crazy psychological crap you never would have believed possible.
I am a contractor and part of a larger consulting shop so I'm biased but I have to agree with ahoyhere. You get a reliable burn rate which is adjustable on a schedule you can negotiate. If you're hiring a team of contractors you should get a group who have proven that they have an effective and efficient process for working together which they can apply from day 1 and you can probably scale the size of the team based on your needs and budget. When your needs change or you pivot and you need an expert in a new technology which I don't know I'm happy to walk away or swap places with one of my peers who may be a better fit. I'm also fortunate enough to have coworkers lining up future projects so neither you nor I need to worry about what I'm going to do if you no longer need me or just need to slow down development an focus your resources elsewhere.
I'm certainly not invested in your startup the same way an employee might be. I'm not going to work crazy hours and I'm not going to pull off long shot programmer heroics (well not unless that's what you ask for). Instead I can measure my success only by the quality of the work I produce and the value I can deliver to you immediately. Building the tools you need to validate a product-market fit or get a MVP in front of users is often my end goal, not an incremental step towards hopefully seeing a return on some equity share.
If I'm lucky I'm helping a startup build a new product every couple of months. I think that offers a breadth of experience which relatively few prospective full time hires can match.
Startups will need employees and employees invested in and committed to their long term success. So while your looking for the perfect first employee, the one who has the combination of personality, skills, passion, and mindset you need, consider if the right contractors might let you get a lot done in the mean time.
My employee #1 was not the first or the second person I hired. I tried and failed a lot in finding the right person. I even made the biggest mistake of all of using a recruiter.
What eventually worked for my company was someone straight out of college, with no previous experience, but that is smart and has the right small company culture.
This whole process was hard, but I learned a lot.I now have developers solve a small problem by writing code in a technology/language they don't master. If they know python, I give them a laptop with Visual Studio and tell them to solve the problem using .NET and C#, if they know Java and come from enterprise consulting, I give them a terminal window and python, if windows then linux, and so on. This gets them off their comfort zone and I can look for what I'm really looking: problem solving skills and being able to learn and pick up new things fast.
Another important thing is to be completely open about where your company stands: does it have money in the bank, does it have paying and happy customers, etc. I found that this scares away a lot of candidates, especially the ones coming from big companies, wanting to change their lives by working in a small company.
I'm rather surprised your interview process for developers works well for you. I can potentially see some benefit, but I look for fundamental skills outside the scope of some language.
It's not focused on programming languages or a particular technology, but on placing them outside their comfort zone (taking their hammer of their hands) and try to see how they react to it. See my reply to pbsd, that's what I'm trying to look for.
It's not just important that they pick up things fast. If you ask to do some task in Python, that would be done much faster in (say) C#, they should be able to point this out, instead of just following the recipe you gave them. Good judgment is important.
That is a hard judgment to make, unless you know both Python and C#. Any of the candidates are going to be able to do the task far quicker in the technology they already know.
Yes, agreed. What I'm trying to see is how they behave with something they're not used to, how they take on the problem. These are some of the things I try to analyze:
Do they search and read about the problem?
Are they able to implement what they just researched?
Are they looking for recipes and trying to copy and paste the code from some website?
Do they have critical thinking (what you mentioned) and propose better solutions with better tools?
Do they communicate during the problem solving stage, or are quiet, closed and isolated?
Do they ask questions? Or behave like asking questions is a sign of weakness?
I usually use the criteria of "What does this person do in their spare time?" There should be two things that they should be doing:
1. They should be coding all the time. Not just for their current job, but because they genuinely like it. They may not be able to write a red-black tree in your 5minute coding quiz, but if they are truly passionate about coding and technology they will bring a wealth of knowledge with them. More so, they will have lots of exposure to new technologies, ideas, and have good ties in the community.
2. They should be passionate about the industry you are in. I would expect half of the Spotify team to be almost deaf by now, because they are listening to music all day long -- and loving it.
It's hard to find people that will fit both, but you should at least settle for the point 1. Especially now, with public code repositories like Github, it is easy to see the quality of code that most people can churn out and how passionate they are about engineering good solutions.
Seriously, this may make for great code-monkeys but very limited software developers. There are tons of things you can do to become a better developer that don't involve actual coding. Especially if your job is already mostly coding, for god's sake spend as much time as you can doing those other things.
I'm not interested in people who can write awesome code, but couldn't finish even a small development project unless somebody else holds their hand through every step of the way.
Totally agree with 2 though. Probably even more important than 1, because a mediocre programmer with a passion for the actual business can make a great product. An awesome programmer will just make great code. I prefer the former.
You're totally right. I think when I say "coding", I don't literally mean writing code. Coding requires different facets of creation: designing, testing, etc. I think another way to say point 1, is to say that the person should be passionate about technology, which I guess is kind of like point 2, but for tech.
And of course, you want someone with some breadth of experience and interests. I would venture that a well-rounded person has a lot more to offer just because he has a larger set of tools at her disposal that can be used to solve problems.
Finding that "special" someone is always such a challenge ;-)
What do ppl think about the idea of hiring someone in their freshman/soph year in college, and grooming them, sort of like a "farm system" or minor leagues in baseball. The thinking is that the juniors/seniors probably have competitive internship offers already, and you're better off targeting people earlier. Sure they might be unreliable early on, but gradually they'll become loyal and great employees after 3-4 years.
Another option, though definitely not cheap is to find people that want to move to the USA, and give them a visa.
Like this idea and have tried it and continue to to do this at my startup. But for a startup, it can be challenging for a few reasons.
1. We're already stretched thin so we generally need folks who can contribute quickly. If the person requires lots of oversight and guidance, that can take time which is already in short supply. That said, we've had some freshmen who put seniors and even experienced hires to shame. So this is clearly person-specific. If you're hungry, humble and happy and have some basic fundamentals down, we can usually make it work.
2. We can train them up and then they go to big high paid job later. This is always a risk in any market, but an intern can learn a ton with us in a couple of years which makes them more marketable to the big boys. Of course, it is our responsibility to make them love us so much that they want to stay, but when leaving school with big student loans, parents/friends who might feel working with a known brand is better, it can be tough to turn down the big paycheck/brand name.
Despite the challenges, we continue to think the pros outweigh the cons and so will keep trying. We're probably a bit more selective than when we started, however, given some lessons we've learned along the way.
From my experience working in smaller companies just beyond the startup phase, if the person caught on quick and was able to contribute, even if their contributions had a lot of issues, that was still valuable work. Some people would, however, just get stuck and never seemed to know what to do or what was expected of them, which doesn't work well in a small group but is much more acceptable at a large corporate internship. It goes back to the author's point on who to hire, but my impression is that this is a bigger problem with students who don't have much actual work experience. Work, especially in a startup, is much different than school, where you are shooting for a fairly well-defined goal, work is doled out in carefully measured chunks, and you can often just show up and get your grade if that's your motivation. The point that struck me in this was your 3-4 year figure; I would expect someone to hit the ground running, or at least moving at a steady pace, even if they ran into a few walls along the way.
I didn't really address your question directly, many startup founders are at this same point in their lives, I would be curious to hear from people with direct experience hiring interns in the startup scene.
For what is worth: I'd move to the US, and in principle I'm not opposed to working at a startup. However, the H1-B visa says I that if I lose my job, I need to get another within 1 month or leave the country. So, while I'm not so risk-averse in the sense of being afraid to be temporarily jobless, I would avoid putting myself in such a position.
Not bad. I quite like the idea of screening applicants with essay questions however this brings two issues. First, I would be amazed if your response rate was as high as 10%, in fact I'd be shocked given the fact that the kind of people you are looking to hire probably aren't using Monster and craigslist in the first place to find work.
Second, the point is almost counterintuitive. You said yourself that the best people are already in work and probably have a stable job. Most of those simply won't bother to jump through additional hoops when all they want is to speak to an actual human about the position.
This seems fairly off. I think more likely is hiring someone you know or have heard of already, or has been referred to you, and the "interviews" wouldn't include essay questions, rather a series of drinks, coffees, meals to assess technical and personal fit. Employee #1's concern hopefully isn't ensuring that they get paid on time every month and will be willing to roll with the punches. That said paying someone late sucks.
You can't assess technical competence from coffees, only from writing code. You can't assess email communication skills from drinks, only from writing.
Like in the Matrix, you don't truly know someone until you fight them.
Certainly the right meetup over coffee would digress into laptops out battling over technical ideas and implementations or reading through some samples?
Shouldn't it be "Hiring Employee #2" instead? When starting a business, you should always pay employee #1 (yourself) even if it is a small amount at first. Many businesses fail because the founders forgot this simple yet essential step.
If it is a corporate form, then the first person you hire is likely to be either an employee if the founder is (in the sense of an officer) or not (in the sense of an officer).
if during the interview she asks how often you do performance reviews,
that means she doesn’t understand the startup culture
This is really stupid. All bosses, from a two person shop to a twenty thousand person shop, should regularly be sitting down with their employees and communicating what that person has been doing well, not doing well, what the boss wants to change, etc. You don't have to be a hidebound corporation with 100k employees to benefit from being explicit about the manager communicating feedback and from setting aside time for this to explicitly happen. Not to mention that many founders are learning how to be a manager, and often are far from clear about their expectations. Making them explicit does nothing but help the relationship. See also Rands' opinion [1], [2]. Communication doesn't just happen; it's something that is made to happen.
Justintv had similar experiences about the benefits of being really clear what a manager wants [3]. Protip: employees don't read minds. He found that this was the typical project workflow:
Vague problem definition: "Create an automated test suite for the website."
Employee defines it in some way that we didn't actually have in mind: "Create
an extensible, Selenium based framework for performing every action a user can
on the site."
Employee works on that for a while, sometimes months, without feedback: "I'm
making great progress!"
Manager checks on progress, has a "wtf" moment: "Wait, I just wanted something
that pinged five URLs and checked for 500s."
Massive micromanagement ensues: "OK, clearly you don't understand what we're
doing; I'm going to have to take over."
Massive employee disenchantment: "WTF just happened?"
Performance reviews aren't the same thing as feedback. Feedback and communication are essential; performance reviews are regimented checks that often completely fail to provide the needed feedback, because no one wants to appear to be doing a bad job when it comes time to talk salary.
For feedback to be effective is has to be mutual, constant, and constructive. Performance reviews are often none of these things.
performance reviews are regimented checks that often completely fail to provide the needed feedback, because no one wants to appear to be doing a bad job when it comes time to talk salary.
There are enough companies decoupling performance and salary reviews (e.g. 6mos apart) that there are already well-established techniques for dealing with the problem you mention. Beyond that, my experience is that companies bad at communicating by means of performance reviews (i.e. they're late/irregular, or not substantive, or tied to salary) are bad at communicating in general, and inquiring about performance reviews can be seen as a leading indicator in an interview about how communicative about important stuff they are in general. Don't mistake loud offices/people with opinions about the business to be the same as managerial communication.
