How I Hire Programmers (2009)
aaronsw.com
aaronsw.com
These are rather obvious metrics that a child could have drafted. Are you smart? Can do you do things? The problem is that these are subjective measures.
A smart person, who sets the world on fire and gets things done, perhaps like Aaron did or could have done, has a different perspective than say a 50-something product manager. They may see smart as seeing the future, where the programmer may see smart as knowing x86 assembly. And the fool may see smart as someone who talks in technical jumble.
There is no golden key to hiring folks. My experiences say that in a good company, the manager needing help should be in charge of hiring who he/she deems fit. Some may, perhaps rightly, cry nepotism and other factors may run amok. But putting that weight, and risks, on the manager is the point. If they hire an unqualified buddy, they are responsible and ultimately fail with them. I don't really see this as different than Aaron - someone who has their own metrics.
In short, trying to put out any 'guide to hiring people' is a short sighted goal, seeing as everyone has their own experiences and views. This is really no different.
I agree. AS being dead makes it difficult to discuss issues related to him.
I don't view AS as wise sage. I always found he was a bit of a self-promoter; a bit of a loose cannon. A person who was a hacker, but like some millennials, the validation from publicity got to his head.
It's taboo. If you attack certain things on the merits - certain people will believe you're attacking all freedom of information - because they relate AS to some sort of representation of it.
Burglarizing MIT isn't hack in the sense of hacker culture. MIT hacks were clever. Burglarizing for the attempt to swallow data isn't clever - it's a hammer.
As far as the MIT incident... I don't really think he burglarized MIT. He tried to bring documents that were hidden behind a paywall to the general public. He didn't rob anyone seeing as how the documents were submitted without compensation by the people who created them. Whether or not it's hacker culture, it's a culture of social disruption aimed at the betterment of us all.
There will always be shakers, people who raise their voices loud to stand for what they believe in. Unfortunately, they will all be followed by people like you and your parent poster who will attempt to defame their character and negate their contributions.
I think Mr. Swartz's actions at MIT are admirable, but I don't know how you can deny that what he did was burglary.
It seems as though there is some kind of personal hatred towards Aaron that compels people to try and vilify him as if he was some sort of criminal.
Not on my part, I've always thought highly of him. I was just correcting your misconception about burglary laws.
> A laptop in an unlocked cabinet is not really breaking in.
Burglary, again, is gaining entry to a place you're not authorized to be, with the intent to commit a criminal act. Whether the cabinet was locked or not has no bearing on that charge. In many places, entering an unlocked car or house that doesn't belong to you constitutes burglary, even if you don't do anything while you're there. It's up to the court to prove whether you had intent to commit a crime, but the simple act of gaining unauthorized entry is usually enough to be charged with burglary.
One more thing: I agree with you in that I don't think Aaron felt what he was doing was wrong. Given my background in law enforcement, I simply felt compelled to correct a misconception.
You can read more about the charge of burglary in general here, though you may wish to read about Massachusetts's specific laws as well:
http://criminal.findlaw.com/criminal-charges/burglary-overvi...
If someone steals something from me, it isn't that they now have it that is the big problem. It is that I no longer have it that makes it so bad.
Read "Thinking, Fast and Slow" by Daniel Kahneman and you will become much more suspicious of sentiments like "I think it’s pretty easy to tell whether someone’s smart in casual conversation". We are actually extremely bad at guessing people's competences on first encounter, and very prone to cognitive biases such as the halo effect.
With no objective measures, it seems this method is likely to be subject to massive bias towards people that you just get on with or like for some reason.
I don't care either way. It doesn't get in the way of my curiosity, which takes me on plenty of rides regardless of my ability.
Of course, you need to give the person a chance to ramp up, etc, but if they can't be a contributing team member in 2 months, then it's better to give them 1-2 month's severance and get rid of them. I know one late-stage startup in the city that is using this technique, and I believe (not sure) that both Amazon and Netflix use this technique as well. It sucks, and kind of creates a bit of a harsh environment, but it's a fast way to build out your team, and probably has the same success rate as any other interview method, if not better because you cull your bad performers quickly.
I'm not saying that people who don't work out should not be let go, and I'm certainly not saying that you "owe" people anything. It's a business and not a charity. (Just remember that this goes the other way as well; people who show loyalty to some company are doing themselves a great disservice, in my opinion. I work for money. I'm passionate and will do great work, but I'm a mercenary.)
That being said, I would be very hesitant to go work at a place known to err on the side of just hiring someone and kicking them to the curb if it doesn't work out. Why? Because it can say a great deal about the management at that company, and how they will treat me. I also have no interest in being hired unless you are confident that I'm a great fit. I don't want anyone to take a chance on me. I want people to be delighted to hire me over someone else.
Edit fixed some typos.
Also I tend to work based on reference. I know a lot of computer science theory that I do not retain in RAM (so to speak). A little refresher on a topic brings a whole new set of knowledge into play than if it's just me and a whiteboard. I really don't mind doing interview coding exercises in my own time because it is much more natural and I think a fair representation of my abilities in the real world.
Discovering that someone is a poor programmer after you actually learn first hand that they are, may be a solution to the problem of aquiring a good team long term in a medium or large company, but it's not a solution to the problem of minimizing the risk of hiring ONE bad programmer.
Something like:
Here are two tables. How would you improve their design?
Now select all XYZ from them.
Now, here is a list/array of items and some search input, return a list/array with only those that match.
Finally, Fizzbuzz.
Total time of 5 or so minutes, and it will quickly eliminate those who have high charisma but no actual skills. This part can be replaced via a github account or such, but not everyone has one (or one they are willing to share with an employer/professionally tie their identity to).
Certainly it sucks from some people, but also, some developers would be very very uncomfortable casually talking with their prospective employer about things to prove they are smart.
We do white board coding, but failing a white board coding isn't an automatic no, it just goes into the pool of info we know about the person. But what I look for in a white board coding isn't someone remembering some obscure coding or that they write perfect syntax, but just to see how they can take an algorithm and turn it into code and whether they can step through their code.
All this bias against white board coding is kind of like a violinist saying I hate auditioning because the pressure of auditioning is nothing like playing in the orchestra. Yes its not, but its not unreasonable to have someone hear what you sound like live.
I hate the live coding exercise because I like to work how I was taught (back in the 80s). If I'm trying to implement an algorithm, I write pseudo-code then turn that into the appropriate language. I can rely on my editor to help with the syntax as I turn that pseudo-code into a actual code.
I could do this by just giving out a sample code and asking people to step through it, but I've seen difficulties with taking a spoken algorithm and turning it to code and I want to test that. I have seen some correlation between those struggles in interviews (its not a hard fail to fail the coding question) and in real life. I've discussed an approach with a coworker, then have them fail to write that into code that does what we discussed, just like they did in the interview.
I have thought about bringing in a computer but I feel there's an added stress to typing correctly with someone in the room. Our phone screen coding question (really really simple) is done on a collaborative web environment, but that's a really simple 5 minute question.
http://www.joelonsoftware.com/articles/GuerrillaInterviewing...
http://www.amazon.com/Smart-Gets-Things-Done-Technical/dp/15...
Well, it looks like I'm going to have to find better things to talk about...
Of course you want smart, curious people who can learn things and do stuff. These "guides" are just various elaborations of (sadly uncommon) common sense. There's no secret here.
I don't hold it against him. An ordinary young person being a young person. Nothing special. Nothing to be embarrassed about.
Also I don't think he cared about the hiring much - his specialty was never upper management.
I think the value of this is highly underestimated.