Comment by econgeeker | Hacker News Reader

Comment by econgeeker | Hacker News Reader

Parent Full thread

One of the key motivators that made me start my own company was this kind of nonsense. Poor managers, having made bad hiring decisions, are always looking for some way to short circuit the process. The entire recruiting agency industry exists for this very purpose (and look how little they know about engineering!)

This does provide a very useful feature for confident, quality engineers: Whenever someone asks for your github ID as part of the hiring process, you can say "Next!"

Seriously, you're an engineer. You can be choosy. And signs of pointy-haired boss syndrome are a good way to choose.

This is one of them.

The correct way to interview someone is to have a stakeholder in the business, who is a competent engineer, look thru the resumes, pick the ones they want to meet with, and bring them in. Talk to them, one on one, for about 30 minutes. (You should know after about 5 minutes, but you want to give them more time so they don't feel like they're being brushed off if you aren't willing to give them the job right then and there. Also, be ready to make an offer, or tell them you'll be making an offer, right then and there.)

If your startup doesn't have a stakeholder in the business whose competent enough to do this, then you still need your technical cofounder. Your technical cofounder cannot be "too busy" to interview engineers.

Frankly, I think you're out of your mind.

You should hire people based on absolutely as much useful information as you can ethically get your hands on. Why waste the information in a person's github profile?

Resumes suck, and are damned near useless. Bringing people in based on resumes wastes your lead engineer's time because the % hit rate on them will be very low. You will, at the very least, need to phone screen somebody that you only know from a resume, a process which takes a surprising amount of time.

Talking to people is totally useful, and necessary, but not sufficient. It's prone to passing bullshitters (esp since you have your best technical person interviewing) and useless smart people (who don't get shit done), and to failing good employees who don't speak well or are having a bad hair/brain day or are very nervous.

When you go to hire, use all the information you can. Look at their github, interview, have the person write code, have lunch with them to see if they get along with the team. Don't fail them for missing any one part of the interview, but take it all into account.

Especially in a small team, you're making an decision with an enormous impact on the future of your company which is difficult and painful to undo. Don't waste any information.

I find it interesting that you presume the hit rate on bringing people in based on resumes would be very low. I can tell a good engineer from a bad one, pretty well, using resumes.

Phone screens, however are a waste of time. It is difficult to establish rapport with someone over the phone, for both parties, and I've seen some people actually ask programming questions over the phone.

One very good engineer I hired, back before I was running my own show, did terrible on the phone screen.

I brought her in, though, because I saw something in the resume. She's asian and had a real problem talking on the phone, but eventually got the job and was great.

You are making a decision with an enormous impact. Therefore, it is critical that you do it based on a truthful assessment of the candidate-- not ideological prejudice.

I can tell a good engineer from a bad one, pretty well, using resumes.

I am reminded of a cartoon I once saw. It showed a businessperson meeting another in a typical office. The caption read "We really liked your resume and would be interested in meeting the person it describes."

Obviously you can select the good engineers a resume describes from the bad engineers a resume describes. What you cannot do from the resume alone is deal with false positives in the form of misrepresentations, nor with false negatives from people who are better at programming than they are at writing resumes.

You already know this, that's why you still have interviews. But I hope you can appreciate that additional information can help you pick out some red flags for the "good" resumes, thing you will want to ask about in an interview, and likewise a resume that doesn't seem all that great but is associated with good work on github.... Maybe that's a false negative and you want to interview them anyways to see if they simply suck at resume-writing.

I once was given a phone interview because a friend of mine knew the hiring manager. The manager really didn't want to waste time with me, he said, because I had just graduated from school, and thus I couldn't possibly be useful to him.

But at my friend's insisting, he gave me the interview, and summarily dismissed me.

A few weeks later the manager was fired from the company for some sort of unprofessional behavior, and replaced by someone who had just graduated from school.

I'm not sure the point you're making, but I should have said "phone interviews, at least for me, are a waste of time."

I would have brought you in face to face... a recommendation from someone already working there is a very valid positive signal.

Phone interviews aren't that bad, IMO, with proper use of http://i.seemikecode.com or something similar. But when there's a language barrier of some kind, they're definitely not going to be as useful.

Whenever someone asks for your github ID as part of the hiring process, you can say "Next!"

Yes you can, but your words do not convince me that this is a sound job-seeking strategy. You say:

...have a stakeholder in the business, who is a competent engineer, look thru the resumes, pick the ones they want to meet with, and bring them in.

To persuade me, you must establish that the companies with a strategy of "look thru the github profiles, pick the ones they want to meet with, and bring them in." Everything else, the thirty minute interviews and what-not, can be identical between the resume-driven filtering companies and the github-driven filtering companies.

I am not saying that selecting candidates on the basis of a github profile is superior to selecting candidates on the basis of resumes, or--even better--selecting candidates on the basis of either an outstanding resume or an outstanding code portfolio (my personal choice).

But your claim is that as a job-seeker, the best strategy is to refuse to interview with companies that select candidates to interview on the basis of their github profile or who want to discuss it in an interview. The onus is on you to establish that this is such an obviously unsound practice that you can infer that these companies are poor places to work once you receive an offer and accept it.

It is an obviously unsound practice because at its core is an ideological prejudice: We're going to judge you, not on the quality of your skills, but on whether you contribute to open source software or not.

Candidate are better off working for companies that are interested in getting to know them in order to make hiring decisions, rather than running them thru a political correctness filter.

I don't really care whether I convince you or not. I believe the basis for wanting someone's github id is a prejudice, and I've not had luck convincing prejudiced people that they shouldn't discriminate.

We're going to judge you, not on the quality of your skills, but on whether you contribute to open source software or not.

That's interesting. I don't see it that way, and neither do a lot of other people. Here's how I see it: Those people that do write code I can review provide me with more information than those that don't. They make my job easier. I judge the code, not whether the code is open source.

This is exactly the same phenomena as writing a readable resume, or blogging where I can read it. It increases their chances of being hired simply because they reduce the friction involved in the hiring process.

Now, does that mean that I will not hire someone who doesn't have a github account? No. It's my job to hire them too. But as an employer, it is remiss of me not to use all of the information available to judge hires. This is not prejudice, this is a business strategy.

Your words seem to indicate this is not a question of tactics and strategy. You introduce a lot of emotional rhetoric such as "political correctness." Frankly, I have NO idea what you are talking about, as Github has zero to do with whether one uses the word "bitch" in a presentation at a conference ;-)

I cannot read your mind, but in the conversation between you and I, YOU are the one introducing emotional baggage like "ideological prejudice," not me. I therefore suggest that if you want to stamp out all this zeal and prejudice, you start with YOURSELF. I am not the one claiming that people who write things I can read are or aren't better than those who don't. I am not the one with an axe to grind. I am simply a fellow trying to get my job done and looking for efficient and effective strategies for doing so.

" if you want to stamp out all this zeal and prejudice, you start with YOURSELF."

You're talking to the person, rather than the point. In fact, looking at your original response, it is constructed to do the same thing.

I'm done here.

I literally cannot believe that you have no interest in evaluating a programmer's code base for the purposes of a hire. That is so unbelievably counterintuitive and, well, just not very smart.

Reply on news.ycombinator.com