3 ms·

Glad to hear he hasn't given up. I agree with his basic thesis that much of software engineering hring is a cargo-cult shitshow. But I haven't given up hope and

Glad to hear he hasn't given up. I agree with his basic thesis that much of software engineering hring is a cargo-cult shitshow. But I haven't given up hope and have worked on developing a hiring process that is human, efficient, and effective. I've outlined it here before. Been using it and tweaking it for the last 3 or 4 years. I keep bring it up because it's a tested alternative to the usual death marches and dumpster fires and it has been a success for the teams I've led and our applicants. The principles I've defined to guide our process[0]: - Hiring cycles will be structured and as short as possible. - When we start a hiring cycle, we will finish it by hiring the most qualified applicant who accepts our offer. - Every applicant will receive a response within 48 hours and be updated on the status of their application at each step asap. - The hiring process will be as transparent as possible. - Objective and fair-minded measures will displace biased and bigoted ones. - Every applicant will appreciate their experience, even the rejected ones. - The process will be agile and adapt over time to improve and meet the specific needs of the organization. - Onboarding will begin with hiring. One problem I'm confronting at the moment. As our company grows, we've brought on a new HR lead who wants to jam the process we've been refining over the last couple years into a new ATS (Applicant Tracking System) that could significantly screw up our meez. We'll see how that works out. I'm doing everything in my power not to let it fall apart. If you have the power to improve the situation, please do so. [0] For an outline of the process, see https://wiki.klenwell.com/view/Hiring https://wiki.klenwell.com/view/Hiring

andrewflnr 7y ago
How do you design your coding challenges? Can you give examples?
- klenwell 7y ago
  Sure. We start by noting in our job description that there will be a coding challenge -- on a laptop, not a whiteboard. Most of our work is on web applications, primarily Rails. So, for that role, the challenge is to fix an issue in an implementation of Fizzbuzz on our sandbox Rails app. We give the candidate about an hour to work on it. It's not as trivial as the common Fizzbuzz exercise but it's a pretty representative sample of the kind of work we do. As part of the phone screening, we check to make sure the candidate understands there will be a code challenge involving Rails and that they're cool with that. There's a handout we present before we turn over the laptop that explains the issue and clearly defines requirements (e.g. create a branch with this name). We read a brief intro section then give the candidate time to review the requirements on their own and ask them if there are any questions. Candidates are reminded to read the README included with the project and encouraged to use the browser to Google stuff. One tweak we made was to add check-in stages to the challenge to make sure candidate doesn't get stuck for a half-hour trying to open up the text editor or something. Every 15-20 minutes, a team member will check in with candidate and if they haven't hit a certain milestone (e.g. has started local server or had reproduced issue), we'll assist them in getting to it. At the second or third check-in, it usually turns into more of a pair programming exercise and at the end we'll review the solution with candidate so they understand why the problem is relevant to the job. There's not a definitive pass or fail for the challenge. The candidate's performance gets scored on a simple 1-5 scale alongside the other competencies we're evaluating as part of the interview. We're pretty thorough about preparing the code challenge and consider it a good example of our "onboarding begins with hiring" principle.
  - insomniacity 7y ago
    I like the milestones/check-in idea - will have to use that next time around.

andrewflnr 7y ago

How do you design your coding challenges? Can you give examples?

klenwell 7y ago
Sure. We start by noting in our job description that there will be a coding challenge -- on a laptop, not a whiteboard. Most of our work is on web applications, primarily Rails. So, for that role, the challenge is to fix an issue in an implementation of Fizzbuzz on our sandbox Rails app. We give the candidate about an hour to work on it. It's not as trivial as the common Fizzbuzz exercise but it's a pretty representative sample of the kind of work we do. As part of the phone screening, we check to make sure the candidate understands there will be a code challenge involving Rails and that they're cool with that. There's a handout we present before we turn over the laptop that explains the issue and clearly defines requirements (e.g. create a branch with this name). We read a brief intro section then give the candidate time to review the requirements on their own and ask them if there are any questions. Candidates are reminded to read the README included with the project and encouraged to use the browser to Google stuff. One tweak we made was to add check-in stages to the challenge to make sure candidate doesn't get stuck for a half-hour trying to open up the text editor or something. Every 15-20 minutes, a team member will check in with candidate and if they haven't hit a certain milestone (e.g. has started local server or had reproduced issue), we'll assist them in getting to it. At the second or third check-in, it usually turns into more of a pair programming exercise and at the end we'll review the solution with candidate so they understand why the problem is relevant to the job. There's not a definitive pass or fail for the challenge. The candidate's performance gets scored on a simple 1-5 scale alongside the other competencies we're evaluating as part of the interview. We're pretty thorough about preparing the code challenge and consider it a good example of our "onboarding begins with hiring" principle.
- insomniacity 7y ago
  I like the milestones/check-in idea - will have to use that next time around.