Hiring Employee #1
blog.asmartbear.com
blog.asmartbear.com
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.
Humans are such silly creatures...
That sounds awfully ridiculous.
http://en.wikipedia.org/wiki/Employment_discrimination_law_i...
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:
http://ag.ca.gov/publications/civilrights/01CRhandbook/chapt...
* 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.
[1] http://users.aristotle.net/~hantley/hiedlegl/statutes/title7... [2] http://www.seattle.gov/civilrights/discrimination.htm
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!"
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.
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.
So, yeah. Don't do it!
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.
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.
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.
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?
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.
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 ;-)
Another option, though definitely not cheap is to find people that want to move to the USA, and give them a visa.
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.
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.
Shameless Plug: I've written a pretty extensive post recently on making your start-up more appealing to potential hires which works nicely with your post: http://voltsteve.blogspot.com/2011/10/why-should-i-join-your...
Like in the Matrix, you don't truly know someone until you fight them.
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
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?"
[2] http://www.randsinrepose.com/archives/2009/08/31/no_surprise...
[3] http://www.businessinsider.com/three-signs-you-have-a-manage...
For feedback to be effective is has to be mutual, constant, and constructive. Performance reviews are often none of these things.
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.