I feel rather silly commenting as a voice of dissent here, against a man who cannot defend himself, but here goes.
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.
Taking a different view here. The best ideas seem obvious in the future. I thought he was very clear articulate in how he does his hires (he would be the hiring manager here). While yes the manager needing help answers the "who" part of the hiring question, Aaron answers the "how".
> I feel rather silly commenting as a voice of dissent here, against a man who cannot defend himself, but here goes.
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.
I see you being downvoted. This doesn't seem right to me in that I agree with you completely, so implicate myself with this comment to show my support.
You really are speaking ill of the dead. Calling him a self-promoter and a loose cannon isn't appropriate.
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.
Burglary is theft of valuables. What was stolen? Data was copied, not erased. The moral ownership of that data is by the many authors who were never reimbursed. JSTOR is a scam.
Burglary isn't theft. Burglary is breaking into a place you don't have permission to enter, with the intent to commit a crime. If you then commit that crime (whether it's theft, vandalism, destruction of property, etc.) you are usually charged with that other crime alongside the burglary charge.
Ok so lets focus on the act of breaking in, though there was no financial loss. Lets ignore the fact that he could have obtained everything without "breaking in" if he did so at Stanford. It's clear to me that in Aaron's mind, he was not breaking in. A laptop in an unlocked cabinet is not really breaking in.
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.
> 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:
Working out whether someone is smart or not on the basis of how an entirely informal conversation goes makes you extremely vulnerable to biases.
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.
Do you think, perhaps, after being aware of these biases it makes it easier to determine someone's "smartness" based on a sequence of interactions as described in the article?
Side anecdote: I get the feeling I'm judged as less capable mentally in person. I wonder whether it's because of my appearance, my voice or perhaps because I am less capable mentally. Confusing world to live in when I get such conflicting information.
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.
I think the most effective way to hire is to do your best without giving into to grueling whiteboard interviews, and take a chance on someone who seems smart. But also fire the person quickly if it seems like they won't be a good fit. After spending years interviewing people, this is the best conclusion I've come up with, because nothing else works as conclusively. Yes, it's brutal, and a bit ruthless, but effective. Whiteboard interview questions are a terrible measure of whether someone will be able to contribute. Same goes for the other types of interview questions.
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.
This is an interesting perspective. I know that whiteboarding is the worst possible technique to personally face in an interview because of how my thought and creative processes work. Mostly I come to a new problem, explore it a bit, let myself do some background processing while I do something I know how to do in my sleep and then tackle the new problem. This is way more productive for me than dealing with the problem straight up where I would take the same about of time getting frustrated with the new problem while not doing anything productive.
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.
> Yes, it's brutal, and a bit ruthless, but effective.
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.
I guess I have the opposite stake on this. I'm a junior dev and I've been interviewing multiple times a week for the last month and a half. I've gotten better at interviewing but I still mess up on something and remember later on what the answer was. Now I get passed on the job because I failed the interview.
I would rather an employer take a little chance on me and let me prove that I'm a competent developer and a hard worker. I would rather prove that on the job instead of in an interview.
You are forgetting that the ability to fire people for performance are very limited in many situations. That places some constraints on it. For example, in many countries it's very hard to fire someone for performance reasons. The same also applies everywhere, for first hires in young companies. You just can't make a mistake.
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.
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).
I think the assumption that white board coding is the worst way needs a bit more evidence.
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.
There's a big problem with that analogy. With auditioning, you're doing the same thing you'd do professionally with basically the same tools. But, with whiteboard coding, you're doing it in a completely different environment. When I'm coding, I'm on a computer where I have access to a variety of tools and resources. Plus, you generally don't have someone evaluating you on the spot when you're coding. You have time to reflect. With a musician, you'll be performing and evaluated live which is very similar to an audition.
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.
Late reply. I am fine with pseudo-code in the coding question. I just want to know that the candidate can visualize an algorithm and get it into something concrete. Then be able to step through the code and tell me how the state of the machine will change.
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.
As I'm going through a new round of job interviews, this article resonates well. It's kind of sad watching (and being subjected to) some otherwise great companies still going at it the old way as described in the second paragraph.
>"If you ask people at parties to name their greatest strengths and weaknesses or to estimate the number of piano tuners in Chicago, you’ve got bigger problems."
Well, it looks like I'm going to have to find better things to talk about...
Really? So just have a nice conversation and ask questions?
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 think the three questions are his main focus. Having a nice conversation and asking questions is just the example method used to determine the answers. It's not revolutionary, but showing that individually they are all necessary but not sufficient conditions was novel to me.
> Whether code is concise, clear and elegant has not been causally related to success, unless that's how you define success, which is not how the market defines it. Reductio: The brain is neither concise, clear nor elegant (as far as we can tell), but it is usable and furthermore it works. It successfully extracts value.
Sure, but success is a continuum not a binary switch. Who is to say that the brain could not have been more successful if it was more clear and concise? A body of experience points to code that is not clear and concise being much harder to maintain. True that it is not as good as having hard experimental evidence, but it seems silly to say that demanding code be clear and concise is purely egotistical.
> News flash, everyone is smart, some people just aren't as assertive as you, or aren't yet as educated. You could hire them and educate them, but you are so concerned about short term profits that you fail to invest in people, who are inherently valuable and can do anything they set their minds to.
I have to disagree with the statement that everyone is smart, but ignoring that, what is wrong with not wanting to train people? If I had to choose between someone who knows the material now and someone who could know it by the end of the year, I would choose the clearly more qualified candidate. If Aaron was complaining about a lack of talent to hire, I could understand blaming him for not investing in people, but he does nothing of the sort. The entire article is him explaining the process that works for him -- so why would he want to change a working process?
> Let's select against all the people we don't like by not giving them jobs.
Well, of course. If you start hiring people you don't like, then you will have major problems working with them. As Aaron says, "Someone you can’t work with, you can’t work with". I fail to see what the alternative would be in this case.
Here is another Massachusetts resident whose life Carmen Ortiz has destroyed that I just read about this week. She finally brought federal drug distribution charges against a family doctor after he lived under a cloud of suspicion during a 7 year "investigation." He was acquitted of all charges:
http://needham.wickedlocal.com/article/20150515/NEWS/1505171...
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.