4 ms·

I think in any field it's important to decide on the desired answer (from what traits and skills you need), then build the question. We use a scoring system (1-

I think in any field it's important to decide on the desired answer (from what traits and skills you need), then build the question. We use a scoring system (1-4) in our case and for each question the interviewer has several general bullet points the interviewee ought to be hitting on. For a simple example, if we're hiring for a desktop tech, we might ask what steps you take when troubleshooting an individual who claims their PC is slow. The desired answers might be: determine scope of problem (how often, how slow, is it affecting work duties), determine specific triggers, check PC for known issues (spyware, virus, etc), research, attempt resolution. We don't expect exact wording or even total coverage, but at least everyone is on the same page in terms of expectations. This has proven to be a very effective way of getting quality people into positions at a variety of levels. EDIT: Side note, we also generally build the interview questions, then write the ad. Since we already know the answers we want, the ad comes fairly naturally from that.

csydas 10y ago
Though I've been hiring for much smaller institutions, I can attest that this is a common problem for virtually all hiring processes: > I think in any field it's important to decide on the desired answer (from what traits and skills you need), then build the question. My previous job liked to hire by committee that was created by randomly selecting employees to participate with hiring. (already a mistake) Even though these included the department head actually hiring, we'd often find that most of the time in meetings was spent asking or telling each other what was "really" necessary for the job, since even if we had a solid job description and list of wants, the committee members would squable since the jobs were allowed to be too flexible. When it came time to design questions, we would run into the same problem each time: We were more focused on "good questions" than deciding what we really wanted the answer to be and designing questions around it. This often resulted in really poor interviews where we let applicants just talk their way through any of our concerns because there was no concrete idea of what we were looking for. I think in general this tends to be an issue with employers who have difficulty with hiring - they are not good at articulating their wants beyond "we need a web developer" or "database admin" - undoubtedly it's managers who were told "don't get too specific with your wishlist", the idea being to prevent job postings with absurd requirements, but it's swung too far in the opposite direction in many cases with employers relying exclusively on keywords as indicators of success. ("They know X language and have worked with Y hardware - they're perfect") The hard truth is that even though hiring sucks and can take forever if you're not careful, it's worth taking the extra prep time to ensure you have a clear idea of the type of hire you want. Anything less is a disservice to your company, your employees, your customers, and your new hire. The HR hatchets are generally not useful either, as they're too broad sweeping and the same tools that weed out the absolutely unqualified also end up weeding out those who haven't jammed the right keywords into their resume. Neither ends up getting you what you want; while it's shitty to have to read potentially dozens or hundreds of resumes, if you're struggling to fill positions with good people, it's a necessity.

csydas 10y ago

Though I've been hiring for much smaller institutions, I can attest that this is a common problem for virtually all hiring processes: > I think in any field it's important to decide on the desired answer (from what traits and skills you need), then build the question. My previous job liked to hire by committee that was created by randomly selecting employees to participate with hiring. (already a mistake) Even though these included the department head actually hiring, we'd often find that most of the time in meetings was spent asking or telling each other what was "really" necessary for the job, since even if we had a solid job description and list of wants, the committee members would squable since the jobs were allowed to be too flexible. When it came time to design questions, we would run into the same problem each time: We were more focused on "good questions" than deciding what we really wanted the answer to be and designing questions around it. This often resulted in really poor interviews where we let applicants just talk their way through any of our concerns because there was no concrete idea of what we were looking for. I think in general this tends to be an issue with employers who have difficulty with hiring - they are not good at articulating their wants beyond "we need a web developer" or "database admin" - undoubtedly it's managers who were told "don't get too specific with your wishlist", the idea being to prevent job postings with absurd requirements, but it's swung too far in the opposite direction in many cases with employers relying exclusively on keywords as indicators of success. ("They know X language and have worked with Y hardware - they're perfect") The hard truth is that even though hiring sucks and can take forever if you're not careful, it's worth taking the extra prep time to ensure you have a clear idea of the type of hire you want. Anything less is a disservice to your company, your employees, your customers, and your new hire. The HR hatchets are generally not useful either, as they're too broad sweeping and the same tools that weed out the absolutely unqualified also end up weeding out those who haven't jammed the right keywords into their resume. Neither ends up getting you what you want; while it's shitty to have to read potentially dozens or hundreds of resumes, if you're struggling to fill positions with good people, it's a necessity.