3 ms·

What about developers with little experience, that come right out of school, or are applying for an internship position? Are you going to cut them out of the pr

What about developers with little experience, that come right out of school, or are applying for an internship position? Are you going to cut them out of the process? If so, are you okay with the fact that you'll often be missing out on getting an early lead on good junior developers? Good developers rarely kick around on the job market, and so it's often much more difficult to hire them when they've become more senior. Joel Spolsky's take: http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html http://www.joelonsoftware.com/articles/FindingGreatDeveloper...

jnbiche 12y ago
I'm not suggesting to do this exclusively. By all means, hire promising devs out of college using the method the GP prefers. I'm just suggesting that when an applicant like this exists before you, it makes more sense (assuming you're happy with their accomplishments) to confirm that these are indeed their accomplishments than to try to cram in some ad hoc heuristic for determining their range of skills in an hour or two. And if my peers are any indication, the reason it's become so hard to hire senior devs is that no one wants to go through the headache of the interview process anymore once you've reached a moderately satisfactory job situation.
- shepardrtc 12y ago
  When I used to hire people, I focused more on their intelligence, their focus, and their motivation. Any idiot can google snippets of code or memorize answers to questions. What I wanted was someone that could handle learning what they don't know, motivate themselves to get the job done, and most of all, get the job done. And you can't figure those things out just by looking at a resume or by quizzing them for hours until they break. You have to actually talk with them. Engage them in conversation. Learn who they are and how they fit into this field. Learn about their past experiences and their future goals. Then the question as to whether or not to hire them is easy. Resumes are a starting point. Previous knowledge is a time-saver. Problem-solving and motivation is where its at. *As a side note, most of my interviews were 30 minutes or less. I only regretted one hire, and I got rid of him pretty quickly.
- mahyarm 12y ago
  Well if you want to be an innovator in that space, then you can offer an interview process that is more friendly to them. That means, no onsite interview processes that require taking vacation days to complete mostly. Or off hours interview processes.
RogerL 12y ago
Talk to them about school projects or classes. I recall one candidate was in a compiler class, and told me about the compiler s/he had working. I asked 'what's a recursive descent parser'. They didn't recognize the term. I asked what grammar the language had. They didn't know. Other's show excitement, talk about having had to study things on their own because it wasn't covered in class but they really wanted to learn it, and so on. You quickly get a sense of who has a fire burning and who is going through the motions.

jnbiche 12y ago

I'm not suggesting to do this exclusively. By all means, hire promising devs out of college using the method the GP prefers. I'm just suggesting that when an applicant like this exists before you, it makes more sense (assuming you're happy with their accomplishments) to confirm that these are indeed their accomplishments than to try to cram in some ad hoc heuristic for determining their range of skills in an hour or two. And if my peers are any indication, the reason it's become so hard to hire senior devs is that no one wants to go through the headache of the interview process anymore once you've reached a moderately satisfactory job situation.

shepardrtc 12y ago
When I used to hire people, I focused more on their intelligence, their focus, and their motivation. Any idiot can google snippets of code or memorize answers to questions. What I wanted was someone that could handle learning what they don't know, motivate themselves to get the job done, and most of all, get the job done. And you can't figure those things out just by looking at a resume or by quizzing them for hours until they break. You have to actually talk with them. Engage them in conversation. Learn who they are and how they fit into this field. Learn about their past experiences and their future goals. Then the question as to whether or not to hire them is easy. Resumes are a starting point. Previous knowledge is a time-saver. Problem-solving and motivation is where its at. *As a side note, most of my interviews were 30 minutes or less. I only regretted one hire, and I got rid of him pretty quickly.
mahyarm 12y ago
Well if you want to be an innovator in that space, then you can offer an interview process that is more friendly to them. That means, no onsite interview processes that require taking vacation days to complete mostly. Or off hours interview processes.

RogerL 12y ago

Talk to them about school projects or classes. I recall one candidate was in a compiler class, and told me about the compiler s/he had working. I asked 'what's a recursive descent parser'. They didn't recognize the term. I asked what grammar the language had. They didn't know. Other's show excitement, talk about having had to study things on their own because it wasn't covered in class but they really wanted to learn it, and so on. You quickly get a sense of who has a fire burning and who is going through the motions.