4 ms·

Let's say I'm trying to find the top 10% of software engineers and I'm willing to pay for it. I'm interviewing a 55 year old candidate. What kinds of questions

Let's say I'm trying to find the top 10% of software engineers and I'm willing to pay for it. I'm interviewing a 55 year old candidate. What kinds of questions should I ask and how should I evaluate if they are really that good? (Let's say I'm hiring at Slack, to make it more concrete). I agree with your sentiment but struggle with the question above.

7Figures2Commas 11y ago
1. Walk through in real detail the candidate's past work. This requires preparation on your part, as you will need to review the candidate's past work, any code samples, etc. If you do your homework and manage the conversation well, it will be very difficult for someone faking it to get through. 2. Present one or two real-world challenges related to the work the candidate would be doing for you and talk about how he or she would solve them. If the candidate wants to draw or write code on a piece of paper or white board, fine. But this should be a conversation, not a test. 3. Although they aren't always viable, contract-to-hire relationships are your friend.
randcraw 11y ago
Ask an older candidate, in their experience, which tech or management practices work and which don't. Ask them why they think so. You can learn a lot about the depth of someone's understanding of the full engineering process: reqs & specs, design, implementation, test, maintenance. Among the places the candidate has worked, ask them about the strengths or weaknesses of various approaches and techniques. Ask for war stories that were learning experiences. Ask for their thoughts on which of these might be relevant within your company (or given a certain set of synthetic but plausible relevant constraints). In practice, a really large fraction of software dev practices, especially in the early phases like requirements and design, have long been suboptimal. (I'm being kind, of course.) But few bemoan this because, formally, few agree about how to correct it, largely because business problems vary widely. However if someone smart works in business long enough, and they pay attention to more than just their own code, they usually learn a lot about which approaches serve their business well and which don't. That wisdom is the greatest strength of an experienced developer/engineer. Explore that in the interview, and not just how they would code a red-black tree template in C++ on a whiteboard.
vitd 11y ago
Here are some things I've done recently that seemed useful: 1) Rather than ask them to code something, give them some code and have them review it. I opened up a browser and went to code review.stackexchange.com and picked one in the interviewee's favorite language. 2) Have them show you code they've written. It doesn't have to be from their current job, which would probably violate their employment agreement, but they've probably written some side projects for fun, or worked on some open source, or something. 3) Discuss problems they've actually solved and how they approached it. What did they try that didn't work? Why did they choose the solution they did? Did they consider anything but not try it? If so why didn't they try it? That way you're not testing their ability to write unrealistic code (who writes their own linked list?) under ridiculous time pressure (less than 1 hour); you're not bringing on test-trauma that wouldn't affect them in their real job, etc.

7Figures2Commas 11y ago

1. Walk through in real detail the candidate's past work. This requires preparation on your part, as you will need to review the candidate's past work, any code samples, etc. If you do your homework and manage the conversation well, it will be very difficult for someone faking it to get through. 2. Present one or two real-world challenges related to the work the candidate would be doing for you and talk about how he or she would solve them. If the candidate wants to draw or write code on a piece of paper or white board, fine. But this should be a conversation, not a test. 3. Although they aren't always viable, contract-to-hire relationships are your friend.

randcraw 11y ago

Ask an older candidate, in their experience, which tech or management practices work and which don't. Ask them why they think so. You can learn a lot about the depth of someone's understanding of the full engineering process: reqs & specs, design, implementation, test, maintenance. Among the places the candidate has worked, ask them about the strengths or weaknesses of various approaches and techniques. Ask for war stories that were learning experiences. Ask for their thoughts on which of these might be relevant within your company (or given a certain set of synthetic but plausible relevant constraints). In practice, a really large fraction of software dev practices, especially in the early phases like requirements and design, have long been suboptimal. (I'm being kind, of course.) But few bemoan this because, formally, few agree about how to correct it, largely because business problems vary widely. However if someone smart works in business long enough, and they pay attention to more than just their own code, they usually learn a lot about which approaches serve their business well and which don't. That wisdom is the greatest strength of an experienced developer/engineer. Explore that in the interview, and not just how they would code a red-black tree template in C++ on a whiteboard.

vitd 11y ago

Here are some things I've done recently that seemed useful: 1) Rather than ask them to code something, give them some code and have them review it. I opened up a browser and went to code review.stackexchange.com and picked one in the interviewee's favorite language. 2) Have them show you code they've written. It doesn't have to be from their current job, which would probably violate their employment agreement, but they've probably written some side projects for fun, or worked on some open source, or something. 3) Discuss problems they've actually solved and how they approached it. What did they try that didn't work? Why did they choose the solution they did? Did they consider anything but not try it? If so why didn't they try it? That way you're not testing their ability to write unrealistic code (who writes their own linked list?) under ridiculous time pressure (less than 1 hour); you're not bringing on test-trauma that wouldn't affect them in their real job, etc.