3 ms·

I think the hardest part is getting some kind of hiring flow anyway. Knowing who to contact is the biggest obstacle. But once you've got someone... First: ac

by ibejoeb 10y ago

I think the hardest part is getting some kind of hiring flow anyway. Knowing who to contact is the biggest obstacle. But once you've got someone... First: actually read the resume and letter. Learn about the experience this person has. Unless you're hiring out of a bootcamp, the candidate has worked on something and you should not be walking in blind. (If he or she hasn't articulated it in the resume and letter, then I wouldn't expect to have initiated an meeting.) I don't use challenges, homework, riddles, quizzes, etc. anymore. Again, we're not starting from scratch. I hear it and wonder, "Do you really think I haven't yet figured out the difference between fifo and lifo?" (Or, "Here's a little, 5-minute challenge. Just a little date math." Oops. Forgot the leap second.) I focus on problem decomposition. I ask about problems that the person has worked on. I talk about my own systems and have him or her opine on it. We brainstorm. These discussions get into things like: * What was the situation? Why was it a problem? Was the solution obvious? Was is tricky to intuit, or was it a lot of work to implement? * What were your constraints? Were they natural or derived? (Perhaps it was a very-low-resource environment, or there was real-time requirement, or it needed resistance to a type of attack, or it required strict regulatory compliance.) * What was the mental model and how did the individual arrive at it? Did it change during implementation? This structure has worked for me at most levels of hiring. I can ask a very junior person who, say, writes SQL to generate reports to talk about a particularly challenging report, or one that is particularly elegant. If he says, "I changed the order of operations to get the rows down from 4 quadrillion to 400,000" then I know that, conceptually, he knows about cardinality. I can ask a director to talk about a project that he ran with a remote team in the same way. If the drop has to happen in sync and you have people in 4 time zones spanning 10 hours, did he wake people up or did he use some kind of technological orchestration? Also, I think it's worth noting that quite a few very good programmers do not keep very public profiles, so I really don't trust the greenness of a github profile.

Throwaway23412 10y ago
>First: actually read the resume and letter. Learn about the experience this person has. >I don't use challenges, homework, riddles, quizzes, etc. anymore. Unless you don't get many resumes, I find it hard to believe that this is a good hiring flow for you at all. A lot of people who agree with me will often say that nobody has time to be reading hundreds or thousands of resumes, but I'll take it one step further: unless you are rigorously verifying the information on resumes, resumes are basically useless. It is way too easy to lie on a resume. I don't mean mere embellishment or exaggeration. I mean straight-up lying. I looked at your profile. You have an impressive resume. What would stop me from copying your resume and submitting it as mine? Your impressive positions would be harder to fake, so I'd just lower all the CTO, head, VP, and chief titles to lower level titles. Let's take this even further. Let's pretend that you actually call the references for the positions on all the resumes that you read. What's stopping an applicant from giving you a friend's number and having them pretend to be their former manager/employer? One could argue that the same sort of deceit works for challenges, quizzes, etc., but there's the additional barrier of at least knowing a decent enough programmer who can take the challenge or quiz for you.
- throwaway_374 10y ago
  You're hiring a CRUD programmer to wire together a few processes and write test, not a brain surgeon or a rocket scientist. You're not Space X, 90% of CVs you see could probably do the day to day job you require. Get real.
- holyOrIonsBelt 10y ago
  I have to respectfully disagree. The poster above you is not saying that they don't verify, they say they verify through different means. They are saying, in my opinion, that it is important to step away from the S.O.P. because by doing so we gain the clarity of insight from treating them not as cogs to fill a gear ratio, but as human beings that bring an enormous range of abilities that, for various reasons, may not communicate unless one allows them to, hence the example of a root reduction in the db search space.
- ibejoeb 10y ago
  You raise the practicality of doing things this way, and you're right about the required effort. When I was in a larger organization, I set aside a week at time to get people in the door and talk to them. It was tough talking 6 or 7 people a day for an hour each, but I think it's worth the effort when you really need to bring on people. Sure, you can copy a resume and you might get a phone call, but I suspect we're not going to have a very good conversation.

by ibejoeb 10y ago

Throwaway23412 10y ago

>First: actually read the resume and letter. Learn about the experience this person has. >I don't use challenges, homework, riddles, quizzes, etc. anymore. Unless you don't get many resumes, I find it hard to believe that this is a good hiring flow for you at all. A lot of people who agree with me will often say that nobody has time to be reading hundreds or thousands of resumes, but I'll take it one step further: unless you are rigorously verifying the information on resumes, resumes are basically useless. It is way too easy to lie on a resume. I don't mean mere embellishment or exaggeration. I mean straight-up lying. I looked at your profile. You have an impressive resume. What would stop me from copying your resume and submitting it as mine? Your impressive positions would be harder to fake, so I'd just lower all the CTO, head, VP, and chief titles to lower level titles. Let's take this even further. Let's pretend that you actually call the references for the positions on all the resumes that you read. What's stopping an applicant from giving you a friend's number and having them pretend to be their former manager/employer? One could argue that the same sort of deceit works for challenges, quizzes, etc., but there's the additional barrier of at least knowing a decent enough programmer who can take the challenge or quiz for you.

throwaway_374 10y ago
You're hiring a CRUD programmer to wire together a few processes and write test, not a brain surgeon or a rocket scientist. You're not Space X, 90% of CVs you see could probably do the day to day job you require. Get real.
holyOrIonsBelt 10y ago
I have to respectfully disagree. The poster above you is not saying that they don't verify, they say they verify through different means. They are saying, in my opinion, that it is important to step away from the S.O.P. because by doing so we gain the clarity of insight from treating them not as cogs to fill a gear ratio, but as human beings that bring an enormous range of abilities that, for various reasons, may not communicate unless one allows them to, hence the example of a root reduction in the db search space.
ibejoeb 10y ago
You raise the practicality of doing things this way, and you're right about the required effort. When I was in a larger organization, I set aside a week at time to get people in the door and talk to them. It was tough talking 6 or 7 people a day for an hour each, but I think it's worth the effort when you really need to bring on people. Sure, you can copy a resume and you might get a phone call, but I suspect we're not going to have a very good conversation.