I always put up a mental barrier when reading articles such as this as I am of the opinion that it is difficult to successfully produce generalities about a subset of people unless you are quite intimate with their idiosyncrasies.
Philip Guo overcame this barrier in his article looking at the conversational behaviours of “geeks, nerds, and other highly-smart technical people”. These behaviours:
- Struggling with turn-taking.
- Obsessing over correctness and completeness.
- Preferring exact numerical responses.
- Using technical terms without checking for understanding.
- Focusing on the how rather than the what or the why.
- Favoring complexity and detail over simplicity in descriptions.
- Rapidly enumerating long lists of items.
- Showing a lack of interest in outward appearances.
- Evangelizing their favorite technologies.
The Hacker News thread discussing this article is also worthy of a casual look.
Richard Millington—online community builder for the UNHCR and one of Seth Godin’s 2008 interns—has compiled over 100 of his best posts from the previous two years.
There’s a wealth of valuable information at FeverBee and this list is a great introduction to the topic of community building. A few of the twelve categories Millington has used in organising his posts:
- Pre-Launch and Strategy
- Building An Online Community Website
- Increasing Participation
You could hire through open source like GitHub (“we hire ‘The Girl or Guy Who Wrote X,’ where X is an awesome project we all use or admire”) or use a check-list to recognise competency (passion, self-teaching, a love of learning, intelligence, hidden experience and knowledge of a variety of technologies) and no doubt find some fine programmers.
You could also take a similar approach to hiring marketers, writers, designers and those in many other industries, too. While this may guarantee competence, it does not guarantee success (business and/or interpersonal).
Combine the above with the approach Steve Jobs takes to interviewing (via Ben Casnocha) and you may be on to something (emphasis mine):
When I hire somebody really senior, competence is the ante. They have to be really smart. But the real issue for me is, Are they going to fall in love with Apple? Because if they fall in love with Apple, everything else will take care of itself. They’ll want to do what’s best for Apple, not what’s best for them, what’s best for Steve, or anybody else. […]
How do I feel about this person? What are they like when they’re challenged? Why are they here? I ask everybody that: ‘Why are you here?’ The answers themselves are not what you’re looking for. It’s the meta-data.
Take heed of how Aaron Swartz hires programmers using three questions (via kottke) and you’re likely to end up with the best candidate. Those three questions:
- Can they get stuff done?
- Are they smart?
- Can you work with them?
And to answer those questions:
- To find out if they can get stuff done, I just ask what they’ve done. If someone can actually get stuff done they should have done so by now.
- To find out whether someone’s smart, I just have a casual conversation with them. […] Under no circumstances do I ask them any standard “interview questions”.
- First, do they know stuff? Ask them what they’ve been thinking about and probe them about it. Do they seem to understand it in detail? Can they explain it clearly? […] Do they know stuff about the subject that you don’t?
- Second, are they curious? Do they reciprocate by asking questions about you? Are they genuinely interested or just being polite? Do they ask follow-up questions about what you’re saying? Do their questions make you think?
- Third, do they learn? At some point in the conversation, you’ll probably be explaining something to them. Do they actually understand it or do they just nod and smile?
- I figure out whether I can work with someone just by hanging out with them for a bit. […] The point is just to see whether they get on your nerves.
Whether or not you believe this to be (as Joel Spolsky does) the “best post […] about A/B testing, ever”, it definitely is one of the easiest to understand and one of the few posts on split testing that is statistically sound (i.e. useful).
Is [a given A/B test] conclusive? Has [variant] A won? Or should you let the test run longer? Or should you try completely different text?
The answer matters. If you wait too long between tests, you’re wasting time. If you don’t wait long enough for statistically conclusive results, you might think a variant is better and use that false assumption to create a new variant, and so forth, all on a wild goose chase! That’s not just a waste of time, it also prevents you from doing the correct thing, which is to come up with completely new text to test against.
Normally a formal statistical treatment would be too difficult, but I’m here to rescue you with a statistically sound yet incredibly simple formula that will tell you whether or not your A/B test results really are indicating a difference:
- Define N as “the number of trials.”
- Define D as “half the difference between the ‘winner’ and the ‘loser’.”
- The test result is statistically significant if D2 is bigger than N.
Update: Now even easier, thanks to the online split test calculator.
Written in early 2006 shortly after Disney’s acquisition of Pixar in a $7.4 billion all-stock deal, BusinessWeek looks at the relationship between the Disney and Apple CEOs and where their relationship may lead.
Prescient in that it accurately predicted the Apple TV and the iPhone, the article also briefly looks at Jobs and his product-first mindset:
“The great thing about Steve is that he knows that great business comes from great product,” says Peter Schneider, the former chairman of Disney’s studio. “First you have to get the product right, whether it’s the iPod or an animated movie.” […]
Time and again since, Apple has eschewed calls to boost market share by making lower-end products or expanding into adjacent markets where the company wouldn’t be the leader. “I’m as proud of what we don’t do as I am of what we do,” Jobs often says. […] “Quality is more important than quantity, and in the end, it’s a better financial decision anyway.”