Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

I’m not sure who originally told us about the Sunday test and the Caller ID test, but if they remind me I would certainly like to thank them. These two very simple ideas have kept us from making some very bad hires, and have convinced us to make others that were great. The Sunday test is as follows: if the candidate is in at the office alone on a Sunday afternoon, would you be more likely to come in and work with them? That answer has to be yes. We want to be excited by our colleagues, and not feel like we’re holding them up or they’re dragging us down. The Caller ID test is equally important, and is as follows: if the candidate calls you on a Friday night and wants to spend time hanging out or working, are you more likely to pick up or let it ring to voicemail? If you wouldn't pick up the phone, that candidate is the wrong hire.

Argh. These rules are toxic. You are unlikely to predict your best hires. A lot of evidence suggests that engineers are uniformly bad at making subjective judgements about future performance. The "Sunday" and "Caller ID" rules basically put a deceptive veneer on the most subjective of all criteria: the "gut check".

That's bad enough, but both rules also have a pernicious culture effect. In companies full of 20-something Red Bull drinking 11a-9p gamer nerds, the rule gets you more gamer nerds. In companies full of 30-somethings with kids, you get more people with kids. This is exactly what you don't want to have happen; a real culture adapts to any positive competent person you find. Good cultures figure out down the road how to get people to hang out outside of work. They also accept people who just don't want to spend their out-of-work time with their officemates. Why would you want to filter those people out? That property has no known correlation to ability or performance.

Finally: do you really want to be the hiring manager who says out loud that you have a rule built into your hiring process that involves people working on Sunday? Don't make people work on Sunday.

The sooner we kill the "Sunday rule", the better.

I agree completely. I've worked with a range of people across a pretty broad "social spectrum" (from very close friends, to acquaintances, to family etc.) but the one guy I've worked with the longest was from a random job ad and, although we get along just fine, we're completely different people. In fact, because of that I have learned a lot that I probably otherwise wouldn't have.

This is an interesting take. For us, it's not about age, but about personality. We have a financial controller who is 20 years older than everyone else on the team and we'd bring her on full-time in a heartbeat if we needed a full-time controller. She has a great personality, is fun to have in-house, and knows what she's doing.

How I look at the Sunday test is less of a "are they like me" and more of a "will I get along with them many hours a day"? We work anywhere from 7 hours a day, up to 18 (especially during major code pushes) - we try to avoid this as much as we can, but sometimes (for us at our stage), it's inevitable.

I do have to enjoy working with my colleagues, and someone for whom I won't be willing to come in on a Sunday has a higher chance of bringing me down on a regular basis. That doesn't mean we work Sundays (we're typically in the office M-F), but it's important to be able to get along with people and it's a good litmus test, imho.

I'm not here to tell you to hire people you don't get along with. But you shouldn't regiment hiring rules that are based on things like "culture fit" or "getting along", because they code for subjectivity and culture bias.

You should certainly rule out people who are disagreeable, or who immediately send signals that they'll be logistically difficult to work with. But you should base those decisions on some kind of objective metric. That requires some up-front thought: what are core hours? Do we avoid meetings and thus require lots of continuous written feedback? Do people need to be comfortable with our chat system?

But as you think of those metrics, start to worry when you get to things like "will this person usually be available to review code prior to deployment on a Saturday night?".

I'm the opposite. I don't want to work with people who I "get along with". I want to work with people who will tell me I'm an idiot when I do something idiotic. I want someone who puts all their effort into creating great technology, not someone who puts all their effort into being liked. I have thick skin, so it doesn't bother me to work with an abrasive person.

That, of course, only applies to programmers. On the other hand, if I'm hiring a salesman, I'd want that person to be the kind of person who puts all their effort into being a likable person. The same goes for hiring managers. Being a likable person will get you far in many positions in a business. Programming is not one of them.

We all have thick skin at Tinfoil - we don't want to hire someone who is necessarily liked by everyone, or who won't tell us what is on his/her mind and be honest. We're incredibly transparent, and whether or not we like someone is certainly not the /only/ reason we would hire someone. Honesty and straightforwardness is a trait we value a lot.

For some reason this thread makes me think of this old HN thread:

https://news.ycombinator.com/item?id=2030433

'iamelgringo (who I miss!) is telling me that just because I feel like I get a good night sleep on 5 hours or whatever it is I get, doesn't mean my sleep quality isn't horrible due to apnea, and that maybe over the long term the apnea might kill me.

I think it's the same with hiring. Everyone thinks they do it well; you look around you, feel like you like everyone you work with, and then write up the process that got you there. What's dangerous is if your current success is a fluke, and the process you set up is a recipe to become insular, or a stepping-stone job for SFBA people, or (worst of all) one of those companies you can't work for if you're a mom --- and I know you personally don't want to be any of these things!

You are awesome and I'd love to work with you someday. I just hate the way you say you hire. :)

Unless a person is at one extreme or the other (on a trait spectrum), I'm not sure I'd be able to tell based on an interview (or series of interviews) whether I would want to hang out with him/her on a Sunday. An extrovert who reads as "fun" within a few minutes may be someone you know immediately you'd like to hang out with. What about the person who is an introvert and reads as "fun" within a few hours, days, weeks. . .? Within a few weeks, you would have realized this is someone you could work with, but you would have already made the decision not to hire this person,

Our interview process isn't 'standard.' It probably isn't scalable to a company of 100, but right now we don't bring a person in for an hour. A few of us are definitely introverts, and it's not about "liking someone" necessarily, it's about being excited to be around them and work with them.

  |  it's not about "liking someone" necessarily, it's
  | about being excited to be around them and work with
  | them.

That's just another way of saying "liking someone." You can "like someone" for a variety of criteria.

Having to work 18 hour days is an inevitable consequence of working 18 hour days.

Unlike tptacek, I love the "Sunday test", because it acts as a filter for me -- I'd never work at a place where that question was asked in a non-sarcastic way.

I have to admit though that I don't really get why you'd use the "Sunday test" and the "Caller ID" test, since both are differently worded ways of gauging exactly the same thing. Seems like you could simplify it down to the "Is this guy (or girl) an asshole or what?" test, but I guess just asking it outright like that doesn't give you the same process-hipster cred of having heard of these other "tests".

You're right, and that is the intent of the tests. We don't ask that question of candidates at all, and I just updated the post to clarify that.

It's not about 'process-hipster cred' - most people who know me will tell you I don't give a shit about anything like that. It's about having questions to keep in mind when evaluating a candidate and your ability to work with him/her. "Is he/she an asshole?" is one such question, but these are others that we have found to work well.

A lot of times when companies say "getting along with us" is an important train in candidates, it often gets manifested as "agrees with us on everything" in practice. In other words, the only way to really fail the "Sunday test" is to disagree with the boss on one too many occasions.

(I work with/for Borski)

Disagreement is one of the things that I think we tend to be pretty open with at Tinfoil. Not everyone has to agree with a decision, but they always get airtime to voice any concerns and for those to be addressed or at least considered/acknowledged.

I met these guys at a party once. (I'm in Mountain View)

I ended up ranting at the CEO and CTO about how their hiring practices were excluding the best people because they were treating candidates like their time is free. The claim was that they wanted to hire the best people, yet their hiring practices were dissonant with this.

They said it was an acceptable trade-off to not have access to the best people in order to ensure they got people that were going to do whatever they asked them to do. At the time they were trying to hire a designer, but the practices carried over into engineering hiring too.

They want people too foolish to value their time, yet smarter than them. Riding that knife's edge isn't easy.

The rules are incredibly shallow. And to blog about them this way seems narcissistic. I hope the community takes this post as informative so prospective employees so they can steer clear well in advance.

Fair enough, you've said what not to do. What would you recommend instead?

Reply on news.ycombinator.com