Hire For The Ability To Get Shit Done
blog.eladgil.com
blog.eladgil.com
I had this experience working at Google. I had a horrible time getting anything done there. Now I spent a bit of time evaluating that since it had never been the case in my career, up to that point, where I was unable to move the ball forward and I really wanted to understand that. The short answer was that Google had developed a number of people who spent much, if not all, of their time preventing change. It took me a while to figure out what motivated someone to be anti-change.
The fear was risk and safety. Folks moved around a lot and so you had people in charge of systems they didn't build, didn't understand all the moving parts of, and were apt to get a poor rating if they broke. When dealing with people in that situation one could either educate them and bring them along, or steam roll over them. Education takes time, and during that time the 'teacher' doesn't get anything done. This favors steamrolling evolutionarily :-)
So you can hire someone who gets stuff done, but if getting stuff done in your organization requires them to be an asshole, and they aren't up for that, well they aren't going to be nearly as successful as you would like them to be.
The other risk is of course the people who 'get a lot done' but don't need to. Which is to say they can rewrite your CRM system and push it out to the world in a week but only by writing it from scratch.
I think you nailed it here. But something to realize is that this is not unique to Google, this is true in any large corporation.
The issue is that as people develop careers within the corporation, they become interested in what is most politically expedient for said career. This means they become very averse to any situation where the individual might personally look bad.
This means that aggressive projects which could have a high level of reward and equivalent risk for the company get waylaid disproportionate to their overall risk/reward ratio.
I think your point about people not understanding the systems that they are working on compounds this idea, as it makes the risks of changing a system appear higher (because they do not know the system).
A start-up environment and Skynet are quite different with different objectives.
You've sort of nailed it. Also what I see is, how much people are addicted to the NIH syndrome. They have a ways of working which they won't change, adapt or even agree debate for their own good.
The way I see, too much or too little process are both equally dangerous. The key is neither to over play nor under play the game. Too little management leads to wandering in the wild with no goals, plans, tracking and destination. Often overly delayed projects.
Too much management gets in the way of achieving what would have been even easily possible.
After all the analysis I can say, sure you may want to hire every smart guy on the market. But you must also know to manage them. Bunch them together, create a positive environment and enable them to be as much productive as they can be. Good people need to be taken care of, Senior developers/architects even though not managers need to have some people skills. Its simple, if interacting with people is a part of your job.. People skills become part of your job.
To be good alone is not sufficient, if you are good alone you can probably get a maximum of 9 hours worth of job done everyday. But if you can manage 10 such brilliant guys you can deliver 90 hours of such work every day. But that requires spotless planning, tracking, course correction and most important creating an environment where such people can be productive.
Nothing big in software these days can achieved without team work. If a person is not good with teams, may be its time for him to look somewhere else. Being a jerk, rude and arrogant with junior developers may help you give a false sense of superiority but that won't bring you success.
But hey, the CEO had sold a previous company for good money so this means he knows what he's doing. I'm sure they'll be a huge success.
I'm not saying that I'm God's gift to college-dropout programmers, but I'd never had a problem succeeding in a job until this one. In reaction to this state of affairs I had considered that maybe I need to be at a huge company that has better processes, but your Google tale says maybe otherwise.
</vent>
I was able to land a gig with a small shop doing work for some incredible clients filled with brilliant people that know their product back-to-front and management that polls the developers for input throughout the project life cycle. Needless to say I've never been happier.
It pretty much depends on what are you looking for: a procedural executant or a project developer. A project developer can execute very well for the first couple of times, but expect from one to get bored with the same speed.
You have to find the right tasks for these "very smart people" instead of hiring them to do the wrong job. The alternative is to hire really dumb people, at least they'd never be able to do anything more or better than what they're told.
So very true. I'm in this situation at my current job: I was hired as a dev, was told to fix organisational things by senior management and am now meeting resistance and roadblocks for various reasons. I'm a dev, and I'm not an asshole, and I also have no authority to steamroll people. At first I felt empowered but lately I've just felt bogged down. It's a sucky feeling.
I (and many people who I've hired) don't have time to waste on your startup. I can tell within two minutes if someone can code or not. I've never understood the need to have someone write code (and then nitpickingly critique the code because it doesn't look like my code) when I can just ask them and know if they are lying or not.
And I've hired a LOT of super fantastic programmers.
Our test was not primarily just code quality.
When we brought people in we would look at:
1. Approach. Did they use e.g. an open source pre-existing module or write something themselves? Did they come up with a creative solution?
2. Culture fit. While they were in working with us, how did they interact with the team? Did they enjoy working with us and vice versa?
3. Productivity. How much did they actually get done?
As for culture fit, again, a socially competent interviewer can size these things up reasonably quickly.
I mean, a half-day programming test feels excessive. Are you worried about loosing good candidates that just don't want to deal with the headaches?
I've heard people try to justify insane hiring processes by saying "we want to filter out the people that don't want to work here. We only want people that really want it." But the best programmers -- the ones you want to hire -- are going to be in high demand by companies that look at their github, have a three minute interview, and pull the trigger.
A lot of people about to make a long term commitment to a company also want to make sure the company is right for them. So this was a good way to get to know one another.
I couldn't care less about the problem OR the eventual solution. I couldn't care less if he used an open source module to write some new code last week or if he thinks CouchDB is super amazing.
What I really want to know is how they think.
When you have a programmer who lives in code, he (or she) swim through problems like they are physical objects. They find passion in killing bugs and making code more efficient. I can hire a hundred people who can recite what the Gang of Four is or write a bubble sort. I can't hire guys who care about whether their own code can be improved.
But this is just one way. There are lots of ways to tell.
When I interviewed for previous copmanies, this is actually one of the questions I would use. "What is the hardest bug you've ever worked on?" If you take this question, and keep pressing for more and more details, and expand on that question, you can get a surprising amount of information about someone's experience and understanding. If they can't adequately answer this question, it means they haven't really been deep in code, or don't have a lot of experience, so that sets your expectations relative to the position that you're hiring for. If they claim to have a lot of experience, but can't go into too much depth, it means they're not very excited about getting their hands dirty or they don't understand what really happened, which are both bad signs to me.
I don't care if they can write up a function that can spit out the Fibonacci sequence. I can that they are smart enough to figure out relatively complex issues and can communicate this intelligently.
If they don't ask for relevant details, etc, they won't be coming up with a solution no matter how they do it.
Common knowledge is that hiring programmers is insanely difficult. If you have a gift for it, you could make craptonnes of money!
It's everything else that is the problem. Are they lazy? Do disappear for days at a time? Will they not fix bugs in someone else's code? Will they complain NIH at the drop of a hat. Will they care to write all the ugly code we need to ship with, and not just the first 80% of the project?
These are the things that are hard to assess. But just knowing if they can code -- that's pretty easy.
† List exaggerated
It was also a burden on our team to spend all this time with a candidate, so this would often be our last step.
We would next expect someone to invest in us if we did not also invest time on our end.
If you feel like you even have to ask these questions your candidate selection process is badly broken, but the same approach scales up to all levels.
The only reason I was putting up with them was because of friend inside who had referred me. The thing is they made me right endless code rounds after rounds and I did code pretty well. I solved close to 90% of the problems without the internet. But most of them were coding problems.
During the final rounds, I don't know what got into them. They started going into Core CS areas. And damn then they started the Algo pop quiz. Some how during the last 3-4 rounds they started giving out the perception that they were not happy with some one who did not know the algorithms from the book memorized by heart. And that even good coding skills can't compensate for that.
After that they called me back and told, that some other department from the same company would like to have an another round. I just politely denied and, cut the call.
Oddly enough, when you decline to continue interviewing they often immediately send you a job offer.
I wouldn't have accepted the offer from the company, from the very outlook it looked like bureaucratic jungle where no one is capable of taking a decision/risk until they run through some 20 meetings to decide what to do. And then toss it on to some one else.
For that if this is what you make candidate run through, you are sure to get CareerCup interview questions ebook masters but not good programmers.
Though in our case there wasn't too much structure day-to-day, there was total lack of structure.
How?
There are real diminishing returns on technical interviews. If you've got well thought out, well structured questions that cover the key areas for your organisation, unless you're doing something massively complex or specific, you can work out whether someone has the level of competence you're looking for in a couple of hours.
b) The best traits of someone are very often some of their worst as well. Be mindful of that when trying to find the "perfect" candidate. Example: Someone who communicates well might also communicate (i.e. talk) a lot instead of working at their workstation for extended periods. The point is to not expect perfection from people. And by perfection, I mean excellence in several types of disparate skills.
I find most of these are pretty easy to fix:
Lack of urgency. Good people will hit their targets or let you know well in advance if they won't.
Easily distracted. Starts but never finishes things.that you have one major task to do and that's what you'll be judged on. This seems more of a management fail.
Argumentative. We try to hire smart people and fortunately/unfortunately smart people have strong opinions on how things should be done.
We've settled on a hybrid of the Microsoft, you own your area for smaller decisions, and the "disagree and commit" style of decision making for larger decisions.
Slow. If you can't keep up then you don't make partner at your 3 month review.
Perfectionist. You can code your algos and systems as well as you want as long as they work and come in on time:)
The problem is that the smartest, most creative, and overall most productive people often don't think this way at all. Instead of slogging away obediently at a problem for six hours, they might dilly-dally on twitter for two hours before having a lateral insight that lets them solve the problem in 15 minutes. They might go to Thailand for the first 3 weeks of a 4 week project then, in a semi-sleepless 100 hour binge, produce a technical masterpiece with a beautiful UI and additional business-savvy features no one else could have thought of thrown in on the fly. Would it be better for your company if this person just sat at his or her desk and focused perfectly and coded 10 hours a day like a good little robot? Does it matter? The same qualities that make some people brilliant will tend to make them unable or unwilling to work like this. You can gripe about irresponsibility or lack of discipline, but they are indeed getting shit done, just not the same way you do. You can pass on them because they don't fit your mold if you like--a more open-minded company will quickly be there to capitalize on the value they offer.
I'm just letting you know, I'm not working with you. Luckily, after years of experience I have been able to arrange lines of clients wanting me to get stuff done for them so I'm capable of screening companies like you on simple cues like this.
Have fun finding a slave who'll just do what you ask, no questions asked, no creativity involved.
Of course, I'm lazy but only about things that don't really matter. Only stupid people laboriously move huge tons of mass by dragging them; smart people invent a wheel and an internal combustion engine.
There is a certain type of cowboy programmer that depends on thinking quickly and having a good memory. This type of programmer can write code that works, really quickly -- provided the size of the project can fit entirely in their head. Because of this, they can do really well on small size projects but they never learnt proper code design and architecture skills, because they never needed them. This type of programmer ends up not being able to scale as the size of the project gets larger, because eventually they reach the limit on how much code they can remember at one time, and the lack of code design that lets you reduce the number of things you need to be aware about in order to write new code without breaking anything really starts to bite you.
It is not about doing short fast sprints - it is about being long term productive as a member of a team. Productivity includes good design and thinking through what is needed up front. But it is also about marrying thoughtfulness to efficiency.
Just so I understand: You're always willing to trade intelligence and experience for someone who produces more, for essential key components of your startup. So you would hire a less experienced person who writes more code over a very experienced slow developer, do I have that right?
All that does is trade the short term risk of not having as much developed with the long term risk of having a broken system. It means you're potentially betting your business on someone who isn't the best, just because they seem more productive.
In summary, you risk making a Friendster instead of a Facebook.
Let me know if I misunderstood your point.
I hire on both: smart people who get it done. And getting it done is relative. Unless you're in consulting, velocity is almost never the issue compared to correctness, so a smarter, slower person is sometimes the right choice. A member of my team took a long time to come up to speed, and is now kicking ass and making the right decisions to keep things on track.
I want candidates with all these things.
If someone is very very bright but not very effective, or terrible for the culture of my startup, I would not hire them.
If someone was an amazing culture fit, but not very bright, I would not hire them.
"Coming up to speed" makes sense. It is all about the context in which the person is working, what they did before etc. Productivity takes time to scale, as does trust in one another, working as a team etc.
But there are some people that you give a lot of time and attention to that just don't get a lot done.
Ok, so what exactly does that mean? Are you concerned with velocity or correctness?
You want both. It's a false dichotomy.
Most of the observations listed here I'd be more likely to line up with a lack of investment and clear alignment of goals and priorities. The tone of the article seems to further support to me the lack of an environment that's nurturing to the team members' motivation.
And, I've worked with many GSD engineers, so they definitely exist.
I'm just arguing that it's contextual way more often than it's fundamental, and the tone of the article left me with the impression that the author isn't interested in playing much of a role in people's motivations.
That said, I also think there are many people who just aren't that productive, and screening for people who are great at GSD is crucial for a startup.
"... there are many people who just aren't that productive..."
I don't think that's the case. I think the steady-state for most people is working (hard). People who aren't productive are generally frustrated that they're not productive. I get it though, there are people who require very little from the outside world to move forward. They'll "GSD" as you put it without much outside influence. I've worked with people who score high on that metric, and I'm genuinely humbled by their ability to make forward progress even in less than optimal conditions.
That said, I think it's tempting to value them above resources that are more sensitive to their context but I'd warn against missing an opportunity. In my experience the developers your talking about will absolutely 'GSD'.. Even when all you ask them to do is 'S'.
I frankly like surrounding myself with people whose motivation falters when they don't feel connected to the problem we're solving for our users, or when we're calling too many bullshit meetings, or when they don't believe in what we're doing. Keeps us honest. Those employees are your canary in the mineshaft. I think where their interest goes, our market is likely to follow.
After all, if my team isn't excited to build it who the fuck do I expect to pay me for it?
Don't forget that you need to pay them like-wise.
It's acceptable to accept slower (but still high-quality) work in exchange for less pay, etc. And sometimes it's even acceptable to let the quality slack for the same reason.
Unless of course he missed off his other criterion "will work for peanuts".
There are many reasons for that, most are happy with flat salary models where can they pay a donkey and a horse the same salary under the premise that they assume both a donkey and a horse can carry weight and run. Unfortunately that's how badly people think of when they pay. Or they are just afraid they may end up setting a trend productive people end up earning big all the time.
Going forward, I will probably only hire someone after seeing them work on a small project, maybe even pairing with them in the process.
A good rule of thumb to spot these people is how much yak shaving they require before they will start adding value. If they walk in and say "well I need new new system A from IT, and hours B approved by HR, and version control system C, and software stack D, and my last company had E, and, and, and etc..." The big red flag is when they ask for all of this serially and not in parallel. Then you know you've got somone looking to setup excuses for why they haven't delivered. A true GSD will carve through obstacles as much as possible.
A good analogy is the out of shape person who wants the platinum gym membership, new workout clothes/shoes, the trainer, and the diet plan, but always needs something else before they can start working out. Meanwhile the GSD person is going for a jog and doing pushups.
Procrastination, distraction, laziness, lack of follow-through, slowness, those all manifest themselves when I have no reason to be engaged in the work. The work might just be a really bad match (example: endless maintenance and toiling through bad legacy code, putting out fires, when I could be designing and building something half decent).
But I do think there are some people who may be very smart or experienced, but who just are not very effective. Some of this could be contextual (in which case it is valuable for both you and them to find them a new home), but sometimes it is just a person's personality or approach to work.
People are way more productive, focused, and determined when pairing. It's simply much harder to waste time and produce low quality work when you're directly accountable to the person next to you.
Scrum solves the urgency, commitment, follow-through, and slow problems. Each iteration the team has to commit to a set of tasks to get done. If they don't make it they have to figure out why they didn't, and how to improve. This continuous reflection and optimization is how team's get good and fast.
Of course there will be people who can't be brought into the team, but they are few and far between. And you can't tell until you've created a team for them to be brought in to. So instead of focusing so much on the fantasy of hiring a great team, learn how to build a great team.
nothing about making software is one size fits all. forcing scrum and pair programming sounds like a really good way to get an enthusiastic team, but guarantees little else.
Applying one aspect to hiring, especially at an early-stage startup, is a poor approach.
Do you think this is not the case? Or are these specific types of roles where you think having effective people are secondary?
However, productivity comes in multiple forms -- just depends on how you measure it. Because of the limited resources in early startups, people need to fire on all cylinders -- productivity and smarts.
Have you seen the people, money and time resources NASA put into the code which runs on space flight hardware? The reviews on reviews on reviews, the exactly specified every code path, the complete tracking and investigating of every bug in their codebase ever and checking all of them for wider applicability... and they don't get 100% success in years of applying their processes to a comparatively small and limited codebase.
Wasn't Zed telling us about how 37 signals restarts their Ruby in Rails processes every day due to instability and memory leaks? Guess that makes their lower-than-100% success rate multi-million dollar generating software "worse than useless", eh?
If you bailed them on this, you're process is seriously flawed. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect As Kruger and Dunning conclude, "the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others" Historical references Although the Dunning–Kruger effect was put forward in 1999, David Dunning and Justin Kruger have quoted Charles Darwin ("Ignorance more frequently begets confidence than does knowledge") and Bertrand Russell ("One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision") as authors who have recognised the phenomenon.