Hacker News new | past | comments | ask | show | jobs | submit login
How to Hire (samaltman.com)
240 points by andygcook on Sept 23, 2013 | hide | past | favorite | 80 comments



“Experienced” people often have higher personal burn rates and sometimes you’ll need to pay them more, but remember that great companies are not usually created by experienced people (with the exception of a few roles where it really matters a lot.)

Scary statement for me to read. I'm getting older and worry that the above thinking will eventually cut off cool and even just new opportunities for me. Also hard to audition for longer periods as suggested, but I'm definitely in favor of building a strong professional network and having a good portfolio of work.


Ageism should scare you--and it should scare the author of this post. The inevitable forward progress of time means that literally every, single one of us will be on the wrong end of this equation at some point.

The (possible) saving grace is that a lot of people who came up in the 2000s tech scene are now on the "other side of 30" and becoming quite "experienced" themselves. Hopefully, that group's attitude will change these biases. Too often though, you can read between the lines and discover what they're really talking about is: "You can't convince experienced people to take less money to work obscene hours--especially when their perception is likely that much of their job will cleaning up for all the 'inexperienced' folks you hired."

The idea that "great companies are not usually created by experienced people" strikes me as exceptionally hyperbolic and based more on the publicity of Wall Street Darlings than any evidence that highly experienced people can't (or don't) build something great.

[edit: Just thought that I'd add that I agree with just about every other point made in this post and focusing on one issue generally isn't constructive so I apologize for going down the rant hole without first acknowledging that the post, overall, is quite spot on.]


On the flip side, as an old friend once said, "Do you have ten years of experience, or one year of experience ten times?"

Highly experienced people can be priceless because they have dealt with similar situations before (and it's not the technology, it's the situations). But if they didn't learn from their experiences, it doesn't help. And imho a majority of the old hands are still doing things wrong - sometimes due to management interference, sometimes due to ignorance, but mostly due to simply not making the effort to do better.

One of my own interviewing mantras is, "I don't care so much what you know how to do, as how you deal with what you don't know how to do." But honestly, this mantra taken to its logical extreme massively favors raw intelligence and flexibility over experience. That's not always a Good Thing.


I am right in the middle of this right now. In my 40s, looking for a job at the moment. My interviews have been decent to downright bizarre. The trend of the interview approach is very curious to me.

I've been looking at a variety of lead engineer/architect positions to development manager. Many of these positions come with some immediate needs, i.e. addressing large systems as part of a business expansion.

I find myself being interviewed by individual engineers asking heavy comp-sci questions, mostly in the academic sense. In several cases, during the interview, the individuals were focused on specific answers to questions that could hold several interpretations. Ambiguity is a great way to assess individuals and critical thinking, but when someone is looking for the answer...well, it doesn't necessarily pan out.

The kicker, after these meetings, is interviewing with the C-level folks who explain how their technical team can't get product out the door, and wonder how I'm going to help to that end. I've been shipping products for multiple years, in many cases longer than the individuals on the teams I'm interviewing with have been in the industry.

What's funny to me is that I'm a guy that prides myself on being current in technology. I'm not that old dude who is resistant to the latest thing -- I really enjoy seeing where the industry is going.

I'd love to get to depth on my experience -- why we built something the way we did, decisions we made, difficulties and how we addressed those -- it's like those questions are irrelevant. At the last interview, I was asked how much I enjoy playing "Dominion". I like Dominion, but really.


I understand how you feel. I went on some intensely technical interviews a few years back (late 30s). Many of the questions were the sort of thing you'd expect on an undergraduate data structures and algorithms class, though there were a few brain teasers thrown in there for good measure.

My interviewers were young, and at lunch, I tried to talk to them a bit about the business problems they were trying to solve. Their knowledge about this seemed very thin. I pressed a bit, and finally was told that this is what the "product managers" are for.

In short, I realized that they were asking me about these CS-related questions, at least in part, because this is the bubble of their work life.

One interviewer seemed unengaged in the discussion, waiting for a pause. Then he asked "how would you swap two integers without creating a third integer?" At lunch, in between two 3-4 hour blocks of technical interviews.

I'm done with these interviews. Well, ok, if my family was looking at foreclosure and going without health insurance, I'd subject myself to them again. But it is a priority of mine not do do another one of these interviews again.

It's not that I won't do a technical interview per se - there's a wide range of what counts as a technical interview, and not all of them are equally unpleasant. But I will view it as a personal...letdown if I find myself at the whiteboard showing how to add a branch to a binary tree ever again in my life. Or, to put it another way, I don't want to reload data structures and algorithms into "exam ready" memory in my own head again. I know where to find these things when I need them.

The reason I say letdown is that I most definitely do see my own personal role in this. If I fail to establish enough of a personal reputation for competence that people are asking me to do this, then that is, at least in part, my "fault". However, it does come with the territory - as far as creative fields go, software development is an area where the programmer's contributions are fairly obscured (unless they are working on open source projects).


Exceptionally well put; and good that you're aware of the shortcomings of looking too closely at dealing with the unknown. I love the succinctness of, "It's not the technology, it's the situations."

Obviously, crappy people with 10 years of experience are useless in any situation--it's just easier for them to blend in at Big Company X where they are one of a hundred. The rest of the article already applies well to how to weed those people out. Sadly, they're not always super-easy to spot.


When doing tech interviews, I always prefer to interview experienced people. I find that digging into a project that they did before was all I need to figure out if the candidate is worth going forwards with. My big red flag is when the candidates have "leading project X generating Y revenue or Z customer engagement" in their resumes, but are not able to articulate the system/product architecture, or tell me what the biggest technical challenge encountered.


"The average and median age of U.S.-born tech founders [of companies that have more than $1 million in sales, twenty or more employees, and company branches with fifty or more employees] was thirty-nine when they started their companies. Twice as many were older than fifty as were younger than twenty-five."

http://www.kauffman.org/research-and-policy/education-and-te...


"but remember that great companies are not usually created by experienced people"

What he is saying is that startup shot in the dark companies are not created by experienced people I am guessing. But then again from what I can tell the one company that the author created essentially failed. Now his job is to invest and give advice to others.

Anyone who thinks experience doesn't matter in the real world has (for lack of a more graceful way to put this) a screw lose somewhere.

I've also yet to run into anyone who has ever told me that they were better at what they did when they were younger than when they got older and had more experience. To be sure experience can also jade you and prevent you from taking chances and be a negative in some cases but that's no reason to not hire the most experience people you can. The fact is that some of the best people out there have nothing to do with the "startup" community.


That logic is silly. How about tennis and football coaches? Were they stars themselves? And the gazillion motivational book authors?

As they say, people who can't do, teach. And there's nothing wrong in teaching.


Experience itself is usually a good thing; the problem for startups comes when that experience brings with it things that cause issues with the startup--for example, much higher salary requirements.


"Experienced" employees are also more likely to need/want that cliched work-life balance. They may not want more money, but they may not be willing to work incredibly long hours indefinitely.


>"...remember that great companies are not usually created by experienced people..."

I was reading a post on quora about ageism that is quite relevant. http://www.quora.com/Silicon-Valley/What-do-people-in-Silico...

TLDR: Jimmy Wales 35 when he started wikipedia

Mark Pincus was 41 when he started Zynga

Reid Hoffman was 36 when he founded Linkedin

Marc Benioff was 35 when he started Salesforce

Robert Noyce started Intel at 41 with a 39 year old Gordon Moore

Irwin Jacobs was 52 and Andrew Viterbi was 50 when they founded Qualcomm

Pradeep Sindhu was 42 when he founded Juniper Networks

Michael Arrington started TechCrunch when he was 35

+ many more


> Also hard to audition for longer periods as suggested

He did follow that up by saying you should pay the candidate for the "audition" as a contractor. I've personally experienced this, and love it, and I advocate it strongly if not outright insist on it going forward. It's the employment equivalent of dating before marriage. And it's about Getting Real as much as you can, as early as you can.


If someone is working a full time job (the currently employed are definitely targeted in the article), and are 'experienced'/older, and thus more likely to have other demands on their time like wife/kids, contracting, even in off hours, becomes more difficult.

It won't be impossible to 'audition' but it will definitely be tougher.

(To say nothing of the intellectual property issues if the possible employee is in a related field and the employer is peeved at them leaving.)

If I was at a stable, good job, and wasn't looking, and someone was trying to poach me with the siren call of 'contract to hire' or 'work this weekend', well, it'd be an uphill battle for the poacher.

Maybe that's why I'm not in the Bay area, working for a startup :).


It'd depend on what the incentives are. If you're trying to lure a highly experienced person from a secure enterprise job to the uncertainties of a startup, what are you offering them? Money? They can make a lot more than a startup can offer by going into consulting, if they're good. Freedom? Maybe. A mission? Maybe. But you'd better have something.

For an example of other conditions... I have a friend I'd love to poach away to work for me. But he's the sole breadwinner with five young children. Besides money, I'd have to make sure I can provide good health benefits.


> Whenever possible (and it’s almost always possible), have someone do a day or two of work with you before you hire her; you can do this at night or on the weekends.

No. Absolutely not.

If a candidate really is as good as you think he/she is, they already likely has a full time job that they're perfectly happy with (as you already well know):

> Often, to get great people, you have to poach. They’re never looking for jobs, so don’t limit your recruiting to people that are looking for jobs.

They might have other compelling offers, and they'll certainly have personal projects, hobbies, and people that are more worthy of their time than this insulting little game. The developers who know what they're worth won't put up with this. Why are you trying to hire the ones who will?

Hire fast / fire fast is fine, but seeing a founder do this is a big red flag for me. It screams indecisiveness, lack of confidence, and mediocrity. Does he try to pull this stunt with everyone he hires? What am I supposed to think of the rest of the team? Can I get behind someone whose hiring process is so driven by fear that he's willing to miss out on the best candidates?

This tactic might help you hire a decent candidate over a mediocre or a terrible one, but you'll be missing out on (or even creating ill will toward) the great candidates. It's already hard enough to get them on board -- why would you make this harder on yourself?


Sorry, but speaking as a software engineer who does have a bit of talent, I disagree with you in saying that this type of audition exercise is below me. We complain and complain and complain as an industry about how the interview process that The Big Boys still use (which is essentially just a pop quiz of vocabulary terms at its core) is broken. Why is this not a better alternative?

You wouldn't pitch this as "hey, I'm still not sure about you so I'm going to ask you to do X to prove your worth" - though it seems that's the interpretation you're getting from this. It's less a question of raw skill than it is a question of how all the different subtleties that factor into effective teamwork would play out when you're working on something together. There are so many vectors that are in play when it comes to actually working with someone tells you so much more than just an interview will.


> I disagree with you in saying that this type of audition exercise is below me. > We complain [...] is broken. Why is this not a better alternative?

It's not a better alternative because many of the best developers in Silicon Valley don't disagree with me. There are many reasons for this -- not everyone is a carefree recent college grad, and many people can't afford the luxury of taking the time off to do something like this. You might argue that it's a paid trial, but often "can't afford" has more to do with family obligations, time commitments, and mental bandwidth than money, even if they'd be more than willing/able to push hard in a start-up environment if it were their full-time job. Many of the best developers aren't willing to leave their current job or take time off without the commitment of a written offer. They may be more risk averse than someone younger with fewer obligations, for many of the same reasons outlined above.

But the most important reason why this is not a better alternative is that any developer who doesn't want to put up with this doesn't have to put up with it, since it's by far not the norm. Any developer who feels this way and is actually any good would have an easy time of finding an equal or better opportunity elsewhere.

> You wouldn't pitch this as "hey, I'm still not sure about you so I'm going to ask you to do X to prove your worth" - though it seems that's the interpretation you're getting from this.

It really doesn't matter how the company tries to spin this. In the current environment, the best developers in Silicon Valley can work wherever they want. By using a paid trial as policy, these companies are (willfully or not) turning away some of the best developers that they interview, for very little gain.

tl;dr: It doesn't matter whether or not you perceive this exercise as being below you. If a large enough contingent of the best developers won't put up with it, the companies who use the exercise are losing out.


> They may be more risk averse than someone younger with fewer obligations, for many of the same reasons outlined above.

Arguably, if they're risk averse they have no business in the startup game. But that's neither here nor there.

I see where you're coming from. I guess when I read it I understood it as "Hey, let's get together for an evening an work on something - I'll even pay you with it if it's for our company" type thing, which sounds entirely reasonable. Then again, taking a PTO day to do a trial day of work has a really minimal level of risk to it.

I think there's a happy medium between where the industry is now and the line you're unhappy with crossing. Don't throw the baby out with the bathwater. :)


>Then again, taking a PTO day to do a trial day of work has a really minimal level of risk to it.

You're not going to find much support for that idea among people in demand. I'd interpret that as a huge red flag that this person does not respect my time. Also, imagine you're applying at a few different places and they all do this. Suddenly, you've wasted your vacation days on working harder without getting paid.


If you are referring to Google by "Big Boys", some of their teams are doing trial period work. My friend got hired in Google after three trial days.


Damn, three trial days?

I have done some interviewing and such of candidates at my current place. I sincerely could not imagine asking a candidate with a job to spend three trial days (or a single day) coding with us. I think it's disrespectful. Not everyone who is looking for work is unhappy where they are. I don't want to put anyone in a position where they have to choose between respecting their current employer and seeing if they're a good fit with us.


The co-working trial is a two way street. Wouldn't a good developer want to make sure the new co-workers are also good?


Hiring has always been a two way street, but in technology the scales are usually tipped against the hiring company. It's simply a numbers game -- there are far more mediocre and poor developers than good ones, and in the current environment, the good ones can basically get hired to work wherever they want.

The co-working trial is an attempt to make the scale more favorable for the company. I can understand the desire for this, but in the current environment, it's almost guaranteed to backfire, as the best developers simply won't put up with it. No amount of wishful thinking on the part of the company is going to change this.


I've worked at a few places that hire top level engineers and use this tactic. It seems to be very successful.

As a developer, why wouldn't you want to see what the codebase and your coworkers are like in a real environment - and get paid for doing it?

Worst case scenario: you wasted a day of vacation, got paid a consultant rate for it while still getting vacation pay from your "real" job.


> I can understand the desire for this, but in the current environment, it's almost guaranteed to backfire, as the best developers simply won't put up with it.

An awful lot of developers are willing to put up with inane algorithm tests.

If I was hiring, I'd be skeptical of any developer who would prefer five hours of whiteboarding to some sort of trial arrangement, or even a sufficiently complete take-home coding test that is similar in nature to the work they'd be performing as an employee.


>If I was hiring, I'd be skeptical of any developer who would prefer five hours of whiteboarding to some sort of trial arrangement,

In theory I would prefer the trial arrangement, but in practice, if I'm employed, it's not an option unless I'm totally and absolutely convinced that you run the perfect company for me.

Which you probably do not.

If I'm unemployed and searching for a job (which sometimes happens: I like to take 6 month long holidays between leaving an old job and starting a new one), then I think it's a fantastic idea. Provided it is paid.


> ...it's not an option unless I'm totally and absolutely convinced that you run the perfect company for me...Which you probably do not.

If you're employed and seeking employment elsewhere, for whatever reason, why would you even waste your time interviewing with a company that you didn't think had the potential to be a very good fit?


I wouldn't of course.

But doing 3 day long interviews means 1/4 of my holiday for the year is gone. On ONE company. Who may not even want to hire me.

3 more of those and I don't get to see a beach until 2015.


I haven't personally done a trial arrangement, but it's definitely intriguing. I absolutely loathe the 5 hour whiteboarding tests whenever I have to do them, and usually I end up fretting about it the day before and show up having not slept an iota.

Different strokes, I suppose.


>>Hire fast / fire fast is fine, but seeing a founder do this is a big red flag for me. It screams indecisiveness, lack of confidence, and mediocrity. Does he try to pull this stunt with everyone he hires? What am I supposed to think of the rest of the team? Can I get behind someone whose hiring process is so driven by fear that he's willing to miss out on the best candidates?

At the startup stage, someone who is mediocre or outright bad can cause so much damage that they can sink you. That is why hiring is the one area where you should be very risk-averse.


Great thoughts in this one, but missing what I think is the biggest key to hiring correctly in the startups I've been part of is what Paul DePodesta said in Moneyball - ""What gets me really excited about a guy is when he has warts... and the warts just don't matter."

I've always thought that hiring in a startup is really like what the A's had to do in Moneyball - you don't have the advantages in terms of money, facilities, and even equity value of some of your much better funded competition for talent.

In that situation, you have really only three levers to pull - 1) give up more than you want (which is what I've seen too many people do); 2) sell the benefits of the startup life and your mission; and 3) find talent that can perform at a similar level that's undervalued.

The place that I've seen startup hiring really add value is when someone can be incredibly effective at #2 (which the author talks about) and they can develop a process that effectively hires for #3.

I've built my last couple of companies in the information security space and #3 is especially important, because there's a significant premium paid for high-value talent in our space. So, finding talent who can perform at an extremely high level whose "warts" don't matter has been a life-or-death matter for creating a company that can compete with those in the space that have more money (either through funding or scale).


I disagree. InfoSec has these companies who hire #3, thinking they can underpay, and it's given the whole industry a bad name because of the shoddy work and dubious claims they make. They go in and play pass the hash, charge a lot, and the company is really no better off.

No offense, but do you think the fact that you have made multiple attempts and not yet created a company that has become a prominent name in the industry means that your approach may not be working?


I entirely agree on the large number of companies who do crappy work in the infosec industry... there's a lot of them, especially in the penetration testing realm.

We're not one of them. Nor were any of my previous teams whether they were at my companies or at companies I worked for (whose names you definitely know).

"Prominent name" is a marketing thing as much as anything... I'd be willing to put the accomplishments of our teams up against most. Hitting $10M in revenue in under 3 years building a security firm with no investment and no debt isn't something I'm going to feel too bad about, even if we don't spend a lot of time making a big deal about that.

You're making the classic mistake of thinking that a company that makes a lot of noise is the same as a company that does great work.... those venn diagrams sometimes overlap. And sometimes they don't.


This is great insight. Really like the moneyball quote.


So much interesting stuff here. For the past couple years, this has been most of my (non-billable) role at Matasano, and we've gotten steadily better at this stuff. So, my thoughts:

›››››› Spend more time

›››››› Have a mission

›››››› Always be recruiting

These three are of a kind for me.

I recommend that you think about hiring the way Patrick McKenzie things about conversion optimization: as a form of marketing that is amenable to engineering. In particular: start tracking it as soon as you possibly can, so you'll have data to pull trends out of. Every effective hiring organization I've talked to has a process for this.

"Have a mission" sounds fuzzy but I don't think that it is. What we've learned is to think a lot about what's good for the candidate about the roles we hire for. We've gotten good enough at this that people on our team can write snappy job descriptions for us: https://news.ycombinator.com/item?id=5640441 --- Sean's a good writer, which helps, but there's also a notion across the team of what we think is great about the work. Having this "through line" for all your recruiting conversations makes it easier not just to sell the job to candidates but also, like any serious sales effort, to qualify prospects.

Being serious about qualifying also gives you another piece of data to track: how well your qualifiers predict how far people get into the funnel. That's been helpful for us too.

›››››› Don't hire

›››››› Get your hands dirty

This times 1000; I think this is the most important piece of advice he has. Jason Fried has been talking about this for years with "The Importance of Hiring Late"; the 37signals motto was "don't hire until you've done the job yourself".

›››››› Focus on the right way to source candidates

I agree in general with the idea here.

I think in particular that "blind" job ads of any sort do poorly. Every venue for ads that has significant visibility is both oversold and also low signal/noise ratio. We don't take job ads seriously anymore.

There's a lot to think about w/r/t poaching employees, particularly from peers. It's important to remember that the ethics of poaching from another company have to be weighed against the best interests of candidates; refusing to talk to someone because they work for a friend's company is probably a fraught decision. On the other hand, remember that you're likely to be at a different company in 2 years, and your long-term relationships with people are important; I wouldn't use inside information I have from peers to poach employees.

I wouldn't work with a recruiter. They also irritate candidates and set up weird incentives.

›››››› Don't compromise

›››››› Look for red flags

This is some of the oldest hiring advice in the industry, for a reason.

Be careful with the "default-to-no" posture if your hiring signals come from employee-driven interviews. Your whole team is rarely on the same exact page about what you're hiring for.

I take specific issue with the "red flag" of people being title-conscious, because there are good reasons some people think about titles: they are (sensibly) concerned about their own career trajectory. The absolute cheapest benefit you can offer an employee is their title, and if they have a rational reason for wanting a better title, why on earth would you refuse to give up some title to get a good candidate on board?

›››››› Have a set of cultural values you hire for

This scares me because I think people don't have a good idea of what a "cultural value" really is, or have aspirational cultural values, like "we'll work as hard as it takes to make our milestones!".

You discover real cultural values bottom-up, by observing what is good and effective about your team. You don't have the value until you've established it in your existing team.

It's obviously important that you build your team out of people who will work well with your team. But it's equally important not to cast too small a net. Among other reasons: it can make you especially susceptible to drama, in a monocultural kind of way.

›››››› Hire people you like

Don't try to do this.

You will be surprised by what you end up liking about people who didn't seem like an immediate "hang out on weekends" fit with your social culture.

When you hire, try to make sure you're hiring on objectively important criteria. Don't kid yourself about how much it matters that a candidate wants to go bar hopping with you after work.

›››››› Fire fast

This is so hard to do. If you haven't actually run a "fire-fast" culture at size yet, I recommend you not assume you'll have this capability. Hire as if it's the life-or-death decision it probably is.

›››››› Put a little bit of rigor around the hiring process.

Put a lot of rigor around the hiring process.

We've steadily standardized every part of our recruiting process and to date we've never looked back at something we standardized or measured and said "you know, this wasn't worth the effort or the cost in flexibility".

We have a funnel with specific objectives at each stage of the funnel. For instance, in 2013, I think it's impossible to interview with us without knowing what our whole hiring process is, and without having the phone number of a company principal to call with questions. It is remarkable how often we hear how much better our process is than the typical company's process, because the things that make us outwardly easier to talk to are so easy. And yet, until a couple years ago, we weren't doing them either.

›››››› Have people audition for roles instead of interviewing for them.

There's nothing I can say about this that hasn't already been said a million times, but I'll make the simplest point against it that I can: the best candidates generally aren't available to "audition" for you, because they're already working full time jobs.


I don't think I've ever done this on 5+ years on HN, but thanks, Thomas, for this comment. Definitely one of the best & most helpful ones I've ready here in a long time. It really lines up with old-school advice from the seemingly forgotten Drucker (and his ilk), whom I'd suggest to anyone reading this comment (The Effective Executive).

EDIT: I really think it's key to emphasize not just hiring people you like. Some of the best people I've worked with I wouldn't hang out with on a Sunday. As long as you're able to be productive together, the rest is moot. A company isn't about creating a friend group.


Regarding the "hang out" test. Imagine you're a person who only likes to hang out with certain people, namely people already somewhat like you, by way of gender, race, age range, grew up like you in the USA watching sports and 80s sitcoms, and so on. Now your hiring process is probably not only unfair but illegal. But your company will act as a great echo chamber to reinforce your own preconceptions, so you have that going for you.


Certainly if a person is not willing to have his assumptions challenged, then the "hang out" test will tend to attract and replicate more of the same. But it's still an important question for reducing conflict and confusion in hard-working teams who will be spending a lot of time together.

The "hang out" test (or "Sunday test" or "airport test") has its imperfections, certainly. I'm wondering, what would be a better assessment of cultural fit?


Not assessing cultural fit in that sense at all.


I feel like I agree with your aversion to the "hang out test" because it's just wrong to do that, but I also know that for me personally, work is far more motivating when I'm friends with my coworkers. Especially when travel is involved.

I can't be the only one who feels this way, so it would be hard not to factor this in when hiring, especially with a small startup.

Do you really think that the added motivation from working with "friends" is insignificant?


I agree, I "like liking" my coworkers too. I guess I'd just encourage hiring managers to consider that:

(a) it's hard to predict who people are going to be friends with; we have 9-5 people with kids, 20- somethings that live in the hipster hotspots, board game geeks, people who drink beer, people who hate beer, people who don't drink at all, and a variety of ages, and everyone seems to get along and enjoy having lunch together.

(b) monocultures are risky in social environments too; for instance, they become incestuous and breed drama; one team member leaves in a huff and your whole team's morale can get seriously screwed up.

(c) if you're getting a company culture by literally hiring everyone's friends, that team is going to be hard to manage top-down. If you don't have a top-down management culture, that might be fine. But a lot of companies that think they're not top down really are; most companies are managed top-down.


But what co-workers will I drink beers with until midnight after work then?! ;)


"The absolute cheapest benefit you can offer an employee is their title, and if they have a rational reason for wanting a better title, why on earth would you refuse to give up some title to get a good candidate on board?"

Well one reason [1] might be that by giving the a "big" title it will enhance their resume in the eyes of another company that is looking to poach. Doesn't matter if it works out or not at the new company. You've still lost out.

[1] This is simply pointing out a downside. It doesn't mean what you are saying "cheapest benefit" is not correct.

In all honesty though what stopped me cold was this which appeared at the start:

"Keith Rabois believes the CEO/founders should interview every candidate until the company is at least 500 employees."

And then:

"*In the beginning, get your hands dirty.

Speaking of spending time, you should spend the time to learn a role before you hire for it. If you don’t understand it, it’s very hard to get the right person. The classic example of this is a hacker-CEO deciding to hire a VP of Sales because he doesn’t want to get his hands dirty. "

How much time is proposed to spend on learning the job of a company where you are supposed to hire (he agrees with the statement) "the first 500 people".


Anytime your reasoning is "we shouldn't do it because it will make them attractive to other companies" you're probably wrong.

You want a company full of super-stars that everyone wants to poach. Otherwise you're just like the companies that prohibit employees from have linkedin profiles or don't give employees training because that makes them more poachable. Crazy.


Not sure you understand what my point is.

I'm not saying you shouldn't have employees that are so good others want to poach them.

I'm saying that by giving someone a title (that they might not deserve) you are possibly making them more attractive and more likely to be poached. This was said simply to counter the parent point that "there is no cost".

Let's say I allow you to put on your card "VP of Software Engineering" vs. just "Software Engineer" as only one example. (Forget legalities I am using this to prove a point).

Or, "National Marketing Manager" instead of "Marketing Manager".


Or it makes them less likely to be poached, because potential poachers will discover they don't measure up to expectations after a phone screening. At this point we're all pretty used to sussing out title inflation at step 1.

Or maybe someone will perceive it in a completely different way. At an individual level, big moments in people's lives (like changing jobs) are shaped by the edge cases that lead to actions, not macro average behavior.

Making personnel decisions based on worst case hypotheticals only seems to increase the chance your employees will have a hard time imagining long term career growth by sticking with you. Deflating titles seems about as viable as forbidding conferences. Except where titles impact compensation, all of this is completely independent of actual competence.


> Get your hands dirty (...) the 37signals motto was "don't hire until you've done the job yourself"

Maybe you can hire people this way, for jobs you're already familiar with, or for very low qualification jobs (janitor, maybe, although there are probably tricks of the trade that are non-obvious, even to a "smart"(!) person).

But if you were trained as, say, a programmer, how do you implement this advice to hire a doctor? A lawyer? A typeface designer? A rocket scientist (SpaceX)?


You're stretching the word "hire".


The OP seems to believe that any "smart" person can learn any job in hours.

This is Enron thinking ("the smartest guys in the room"). Less controversially, this is what Marissa Mayer designing the new Yahoo! logo seems to think. It is wrong.

It would have been better for Mrs Mayer, Yahoo! --and the rest of the world-- if she had hired a real designer before attempting to do the job herself.


Overall, I thought this was a great post, but. . .I've always been kind of hesitant about the "hire someone you'd want to hang out with on Sunday" bit. Well, not when I first heard it. . .but over the years, I've come to believe that so many people hire or want to hire people just like them that it weeds out a lot of otherwise qualified people. Yes, I know you want people who share your company's cultural values. . .and that in a small group it's important that people like each other or least don't dislike each other. I guess it depends on how tightly you draw your box. . .and how "boxy" your box is. . .and the alignment between your comapany's values and your personal values.


Don’t limit your search to candidates in your area. This is especially true if you’re in the bay area; lots of people want to move here.

At first I thought I misread this paragraph, because I'm so used to people advocating remote hires at this point. I was expecting it to say "Don’t limit your search...lots of people don't want to move here."


No, the author explicitly recommends against remote work. It's with a caveat of "early on", but in most places that will harden into a general unwritten "no remote workers" policy, as the organization grows and people are afraid to try something different than what has worked so far.

This post is pretty heavy on the "company culture" stuff -- more or less, the idea that you should want to go drinking with your co-workers. People who believe in this don't tend to believe in remote work. I should mention I completely disagree with all this, but I am biased.


Recruiting is a very hot industry right now, but be warned - I've talked to companies that are hiring fast, and they get 20+ offers a day from recruiting startups trying to offer their services.

Recruiting is needed because there is a signal vs noise for developers.

But there is also a signal vs noise for recruiters - it's a very hard industry to crack into. (AngelList is one company doing a great job here - talking to companies, it seems like AngelList talent is a fantastic resource - also Naval has talked multiple times about hiring/recruiting being a far bigger market than crowd-investing.)

Regarding the personal network hiring tool: I actually started working on this recently - it looks at Facebook connections currently, so that the person who is incentivized to be hiring can just allow an employee to Auth their FB profile, and then go and browse away.

A friend of mine is working on 'Tinder for Startup Jobs' - he's very close to done (iOS app, meteor.js web app is also almost ready), so if you would like to be swiping companies left and right and want to know when he pushes that and when I push this hiring tool, I whipped up a Google Form (as is all the rage these days). [1]

[1]: https://docs.google.com/forms/d/1xijiSr7QsQ0d-fcg_fXm9dLgOXe...


I'd love if more companies adopted auditioning over the traditional interview process.

It was counter intuitive to me at first but it's potentially a cheaper way to hire. There's less downtime for the hiring team - everyone can more or less continue what they're working on.

It's a better quality of interview too - candidates have a more realistic platform to show their worth.


For candidates who already have jobs, how would "auditioning" work? Is it assumed that they'd take time off from their current job to do it?


An audition can be a small paid contract that you can work on in your otherwise free time hours, here and there, on your own premises, then just do whatever interaction or delivery is necessary to show results and demonstrate value. And you get paid for it. It doesn't have to be a MF/office-day/on-site thing. The goal is just to test out two-way fit under as realistic of circumstances as possible, testing for the things you care about most, and, really, have it be reciprocal: the applicant/candidate gets paid. The details are choosable by both parties and should be mutually agreeable. Sprinkle to taste. And you can iterate.


For me the issue is coming up with the tasks to farm out. Do most companies have lots of discrete tasks that don't require domain knowledge?

Everyone says it takes 3 months to a year before a developer is really up to speed and hits their peak contribution levels. How does that square with this new philosophy of interviewing-by-contracting?


Auditioning sounds great, atleast from a college graduate's perspective. Make the new graduates work on problems. A percentage of new generation of coders end up learning that whiteboard tests work perfectly fine and are the de facto standard.


"touchable" portfolios, a public interaction trail, and realistic paid short audition contracts are a killer combo and I hope the future for software development hiring. I'm doing my part to promote it.


Yet another article on hiring without empirical data. And as everyone knows, "gut feeling" doesn't actually turn out to be correct that often in recruiting (otherwise we would have solved the problem already).


Do you have any empirical data to back your point up? Or are you basing your thoughts about gut feelings on gut feelings?


You don't need specific empirical data to back up the point of saying that claims without empirical data are not reliable enough. We have the scientific revolution to back that point up.


I think it's worth noting the irony in that you seem to believe in solving everything rationally except for the value of rationality.

One thing that scientific research has elucidated is that gut feelings aren't useless, and in fact can be very useful in evaluating people. The thing is that we take in so much data via our senses and the conscious mind is only capable of handling a very small amount of those signals. The unconscious mind picks up on these things and surfaces them as intuitions.

https://en.wikipedia.org/wiki/Intuition_(psychology)#Studies...


This maps extraordinarily closely with what we've seen at Thinkful (http://www.thinkful.com/) with both our hiring as a team and with the students we've helped get hired.

Our biggest breakthrough actually came last month when we started simply hiring our students. Three of our last five hires have come from people taking one of our classes.

It's a phenomenal way to get the voice of the user into our user experience, and each has proven a great cultural fit.

We're not sure it'll work for every position, but perhaps when Thinkful starts offering CTO-classes!


"The absolute cheapest benefit you can offer an employee is their title, and if they have a rational reason for wanting a better title, why on earth would you refuse to give up some title to get a good candidate on board?"

If your role doesn't match your title, you may be in big trouble when/if your company gets acquired. Also it might seem like the cheapest in one sense but as the company grows you'll find yourself in an awkward situation when a manager makes more than a VP you just hired. It's a sensitive subject that should be approached more carefully than you'd expect.


> Whenever possible (and it’s almost always possible), have someone do a day or two of work with you before you hire her; you can do this at night or on the weekends.

Fuck off.


Using "she" when talking about developers to be politically correct is really getting old.


I disagree with some of it agree on some of it, but i strongly disagree with section on cultural values.

First of: "Spend a lot of time figuring out what you want your cultural values to be (there are some good examples on the Internet)." Do spend time figuring out what your cultural values are, but don't look for them on the Internet, or to put it another way: don't have cultural values for the sake of having cultural values.

"Treat your values as articles of faith" - also don't do this. Don't take anything as article of faith, you should have a reason for each value. If you can't put a reason on value, how much value does it really have?


People that have a great job and have done great projects will ask you for more and can easily leave you if they get bored. I think a great recruiter is someone that gives a chance to people that show other signs of "success" besides pure measurable performance. Especially, I think you are better off sometimes hiring people willing to learn and adapt.

Of course, it is easy hiring the 1% when they are already in the 1%. Much more difficult, and much more valuable, is hiring them when they are in the average bucket or they are not even there yet (i.e. people looking to move into programming).


Hi ! I agree on that investing time and just speaking with people is a right thing to do. And I cannot stress enough the need for real-life exercises during the interview and the need for just working with the people to be able to judge their abilities. I was so annoyed by 'traditional' recruitment that I wrote this post : http://blog.cyplo.net/2011/07/24/how-to-hire-people/ ;)


Just re-read and saw this: ".... if I were going to jump into....recruiting startups, I would try to make it look as much like personal network hiring as possible..."

Funny about that: I started exactly that with a friend at a Startup Weekend a while ago... we didn't go anywhere with it: http://www.findexpert.co/

We also found that these guys did the same thing: https://ooomf.com/


Can startups stop thinking that giving me some meager equity of a company that would be lucky to have a 10 million exit is worth paying me some -XYZ% of my market value? Especially when there's so many companies fishing in the limited talent sea?

It might also be a Boston thing, but I've seen some companies in the startup scene here trying to offer like 60K for senior-level Python developers and such....


Is Sam saying that investors recommend that a first engineer gets 1.5% (and that he recommends 3%), or that he recommends 1.5%?


And why does Stripe need top developers? To make a REST API for payments? What am I missing?


Nope, you nailed it. There is nothing in payments that requires more dev work than could fit in an Excel function. Patrick admitted as much with this screenshot of the complete Stripe codebase earlier this week: https://twitter.com/patrickc/status/381779690567913472

That said, the pingpong tables aren't going to play themselves...


Payments is an extremely hard problem. Try picking up a NACHA rulebook. Makes a great doorstop, it's the size of an old-school phone book.

Don't know what NACHA is? Consider the possibility that you don't actually understand the problem space, then.


You are missing an understanding of the complexities of the credit card payments industry.


I suspect it's to do with the 100% uptime they should be aiming for. They might have some other interesting stuff they're working on as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: