News for hackers. Stuff that matters.
Re:Lessons from 3,000 technical interviews by enjo on Wednesday December 28, 2016 @07:23PM (#13274843)
"Intellectual curiosity" was my primary attribute for many years. Particularly when I was young and didn't really know any better. It makes sense doesn't it? Someone who is interested in learning for learning's sake will be a better developer!

Except I'm convinced it's not really true. It's something that is horribly subjective and really self-selective. It's funny, intellectually curious people often have exactly the same interests as whomever is doing the interview. I find that nearly everyone loves to learn, you just have to find the thing they're interested in learning about.

The signal that I have found to be a great indicator of success on my teams isn't about curiosity at all. It's about attention to detail. In the world of scatter brained developers who never seem to really follow through on anything, it's those guys that are the real unicorns.

Our interview process is now designed to bubble that to the top. Vague programming problems with poorly defined requirements provide a platform by which we can see how someone digs into problems. I'll ask for them to send me a couple of things after the interview, it's a really good signal when they pull out their phone and add it to a to-do list.

Those guys may not always be the "smartest" or the most interesting, but man when you're going to spend months working down a really large project they get stuff done.

Re:Lessons from 3,000 technical interviews by tomc1985 on Thursday December 29, 2016 @12:41AM (#13275838)
You had me until, "it's a really good signal when they pull out their phone and add it to a to-do list."

Because it's just one of many possible courses of action for staying organized. For all you know the guy added it to his to-do list on his way to the car, or maybe he employs some other mechanic. While you could argue that an interview is a showboating environment where one is expected to signal certain desireable traits, I personally resent that these attributes seem to manifest in recruiters as specific actions that reinforce their perceptions of a good candidate -- if someone is unconventional then how is looking for specific signals going to tell you anything useful about them?

Re:Lessons from 3,000 technical interviews by enjo on Thursday December 29, 2016 @01:09AM (#13275926)
It's a signal. It's not a binary yes/no, there are many observations we're making throughout the interview. This is just one, and the to-do list isn't the only correct answer. Asking me to email those details to them is another possible right answer. Writing a note in a notebook is fine.

The key thing to remember here is that we're asking this very much in the middle of the interview, and I just want to see that they have some sort of system in place for remembering these things.

In my experience, most of the time, simply going "sure, I'll do that" and depending on memory to actually get it done is a negative signal. Maybe they are particularly gifted in terms of memory, but in my experience that is rarely the case.

In hiring we're willing to accept false-negatives, but never false-positives. You are correct, I may let a perfectly good candidate walk, but I'm willing to accept that as the cost of hiring a bad one is just too high.

Re:Lessons from 3,000 technical interviews by thecrazyone on Thursday December 29, 2016 @03:54AM (#13276367)
I sincerely think the downsides of a false positive are vastly overrated.

IMHO the real problem is the strict barrier between people who are part of company and non-company. Imagine if we had a more permeable membrane with different departments hiring firing as they see fit (a faster flow than this structured hiring). This would test the candidates on working in the real environment rather than the whole magic and mysticism of made-up work scenarios in interviews.

In fact I wish we had a more libertarian system inside companies with more free markets rather than all the central planning which happens now

Re:Lessons from 3,000 technical interviews by stolsvik on Thursday December 29, 2016 @03:07AM (#13276234)
I would not have written that down, but I can assure you that I would remember to send you whatever you asked: An interview setting is very special, and tend to get hyper focus. I wouldn't go out from there wondering the typical "man, that was intense - wonder how it went??", and then forget to send you those things you asked!

Unless your request was very specific and strange ("send me the completed k3-45 and t9807 forms"), in which case I'd have to jot /that/ down.

Should you not rather evaluate whether your request was fulfilled?

Re:Lessons from 3,000 technical interviews by enjo on Thursday December 29, 2016 @03:33AM (#13276305)
So the requests are often a bit strange (relevant to the interview tho). Usually asking for a citation for some claim made during the interview. I also make a point to ask in the middle of the interview so there's lot of times to forget.

Again I do want to stress: This is a small detail as part of a larger interview. Screwing this one thing up isn't going to sink you, but we combine it with a bunch of other signals and observations to make decisions. I've been doing this for several years, and I'm very happy with the results.

Re:Lessons from 3,000 technical interviews by hliyan on Wednesday December 28, 2016 @09:30PM (#13275309)
> It's about attention to detail. In the world of scatter brained developers who never seem to really follow through on anything, it's those guys that are the real unicorns.

I've done a few hundred technical interviews over the years and this is absolutely true. It's these guys who make production ready systems possible more than anybody else.

Re:Lessons from 3,000 technical interviews by throwaway_374 on Thursday December 29, 2016 @04:20AM (#13276426)
As it happens I have a poor temporal memory so the most important tool I have is I always carry my notebook and jot down everything that gets said, particularly as my previous role involved coordinating and managing teams and projects.