You've done an excellent job exposing that many systems are designed to whittle the candidate pool down with knock-out questions, but I'm not sure that I wholeheartedly agree with the splitting of requirements into even thirds directly.
That even-thirds technique is dangerous when, for example, the company has a basic job template and the hiring manager adds their real position requirements to the bottom of the list. I've watched managers do this. A candidate following your even-thirds split would lie outright about the most important requirements on that type of job post.
Perhaps a strategy to complement the even-thirds would be to reorder the list of requirements by specificity. Something generic like "object-oriented programming" should fall to the bottom, while requirements like "Enterprise Java Beans" or "Web Framework: Spring, Jersey" should rise higher in the list. I figure that the more specific a requirement is, the more likely it applies to that position. (And on that note, I would run the opposite direction of anyone talking about EJBs in 2021.)
Now for a personal story: Much earlier in my career, I recognized the knock-out questions in an online application system. One of the knock-out questions asked for "A degree in computer-science, software development, or related field, or at least 6 years of experience in software development." The degree that I hold is in East Asian Studies, and I had less than 6 years of professional experience in development at that point, but I indicated that I satisfied that requirement. I got through the HR interview, programming aptitude test, panel interview, background check (including degree validation), and all other stages.
Finally, I got a call from the head of recruiting: "We were just performing a final review of your application and noticed that your resume lists neither 6 years of experience nor a degree in a software-related field, but you indicated that you satisfied that requirement. Are we counting incorrectly? Or did you forget to include some experience?" I responded that I had more than 10 years of experience and the question didn't indicate the experience had to be professional. (That was completely true: I have been programming since elementary school.) I also told her that part of the reason I decided to pursue a non-technical degree was that I had initially taken some software classes, was correcting the instructors in certain areas, and had absolutely no trouble completing programming assignments that students in higher-level courses showed to me. (All of that was completely true as well.) I told her that instead of spending my time in classes for a subject that I already felt I understood, I wanted to broaden my skills and learn something I didn't know much about yet.
She didn't seem too pleased at the time, but thanked me for explaining my application and hung up. I received the job offer the very next day. Either my answer was satisfactory enough for the company to decide that I hadn't lied, or I had done well enough during the interview stages that they decided to overlook the lie they caught me on.
That even-thirds technique is dangerous when, for example, the company has a basic job template and the hiring manager adds their real position requirements to the bottom of the list. I've watched managers do this. A candidate following your even-thirds split would lie outright about the most important requirements on that type of job post.
I agree that my "even-thirds strategy" is a bit... coarse. For every job description (and potential submission), you gotta apply a little bit of common sense to the equation. And yes, it is possible that the most important stuff is at the bottom (although I feel this is somewhat rare).
But I don't necessarily agree with your point about specificity. Here's why:
I've seen multiple occasions where an HR person is trying to put together a job listing to be posted online. They know that this job will be with, say... the dev ops team, so they talk to the dev ops manager and they ask that person for a list of all the technologies in the dev ops environment.
If that team/company has been around a while, they probably got a little bit of dang near everything lurking around. A stray VB.NET app over here, some ancient legacy Websphere sever over there. And of course, if you're in dev ops, you might need to "touch" all those different technologies, but that doesn't mean that you need to be functionally knowledge about nearly any of them.
I've literally seen job postings where they list a half dozen specific programming languages, and a half dozen specific database engines, and a half dozen different operating systems - but no one actually has to know all/most of that stuff to do the job.
As for your story - yeah... that's a classic example of what I'm talking about. In my experience, it's extremely rare that you ever get called out on such a detail - although it's obviously possible. And just as the process seemed to end favorably for you (even after getting "called out"), I believe it almost always ends up favorably for others who apply the same "creative truths".
Thank you for the detailed feedback!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You've done an excellent job exposing that many systems are designed to whittle the candidate pool down with knock-out questions, but I'm not sure that I wholeheartedly agree with the splitting of requirements into even thirds directly.
That even-thirds technique is dangerous when, for example, the company has a basic job template and the hiring manager adds their real position requirements to the bottom of the list. I've watched managers do this. A candidate following your even-thirds split would lie outright about the most important requirements on that type of job post.
Perhaps a strategy to complement the even-thirds would be to reorder the list of requirements by specificity. Something generic like "object-oriented programming" should fall to the bottom, while requirements like "Enterprise Java Beans" or "Web Framework: Spring, Jersey" should rise higher in the list. I figure that the more specific a requirement is, the more likely it applies to that position. (And on that note, I would run the opposite direction of anyone talking about EJBs in 2021.)
Now for a personal story: Much earlier in my career, I recognized the knock-out questions in an online application system. One of the knock-out questions asked for "A degree in computer-science, software development, or related field, or at least 6 years of experience in software development." The degree that I hold is in East Asian Studies, and I had less than 6 years of professional experience in development at that point, but I indicated that I satisfied that requirement. I got through the HR interview, programming aptitude test, panel interview, background check (including degree validation), and all other stages.
Finally, I got a call from the head of recruiting: "We were just performing a final review of your application and noticed that your resume lists neither 6 years of experience nor a degree in a software-related field, but you indicated that you satisfied that requirement. Are we counting incorrectly? Or did you forget to include some experience?" I responded that I had more than 10 years of experience and the question didn't indicate the experience had to be professional. (That was completely true: I have been programming since elementary school.) I also told her that part of the reason I decided to pursue a non-technical degree was that I had initially taken some software classes, was correcting the instructors in certain areas, and had absolutely no trouble completing programming assignments that students in higher-level courses showed to me. (All of that was completely true as well.) I told her that instead of spending my time in classes for a subject that I already felt I understood, I wanted to broaden my skills and learn something I didn't know much about yet.
She didn't seem too pleased at the time, but thanked me for explaining my application and hung up. I received the job offer the very next day. Either my answer was satisfactory enough for the company to decide that I hadn't lied, or I had done well enough during the interview stages that they decided to overlook the lie they caught me on.
I agree that my "even-thirds strategy" is a bit... coarse. For every job description (and potential submission), you gotta apply a little bit of common sense to the equation. And yes, it is possible that the most important stuff is at the bottom (although I feel this is somewhat rare).
But I don't necessarily agree with your point about specificity. Here's why:
I've seen multiple occasions where an HR person is trying to put together a job listing to be posted online. They know that this job will be with, say... the dev ops team, so they talk to the dev ops manager and they ask that person for a list of all the technologies in the dev ops environment.
If that team/company has been around a while, they probably got a little bit of dang near everything lurking around. A stray VB.NET app over here, some ancient legacy Websphere sever over there. And of course, if you're in dev ops, you might need to "touch" all those different technologies, but that doesn't mean that you need to be functionally knowledge about nearly any of them.
I've literally seen job postings where they list a half dozen specific programming languages, and a half dozen specific database engines, and a half dozen different operating systems - but no one actually has to know all/most of that stuff to do the job.
As for your story - yeah... that's a classic example of what I'm talking about. In my experience, it's extremely rare that you ever get called out on such a detail - although it's obviously possible. And just as the process seemed to end favorably for you (even after getting "called out"), I believe it almost always ends up favorably for others who apply the same "creative truths".
Thank you for the detailed feedback!