> I'm still shocked over half of developers couldn't accomplish that task. Makes me wonder what they were accomplishing in their existing roles.
I once asked a candidate to write a for loop in C#[0], using my laptop and Visual Studio and watched for a solid 5 minutes while he struggled -- And I don't mean jitters around syntax, I mean, failing to declare a variable properly and while he knew what a for loop was, he had no idea how to write one in C#. His resume touted a series of projects that we estimated put him a little above a Junior developer and the only language he referenced was C#. I don't normally do these kinds of "on the spot tests" because I, personally, hate them, but I was cheering when I read Coding Horror's "Fizz Buzz" article[1] on the subject.
This was the most foul example and my only experience is with developer and ops/security positions, but if you're getting half of developers who are in the same time zone as the title[2], you're doing well. Does this happen in other parts of the business world? Some of the folks we get in would be like a Walmart cashier applying to run a finance department because "they've handled money before". And what if they got the job, do they think they'd come close to being successful? I'm all for the "fake it until you make it" and I'm very willing to overlook weaknesses around experience/education if the candidate is really passionate and I can get enough of a comfort level that they'll be a quick study and love the job, but you have to be realistic about your deficiencies.
A lot of the problem, I've found (being on both sides of this in the past) is with recruiters, as well. They tend to operate on a "throw darts at the wall, blindfolded" approach, with the assumption that if they send out a million candidates for a million jobs without regard for qualifications, that they'll get lucky, one will land somewhere and they'll get a commission from sheer volume on bad odds. This serves nobody well -- it causes companies to put up multi-step gates that involve people who aren't close enough to the field to discern a good candidate from a bad one via resume performing a filter operation that disproportionately disqualifies the really passionate but "not quite a perfect fit on the qualifications side" and it causes job seekers to take a bunch of interviews for positions they won't like/aren't qualified for and won't land -- causing them to have a miserable experience interviewing (and probably resulting in some dropping out of the job market entirely).
[0] The exercise was, specifically, write a for loop with an int value that is incremented by one, adds that int value to another int variable, and multiplies the result against the counter, assigning the value to a third variable. Print the result to the console. This was before "Fizz Buzz" became all the rage, I did my best to give a blindingly simple problem to just validate that the person could do something in the language.
[2] Never mind the details "Must have 4 years of experience in Angular", nonsense -- a topic for another post, but the way we write job requirements is about stupid. I mean, I've seen experience requirements that exceed the length of time the technology was in existence, and I'd rather see a candidate demonstrate an ability to adapt and learn new things than be overly concerned with whether or not they've used a framework that is really similar to a bunch of other frameworks.
Bad jobs are constantly in need of filling: people quit very frequently.
Bad employees are constantly in need of placement: people get fired very frequently.
If you're hearing about a particular job or candidate, the odds are they are bad. Most jobs are filled internally or by referral. IIRC, it's only about 20% of jobs that are filled by recruiters and/or cold job applications.
You're right about bad employees, but I've not found it difficult to weed those candidates out. At the same time, I don't fault a candidate for being laid off provided they have a good explanation[0] and/or they're otherwise a good fit.
As for bad jobs, even bad jobs need someone who is functionally capable of doing them. Sure, you have to be vigilant about filling those positions, but it's rare to encounter a "bad job" in this field that would be fine to have a terrible candidate in.
Regarding jobs being from internal candidates: It's interesting, because I hear that statistic rather frequently and often wonder where it originates or whether or not it has the meaning that is often attributed to it. Again, pulling from my anecdotal experience, though my resume was passed in from an internal employee for the two jobs I was most interested in[1], in one case my resume was handed to a sales person who reached out to me with a question about the company I had just been laid off from -- I had never talked to him or met him before and he lived about 100 miles away and in the other case, my sister handed my resume off to a friend of hers who worked there[2]. This friend and I met for the first time on my second day of work there. I don't even know if the guy is a software developer or not -- and that's the crux of the issue. If the recommendation is coming from someone doing the same/similar work on the same/similar team, that candidate is probably a good fit. If it's from someone doing wildly different work or who has no idea what a good candidate would look like, it's not much better than the blind solicitation from a recruiter. This is further complicated by the fact that many/most companies grant a referral bonus, incentivizing staff to solicit and (possibly) lowering the quality of candidates coming through that channel[3]. I'm really curious about others' thoughts on this, particularly those who've hired for their own companies.
The last issue with the 20% rule is that in companies that are dedicated to filling a diversity standard of some kind, it's hard to get there from internal employees unless you already have a very diverse staff. Reality being non-ideal, you tend to hang out with folks who are similar to you[4].
[0] There are plenty of reasons people get laid off/lose a job that have nothing to do with the competency of the employee. Companies go completely out of business, shedding all jobs or merge with companies where the whole department gets eliminated. Less "great" excuses are role elimination, though, this happened directly to me in January but I was offered a position for every job I interviewed for, so given appropriate context it can be fine as well.
[1] I interviewed at four places, all four offered me a position, two of the places were the highest on my list and I took one of my top choices. The two that were high on my list technically had my resume passed in from someone who already worked there.
[2] That it was my sister certainly helped -- she's been the CFO of a very well known global company and is currently the CEO of a mid-sized company -- her recommendation is trustworthy and people who know her know that she wouldn't embellish anything just because of family relation.
[3] I'm on the fence about this, though, personally. On the one hand, I'm less likely to recommend anything but the absolute best candidate for a role at company I work for if there's not a financial incentive -- it's nearly all downside otherwise. If the candidate works out, it's unlikely anyone is going to remember you sent that resume in. If the candidate is a mess, you get a ding on your record for recommending a fool and a subconscious ding to your own reputation that you associate yourself with fools (unfair as that is, I've seen it). If there's a financial incentive, there's always the "well, we paid him to do that; maybe he really needed the money" option which is bad, but not as bad. I got 11 people hired in at CompUSA when I worked there in my teens because they paid a $250 bonus. I had one really bad (as in, he stole things, and damaged things in fits of rage bad) recommendation that surprised my managers and me (he was a close friend and I had no idea he turned in to lunatic once he was being paid to do something).
[4] Though this does apply on racial/gender boundaries, one of the goals of diversity is to also avoid group think. Taking race out of the picture, you favor people who are like/agree with you and if the goal is to seek people who are hard working/passionate but not cut from the same cloth as the rest of the team, an internal recommendation will miss that more than it will hit it.
Hiring at the company worked like this, provided the resume wasn't passed directly from a member of staff close to that team:
(1) Applicant applied through web/recruiter/e-mail. (2) Resume was reviewed by a generic hiring team who covered every kind of job the company had and none of whom had even the most basic understanding of what a developer's qualifications should be[0]. (3) This same team does a myriad of phone screens to further whittle the pile. (4) Team's manager reviews remainder and often didn't perform a second screen since one was already done[1]. (5) Candidate arrives.
[0] These same people provided many of the "templates" used for the job descriptions, so you can imagine these were similarly bad. This practice resulted in the company, for years, refusing all resumes where the candidate did not complete a 4-year degree program. I pushed for an end to that for dev jobs after two candidates I hired in who had limited/no college experience turned out to be excellent employees.
[1] And in some cases, the manager knew nothing about software development and was put there from some part of the business, so s/he'd be about as effective at a phone screen as the hiring team.
I once asked a candidate to write a for loop in C#[0], using my laptop and Visual Studio and watched for a solid 5 minutes while he struggled -- And I don't mean jitters around syntax, I mean, failing to declare a variable properly and while he knew what a for loop was, he had no idea how to write one in C#. His resume touted a series of projects that we estimated put him a little above a Junior developer and the only language he referenced was C#. I don't normally do these kinds of "on the spot tests" because I, personally, hate them, but I was cheering when I read Coding Horror's "Fizz Buzz" article[1] on the subject.
This was the most foul example and my only experience is with developer and ops/security positions, but if you're getting half of developers who are in the same time zone as the title[2], you're doing well. Does this happen in other parts of the business world? Some of the folks we get in would be like a Walmart cashier applying to run a finance department because "they've handled money before". And what if they got the job, do they think they'd come close to being successful? I'm all for the "fake it until you make it" and I'm very willing to overlook weaknesses around experience/education if the candidate is really passionate and I can get enough of a comfort level that they'll be a quick study and love the job, but you have to be realistic about your deficiencies.
A lot of the problem, I've found (being on both sides of this in the past) is with recruiters, as well. They tend to operate on a "throw darts at the wall, blindfolded" approach, with the assumption that if they send out a million candidates for a million jobs without regard for qualifications, that they'll get lucky, one will land somewhere and they'll get a commission from sheer volume on bad odds. This serves nobody well -- it causes companies to put up multi-step gates that involve people who aren't close enough to the field to discern a good candidate from a bad one via resume performing a filter operation that disproportionately disqualifies the really passionate but "not quite a perfect fit on the qualifications side" and it causes job seekers to take a bunch of interviews for positions they won't like/aren't qualified for and won't land -- causing them to have a miserable experience interviewing (and probably resulting in some dropping out of the job market entirely).
[0] The exercise was, specifically, write a for loop with an int value that is incremented by one, adds that int value to another int variable, and multiplies the result against the counter, assigning the value to a third variable. Print the result to the console. This was before "Fizz Buzz" became all the rage, I did my best to give a blindingly simple problem to just validate that the person could do something in the language.
[1] https://blog.codinghorror.com/why-cant-programmers-program/
[2] Never mind the details "Must have 4 years of experience in Angular", nonsense -- a topic for another post, but the way we write job requirements is about stupid. I mean, I've seen experience requirements that exceed the length of time the technology was in existence, and I'd rather see a candidate demonstrate an ability to adapt and learn new things than be overly concerned with whether or not they've used a framework that is really similar to a bunch of other frameworks.