This is an example of an article that does a great job of identifying the problem (seriously -- I think it's great), but it has limited impact because it doesn't offer concrete steps towards a solution. It is hard to interview for intangible keywords -- how does the choice of keyword change that? Is the advice here just to take risk in hiring? That's not going to be received well...it can be just as damaging to make a bad hire for non-technical factors as technical ones, and I suspect this is why so many companies rely on terrible technical interviews.
The broken part of tech interviews isn't that they ask technical questions, it's that no one on the hiring side looks at their process and asks "what is it that this part of our process is measuring?" and "does that factor matter in making a hiring decision?" Asking brain teasers and CS "fundamental" questions is fine as long as there is a good answer to those two questions, but instead everyone does cargo-cult interviews because Medium says that's how Big Tech does hiring.
Yes, that's exactly what we should all be doing more of.
Hiring is always a risk, and the "accepted" risk-mitigation strategies (hiring by keyword, brainteasers, etc.) have been shown to be stubbornly non-predictive. At best they apply a misleading veneer of certainty on an inherently uncertain process, and if I'm going to take a risk I'd at least prefer that I not fool myself about it.
So yes, accept more risk in hiring. You're already taking risk, but by accepting the feeling of more risk you'll at least be more deliberate about it.
Thresholds seems to be a huge missing component to this stuff. Syntax, obscure trivia, brainteasers, etc are generally terrible predictors. However, if you ask someone to find say the average (mean) value in an array and they can't even get close that's a problem.
IMO, this comes from the mistaken assumption that you want to most technically competent person possible. Instead basic competence is a minimum barrier and everything else combined is more important.
Totally agreed. "Fizzbuzz" has become a bitter joke among good developers, but it tests something (sadly) important: can you write a basic loop and conditional statements? Or more cynically, are you a total fraud? You don't have to ask Fizzbuzz to test that, but you do have to ask something.
For me, if you pass the test of basic competence, and you can demonstrate evidence of accomplishment in any language, and you seem to pick things up quickly, then you're probably a risk worth taking.
(Actually, ignore everything I'm saying. I don't want the rest of the market to catch on. :)
> If you're hiring a HR manager, do you have them take a basic English skills test?
Yes, an interview in English is an English skills test.
Programming has the odd problem where you want someone that speaks code so you need to ask them to speak it in some form or other. Yet, if you ask someone to demonstrate even the most basic form of competence some people lock up.
IMO, the best option is to give programmers the same kind of fuzzy test your giving HR managers. You don't need someone that can decode for (int i = -6; i++ < ++j; k++) ... but they need to be able to understand how to use a loop to get something done.
Yep, that's exactly my point with the HR example. The interview itself should be the programming test, not some artificial, condescending introductory literal test.
If interviewers dealt with candidates from any other professional field in the same way that software professionals are commonly interviewed, there'd be a ton more people walking out of interviews.
The problem is the number of people that fail FizzBuzz or morally equivalent interview questions. It's so bad I think companies that don't ask candidates to code could skip interviewing about general background entirely, replace it with a 15 minute trivial coding exercise, hire anyone who passes, and be noticeably better off.
Maybe this isn't universal, but I'm used to most applicants being hopelessly unqualified.
Is this actually true? How many candidates have you failed for FizzBuzz specifically? Personally I've found it to be almost always passed. My previous company would ask for a simple implementation of pow() and strpos() and that had a decent filter rate.
I'm not sure about the point of your post, but to respond:
1) No - you screen those out with spelling mistakes in their resume
2) Maybe? I'm not sure - I'm not an electrical engineer. Then again, credentialing an EE is probably easier than a programmer.
3) This one's not even a good analogy - of course not.
What makes programming a little different is that it's turtles all the way down. While you might not need to find the average of an array, you will need the ability to reason about such things. You'll be reducing a collection of items, or mapping them or summing them.
You basically must deal with abstraction as a computer programmer. (And I'd argue that yes, assembly deals with abstraction)
1) But you don't use the resume to detect whether somebody is blowing BS about their software understanding?
3) It's a very apt analogy. Tons of especially lower level candidates are doing weird tricky CS problems at interview even if they're building yet more basic reporting systems.
Regarding abstraction, why don't you ask them to describe projects they did, instead of grilling them on concocted problems you know are beneath the level of person you wish to hire?
Google et al aren't asking to find the average value in an array. They're asking questions that boil down to "do you know the Boyer-Moore string search algorithm?" or "Can you correctly identify this problem as a rephrasing of the boolean satisfiability problem?" which, in the context of an interview, correlate only weakly with whether you're a good software engineer and instead correlate most strongly with how frequently you took or refreshed your Data Structures and Algorithms courses.
>>instead correlate most strongly with how frequently you took or refreshed your Data Structures and Algorithms courses.
It is well known that this companies test for this knowledge. They even tell you about it during their process so you will be ready for it. At the very least, it tests that you can learn this things from study. If you fail at them, you either did not prepare in the way they told you to, which is a failure to follow instructions, or you tried to study and it wasn't enough, which is a failure of ability to learn. There are probelm with this; the conext on which you are evaluated is vastly different than the environemnt wher eyou will ahve to apply it. But that doesn't mean the assesment is completely random. It tests for some qualities that will be important on the job.
This is complete BS. It's possible you got a bad interview, but this is not remotely the pattern. If it were, Google would struggle to be hiring hundreds of developers a week.
Given the number of developers I've seen who list SQL as "expert" and can't write a simple JOIN, or actually cannot complete the FizzBuzz challenge. As an example, I've been a pretty big fan of JS for a long time (since well before 'The Good Parts'), and after "AJAX" became the next big thing, wound up on an interview panel, and man, the number or developers putting "Expert" on their resumes who didn't even know some fundamentals were staggering.
Maybe it's just me, but when someone uses the term expert, I tend to be doubly suspicious. Especially if they use that for more than one or two skillsets.
To add to this, tasks risks in hiring but fire fast. Seriously as a hiring manager my best hires have been, on paper, the least qualified for the position. And when we've hired bad people, removing them within the span of 6months have been incredibly helpful. The corollary, not firing them fast enough has really hurt.
This is my concern with the fast-fire strategy. If you do a poor job with the interview process and hire someone who cannot do the job and have to fire them, you're messing up that person's life. They probably had a job before they accepted your offer. Now they're unemployed and it's your fault.
Firing people frequently is also expensive and it's demoralizing for the team. You also don't earn loyalty by showing that you have none yourself.
> It is not entirely your fault, unless you didn't effectively articulate what the job was. Otherwise, they took a job they knew was over their head.
It's mostly your fault. You know what the job is and what your expectations will be far better than the candidate. You should be hiring only when you are confident that they will be able to do the job.
> See point #1. Firing people frequently is a sign your interview process is broken.
Yes, that's exactly my point. "Fire fast" as a strategy should not replace "hire well". Your hiring process is entirely messed up if your strategy is "tasks risks in hiring but fire fast".
Sure, if you made a bad hiring decision, you may need to fire someone. But your hiring process should in general be filtering out poor candidates.
I'm pretty confident that the overwhelming consensus is that the tech hiring process IS broken.
Businesses either bias their individual hiring process towards false negatives or false positives, but no one has apparently figured out how to find the balance.
> Firing people frequently is a sign your interview process is broken.
Firing people frequently after a short term of employment is a sign that the hiring process (interviewing is part of that, but perhaps not the problem part) is broken.
Firing people frequently but long after they were hired may be a sign of hiring process problems, but is more likely a sign of post-hiring working environment problems.
(Well, actually, in both cases those assume that the firing decisions are, themselves, justified in the individual cases; obviously, either of the above could be a sign that the firing decision process is broken, instead of some other process.)
Absolutely right. I was sloppy in using "interview" to mean "hiring". I was implicitly only considering the short-term case, though. I agree that the long-term case implies more fundamental problems with the organization.
>>> If you do a poor job with the interview process and hire someone who cannot do the job and have to fire them
I think it largely depends on how do you fire people.
If you just decide 'fuck it, he's out' than yeah, that's awful. But if you give a chance to correct the issues, and actually give the chance rather than imposing some impossible requirements with your mind already set, that's different. Sometimes you just need a little push.
>>> Firing people frequently is also expensive and it's demoralizing for the team
Not sure about the expensive bit (it's better to fire sooner than later if you're going to fire anyway), but also concerned about the morale. Unless that's a very rare occurrence for quite obvious reasons, it will no doubt demoralize the team.
I suspect that a bad programming hire will usually be fairly obvious to co-workers. Like, "firing fast" will probably be after the point where other programmers will have thought "I don't want to work with this person any more"
I'm talking specifically about the "tasks risks in hiring but fire fast" strategy above. If your strategy is to hire without due diligence because you'll just fire later, that's extremely inconsiderate and also demoralizing.
Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.
I think of it more as a continuum that either full due diligence or hire most anyone who seems decent.
I agree that the latter version is wrong, but there is room to adjust how much you work on predicting future performance. How much of a jerk people are is one of the harder things to predict in interviews.
I get the feeling we're both speaking with previous unfortunate experiences in mind :)
The only thing that makes this hard, is when you spend a month looking for a viable candidate, and need work done, and have to pick someone... The person isn't your ideal choice, but the best of those available. It'll work out, or it won't.
In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.
One of the few times I've outright quit a job without another on the table was because of conflict with a "jerk" (overt arrogance irks me) that had too much political clout in the company to overcome. Of course broken process in a larger company is almost as irritating.
Since high school I have been under the impression that was how all businesses work. It wasn't until I got into the working world that I realized some organizations are so imbued with CYA that it can take literally years to fire a shitty worker.
I am very clear with how things progress. You have to be: 3mth evaluation, 6mnth evaluation if 3mnth wasn't going well. A clear onboarding process and written docs to get people up to speed. A pairing with another developer. Several story tickets which aren't designed to produce results fast but rather to educate.
That said, you also have to have an understanding of your interview process: no brain teasers, no language lawyer questions, etc. A peer reviewed collection of interview questions and a rigid methodology to make sure time pressure/stress/etc. are not part of the interview.
But is this legal in all countries and states? Because in some places, you can definitely take risks in hiring and fire fast, because employment is basically 'at will'. In certain other areas, there are all kinds of restrictions on how/when/why you can fire someone.
This might be why a lot of companies use these tests. Because in some places, you need to filter out 'bad' hires before it becomes difficult to dismiss them.
Obviously can't speak to everywhere, but the statutes around here (right to work) specifically allow for an initial probationary period.
Within the first few months of employment (or less/longer, as set out in a contract), the employee can be easily fired. They want similar reasons to a normal firing (underperforming, inappropriate behaviour, etc) but the information I can find says that the bar is set much lower and they're more just worried about you "acting in good faith".
I've rarely (if ever) seen it used. Usually people want to take the time to try and develop the employee, but they end up shooting themselves in the foot. If you hire someone that's not working out you can let them go pretty quickly. Once their probation is up you're stuck with them. So fire fast, don't dick around.
Yup. Or if not firing, then some other action like redesigning the job around the skills the employee actually has or transferring them to something they can actually do.
I've seen this from the other side, when I accepted a job that turned out to require skills I didn't have. It was an unbelievably crappy experience. Prompt action -- within the first six months, maybe -- would have saved a lot of grief.
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.
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.
Ford said : "I fired all the experts because they always told me why things cannot be done". I call this dead knowledge.
Generally, good people are always willing to learn, and challenge themselves, and listen to others, and doubt themselves sometimes, but not too much, and act according to their values, and have a vision and enjoy life.
Find as many of these traits in someone, ane you would have found a great partner.
I think the real lesson is that you should be hiring on the basis of ability, not keywords/checkboxes.
Admittedly, judging ability is very subjective and hard to do, but it's worth pointing out that judging someone's ability is fundamentally different from keyword matching.
With keywords, the only possible answer is a yes/no. Do you have Java experience? Yes/No. Do you have VP-Sales experience? Yes/No. Do you have 10 years of work experience? Yes/No.
Keywords provide no judgement on how good a performer someone is. They only tell you what that person has done in the past. Anyone can spend 5 years programming Java. But does that mean he's going to be a good Java programmer during his spell at your company? The keyword provides no way of answering that question.
Judging someone's ability on the other hand, even if it's imperfect, even if it's flawed, at least makes an effort to understand the person's potential capabilities. And that alone, makes it superior to keyword-based recruiting.
(or at least that's the argument the article seems to be making)
Asking brain teasers and CS "fundamental" questions is fine as long as there is a good answer to those two question
Asking brain teasers is fine as long as that's what your technical people actually do all day -- sit around and ask each other wacky logic problems they half-remember reading about on the internet somewhere, continually trying to one-up another (and if you don't answer with 90 seconds or so, you get fired, on the spot).
But for most software engineering roles, not so much.
Yes this annoys me these days. I was relatively good at these straight out of university. Now after 13 years of writing software I find my ability to do them is hit and miss. I do however write far better, more maintainable, cleaner software than I wrote straight out of university.
We just jumped down this rabbit-hole for a few weeks as we go through a hiring sprint. There's a consultant in this space that makes this exact argument -- Lou Adler -- and he's got the entire process spelled out in one of his books: https://www.amazon.com/Essential-Guide-Hiring-Getting-Hired-...
What's really cool about it as well is that he expects both the candidate and interviewer to read the same book. Pretty powerful.
its hard enough to identify problems and i think you don't need a well thought out solution before you can start to explain the problem. Maybe the next post will be "Do Hire by Ability to multiply numbers in your head", because that worked out well in practice. Or not.
I liked the article and i think these kind of question are harder than they look. Demanding solutions is too much.
Once place actually did ask me to square a number in my head.
Other than a brief flash of insight that you can do something like: 37^2 = (30 + 7)(30 + 7) = 900 + 210 + 210 + 49, I'm not sure what this was supposed to test. It was a fairly small company, but I'm sure they could afford a calculator or two....
I think the author's message is spot on, but I disagree with some of the details. Mainly:
> Industry experience is often a negative, not a positive
I can see why someone would say this. If you looking to innovate, you don't want employees always saying, "This is just the way we've always done it." At the same time, people with industry experience can avoid novice pitfalls.
Also, I cannot stand all the emphasized keywords. I get why he did it, but it's so jarring to read.
What the hell is wrong with this industry that experience in the industry is considered a negative? For every other skill the more you do it the better you get, yet the logic here is that the more one works with tech the worse one gets at it.
The only comparable jobs are high impact sports. An older boxer or football player is assumed to have accumulated injuries that make them a worse value proposition. Are devs the same? Am I slowly accumulating the equivalent of career ending sports injuries the longer I am stuck in a job living like a Dilbert comic?
Probably not. It is really just ageism, and my work history doesn't matter to these hiring managers as long as I'm over 30.
I think you're missing the point. From the article:
> We ran circles around competitors who had teams of B and C players with security expertise but little else going for them.
He feels experience is negative (I'm guessing) because the experienced candidates only have experience. It is implied that they have no other team skills - just their knowledge of the area. It doesn't matter if you hire the world's foremost expert; if they don't mesh with your team, everyone is going to have a bad time.
No. I never said experience is a negative, but I can see how it was implied. I understand where he's coming from, because there are people who are stuck in their ways. That's not an experience issue - that's a people issue.
No problem. I reread your first reply and I think we agree. I've met plenty devs who believe their 10 repeated years of the same experience entitles them to shout down younger devs.
Problem is, now that I am older I really don't want to be stereotyped as one of those dinosaurs.
The way I interpreted is that it's probably negative if your experience is XY years in the same $foobar industry. In other words, the kind of developers who haven't learned new anything since 2000.
I've met people with over a decade of experience in programming and had to convince them that hey, maybe we should write unit tests because customers keep complaining about bugs? Had hard time in doing it because hey you just refresh a browser and see.
Every time you add a filter for a particular trait or attribute, you're removing filtering power on all the other things you're looking for. Want someone with above-average experience in $foo? You've just halved your candidate pool, which means in order to make a hire you have to relax one bit of selection in some other category.
The question isn't whether experience helps. It's whether experience helps more than the worst part of the applicant filter that you're using. If it does, you should use more experience-based filtering. If it doesn't, you shouldn't.
I'm not suggesting that you filter for experience to the exclusion of other attributes. Instead stop filtering against experience, as some seem to be suggesting.
That said, a hard pass fail filter is a bad idea. Much better to score and rank.
> What the hell is wrong with this industry that experience in the industry is considered a negative? For every other skill the more you do it the better you get, yet the logic here is that the more one works with tech the worse one gets at it.
I can believe that experience of doing (say) chemistry 200 years ago might be so different from current practice that it would be of negative value. Tech changes a lot faster than that. Certainly in practice I've found working with experienced people worse than working with fresh grads, because fresh grads tend to be empiricists, whereas experienced people tend to have fixed technical views that are often outdated. (Of course this is just my subjective experience).
> The only comparable jobs are high impact sports. An older boxer or football player is assumed to have accumulated injuries that make them a worse value proposition. Are devs the same? Am I slowly accumulating the equivalent of career ending sports injuries the longer I am stuck in a job living like a Dilbert comic?
Older mathematicians are famously less effective. I honestly feel like I'm less good at my job than when I started. Certainly experience with outdated tools/paradigms seems like a net negative - it will mislead you when working with modern tools/paradigms.
I agree. What I suspect vision founders don't want to hear is that everything that can be done up to this point has already been done. Perhaps not the whole, but the pieces certainly.
They don't like this idea because they want to believe their idea is new and groundbreaking. It may very well be, but the pieces aren't. That's where experience comes in.
There's really great things about being 25. There's really great things about being 45. There's also things that suck about being 25 or 45. One of the things that suck about being 25 is KNOWING that being 45 means you're old and you don't know a damn thing. KNOWING that some 45 year old fart will just get in the way because they're slow and only know Perl. Hell, when you're 25 you simply KNOW so much. Then one day you wake up and you're 45 and you realize that even now you don't know a damn thing.
I guess you're right, it's ageism, but it's also just being 25 and being so sure of everything that you couldn't possibly learn anything from "industry experience".
Some people discover they know nothing at the late 20's, other people at the 30's, by 45 almost everybody already knows how much they don't know (and the ones that don't might be a lost cause already).
I'm closer to 45 than 25 these days and couldn't agree more. Took years to build up the experience I thought I had at 25, still a lot more to learn, wouldn't trade it for the world.
> Industry experience is often a negative, not a positive, for a new company. Could Hollywood execs have started Netflix? Would a book publisher had started Amazon? Jack Dorsey, not Visa execs, started Square. He admitted, when asked how he learned about the world of payments, “We Googled ‘accepting credit cards.'”
He clearly talks about founders and high-level employees, and provides examples. An obvious way of countering him would be to provide counter examples -- which truly innovative companies have been started by industry insiders?
More to the point, what better way to disrupt an industry than be familiar with that industry, and its flaws? Yeah, I agree that being an executive (i.e., the only 'skills' they have is making decisions in a specific environment, i.e., the status quo one) is probably detrimental...but Netflix wasn't originally in the same industry as Hollywood (they started in the soon to decline industry of video rental, and naturally progressed to streaming, and then original content creation). Amazon wasn't in the industry of publishing, they started in the industry of mail order books using this newfangled internet thing. Square isn't in the same industry as Visa; they're a user of Visa's services to build an easy to use payment portal for mobile (Visa even invested in them). Googling 'accepting credit cards' is -exactly what I'd expect- if you're trying to accept Visa, not if you're trying to displace them (because if the latter, who cares how Visa does it?). I think this says more about having -tangential- industry experience. All of them had enough insight into the problems in related industries, without having grown complacent with them, that they either were able to move into those industries (Netflix was able to move into content creation, Amazon was able to move into publishing), or were able to create business models addressing those industry's pain points (Square).
I'm not saying that it's wrong to use people with industry experience. I'm saying don't devalue the people who do. ChemicalWarfare[0] said it best in a sibling comment:
> There are some industries where getting up to speed just with the basic domain knowledge so that you don't have to google every other word/tla in the user story takes a good amount of time.
My point is that people with experience can help spur along development. I'm not calling his statement false, because I know of some company that did it better my way. I disagree (perhaps erroneously), because I know there are not-so-obvious mistakes people can make in this industry that eat up resources.
Getting a bunch of greenhorns together for sake of out with old is probably not ideal. You want people with experience to help avoid traps that prolong your process. Security comes to mind. Security is notoriously hard. And while you may not want to hire only security gurus for your business, it absolutely helps to have someone with security experience in your stable. From the article:
> We ran circles around competitors who had teams of B and C players with security expertise but little else going for them.
That last part is the issue. The employees had little else going for them. Your people with experience should have other qualities going for them. In addition to knowing security, they should be team players, open to new methodologies, effective communicators, and all those other soft skills that make teams function well. A team with no security experience can learn what needs to be learn without issue. I do not deny that. However, expertise doesn't automatically imply that everything else about the candidate is garbage, and having employees to give guidance helps avoid growing pains.
Maybe someone with industry experience could have started those things. I mean, having experience doesn't mean you think the industry is working well right now or doesn't need to change in the future.
Yeah, there are some people in various industries that either couldn't see approaching issues or just flat out ignored that they could be issues.
But there are also people who saw say, the rise of services like Netflix as a positive or likely thing. People in the publishing industry who saw the possibility of selling books online or replacing them with eReaders like the Kindle.
They just might have not done so for other reasons. Perhaps they saw what was coming, but thought they didn't have the entrepreneurial mindset to start their own company. Maybe they did start a company like this up, but they didn't find the right connections or investors or anything else to catch on.
Always been bothered with the assumption that those in 'disrupted' industries are too stubborn to know what could replace their business.
+1. There are some industries where getting up to speed just with the basic domain knowledge so that you don't have to google every other word/tla in the user story takes a good amount of time.
THIS.
After learning a few languages and paradigms, I find that I often have a 2 week ramp up for any given programming language.
If you already know Java and Javascript, you'll get Scala / Kotlin in no time.
If you're experienced in Python and Django, RoR is a few weeks away.
If you're experienced in C++ and Python, it won't take long until you're good to Go.
I get that companies want someone who's productive from Day 1, but they're missing out on a lot of great candidates that might only be productive from Day 15, but they'll be a lot more productive over time.
> I find that I often have a 2 week ramp up for any given programming language.
I agree that a competent, experienced developer can do this. What's worth noting, however, is that it takes two weeks to cross the bar of "can contribute code in this language that produces deliverable results". But two weeks cannot get you across the bar of "can contribute robust, maintainable code in this language".
Even though you are not a beginner to programming, you are a beginner to the language and its ecosystem and so will still make some significant newbie mistakes. Ruby on Rails is a good example of this: half of being good at RoR is being a good programmer, the other half is memorized knowledge of the idioms and patterns of the framework and community.
> But two weeks cannot get you across the bar of "can contribute robust, maintainable code in this language".
Unfortunately, this is so true and yet so difficult for people to realize and understand.
I've seen in real life wherein somebody hired at a supreme decision-making authority comes in and says "We'll rewrite everything in language X". Existing folks in the team quickly start ramping up on the language and simultaneously writing production code. Much of the code thus written tends to be pathological.
> But two weeks cannot get you across the bar of "can contribute robust, maintainable code in this language"
So do 10 years of experience. "robust, maintainable code" is just coding convention that a group of developers comes up with. The convention can vary from one team to another.
I went from Perl to Python / Django. I could write stuff straight away as the languages don't differ too much, but took me 6 months to write decent Django code, and longer to produce efficient, nice django-esque code using best practices.
The silly thing about companies being so obstinate about hiring someone with experience in the exact stack they use is that often times job reqs go unfilled for many weeks or even months. The result is that they end up wasting a lot more time with an unfilled position than if they had just hired that person who needed 2 weeks or so to ramp up.
Letting a developer or engineering job go unfilled for months is nothing, at least in my experience. I've seen a lot of jobs go unfilled for years while the company tried to find a unicorn to fill it, while at the same time priding themselves for being so picky and demanding excessive levels of experience, "full stack" experience, and "culture fit."
> THIS. After learning a few languages and paradigms, I find that I often have a 2 week ramp up for any given programming language.
That sounds about right for many programming languages. My personal average from "having heard of the language" to "writing non-trivial programs" (let's say, something that is able to talk to a REST API and do some processing) is a non-stop weekend programming session. [1]
The time-consuming part is learning the libraries and how to write idiomatic code. That can take months or years (C++, I'm looking at you).
Still, knowledge of a specific programming language is usually the wrong thing to optimize for. Perhaps a more useful metric was the number of programming languages one has been exposed to? That is more useful, as once you have learned a bunch, you've seen most of the important concepts, and can focus on whatever subset is implemented by the new language.
[1] Except Haskell. That's a nut I still haven't cracked.
There are also developers who view Java as the one true programming language who are either unwilling or unable to learn anything else. I know they exist because I've worked with many over the years. Javascript seems to be accumulating people of a similar mindset these days as well.
Filtering these clowns out should be rather simple (make sure their resume mentions at least a few different languages and ask the right questions during a phone screen), but most companies aren't willing to expend the effort.
One should also be vary of the other extreme:
There are people that switch their favorite language every three months, and insist that they use the latest one for their day job. If you allow it, it may lead to lot of wasted time, small wars within your team, and so on.
I wonder if part of this is because of pressure from investors. I heard an investor once comment about how they don't want to pay for a team to learn on the job, which I found ironic given the VC space implicitly invests in innovation, which is creating new opportunities that have lots of unknowns.
You may be able to learn a new language in 2 weeks, but very few people have this ability. I think a lot of developers learn the syntax quickly, but don't "grok" the differences in a language for some time. I still see people trying to write JavaScript in the same way they would write Java, and they wrote their Java in the same way they would write a Basic program (procedurally). It reminds me of a quote I am fond of: "The determined Real Programmer can write FORTRAN programs in any language." -- Ed Post
I prefer Alan Perlis' advice: "A language that doesn't affect the way you think about programming, is not worth knowing."
Edit: I categorize myself as one of the programmers who can learn syntax, but it takes me much longer to understand the language.
While this is true, sometimes knowing the syntax and basic familiarity with the toolchain can be good enough to start contributing. It's just that help from peers becomes very important - good code reviews, etc and not every organization can facilitate this.
So what is suggested for developers running into this situation? Not all of us live in dense, major cities where it's easier to find a cross-section of all stacks, but most of us with experience can ramp up into a new stack based on similar paradigms we already use regularly.
Tokenadult isn't around to chime in here, so I'll take his place today. Hunter and Schmit did a meta-study of 85 years of research on hiring criteria. [1] There are three attributes you need to select for to identify performing employees in intellectual fields.
- General mental ability (Are they generally smart)
Use WAIS or if there are artifacts of GMA(Complex work they've done themselves) available use them as proxies.
- Work sample test. NOT HAZING! As close as possible to the actual work they'd be doing. Try to make it apples-to-apples comparison across candidates.
- Integrity. The first two won't matter if the candidate is a sociopath.
As a PHP programmer, I picked up Node.js really quickly. I mean, sure, I already knew JavaScript, but Node is a very different ecosystem and has its own tools. After a week I was already productive and after a month I was already bored with it.
I bet I could be a perfectly fine RoR developer, given a little bit of time. I don't know Ruby, but I pick up languages quickly. Or, I mean, you could just keep the position open for a few months and just screen for keywords. It's really your choice.
The problem that I see is that employers don't want to spend the time to train people, or even wait for them to train themselves. They figure, if they can get someone who can hit the ground running, why would they waste time waiting for someone like you who needs to learn the language, regardless of how long it actually takes?
What they don't realize is that they it takes longer to find the perfect candidate than to train a good enough candidate. It might take a month or so to train someone on whatever web framework if they have similar experience. Yet the position could stay unfilled for six months or more waiting for that perfect candidate.
Considering the amount of interviews it takes to hire "the one", I guess the better bet is to hire quick learners who have the enthusiasm. How much time will it take to be an average RoR developer? One month? Two months tops! I know someone who was hired without any substantial background in HTML or CSS, and as of now, after three years, he knows enough to be able to speak at a major CSS conference.
It never fails to amuse me to see job advertisements that state "hit the ground running" that have been up for more than a month. It especially amuses me when the critical skill keyword, paired with "developer" or "engineer", surveys above median pay for "software developer" or "software engineer".
They are literally searching harder and waiting longer, to pay more for a narrower skill set.
Good luck finding that "javascript applications developer" or "ruby on rails engineer" or "SPARK/RTEMS engineer", guys. If you needed someone to be productive today, all you had to do would have been to hire them last month and give them a $200 book budget.
When I've asked why tech employers don't want to train people in the past, the prevailing answer was always that they didn't want other companies to get the benefit of the investment when they poach. This was what was behind the anti-competitive suit brought against Google, Apple, Adobe, etc
If you are going to have them on your team for 3 years, do the first two weeks matter?
Where I work the first two weeks are explicitly training. You will not contribute to the bottom line at all, even if you are an expert already. And sometimes this feels like not enough.
As a PHP programmer, I picked up Node.js really quickly.
Every PHP developer who I've seen pick up a nodejs project has end up fighting against asynchronous code and promises. You're fortunate that you were able to grok that aspect of node easily.
The thing is, that's pretty much what JavaScript is. Callbacks, promises, closures and async. If you already figured out that while working with Frontend Javascript the transition to Node is pain-free. But I can see how, if you're a PHP-only developer you would suffer.
I had to deal with asynchronous code when working with client-side JavaScript, it wasn't a new thing for me. If anything, I expect Ruby to be a little nicer if I have to work with RoR. But I probably won't because everyone wants 10 years of RoR experience nowadays.
The author is mocking keyword stuffing, but promoting "cultural fit" as "more impactful keyword". Sorry, but replacing technical keywords with some vague buzzwords does not improve your ads.
I think the wording is a bit unfortunate. I'm sure he doesn't mean you scan resume's for keywords like team player, communication, cultural fit, etc. Instead you should focus on these skills during the interview process, more than specific technologies or previous employers.
As others have said, the article identifies a big problem in hiring. However, it doesn't give you a lot of handles to solve anything.
So what is "cultural fit" then? If one didn't wear skinny jeans and don't enjoy playing foosball, he's out of luck? "Cultural fit" is one of the most offputting keyword for me, because as far as I've seen, it has one of two negative meanings: a) there's a monoculture inside company (usually "hipsters"). b) they creating a bubble around them and do not accept any other attitude than fanatically following their idea(s) which often leads to another overhyped bullshit-that-nobody-needs.
Being a "cultural fit" just means that the person will fit in well with the process and people at a company. Whether the "culture" in question is a specific type of culture is irrelevant. If you approach it from that perspective, you're probably taking the term at face value and missing the point.
The idea being expressed here is that if you bring in a new employee, even one that has no previous experience with the technologies being used, they will perform best if they are naturally in tune with the company's ideals and methodology, and can quickly develop camaraderie with the existing crew.
On the other hand, if you hire someone that knows all the necessary tech, but is constantly at odds with how things are done, alienates their coworkers, or manages to clog up the process in other ways--in those scenarios, everyone loses.
It has nothing to do with a cultural hive mind; it's just a matter of keeping a team synchronized and efficient.
Looking for people who will work well with the existing team is understandable and probably a good thing. The problem is that you have to be vigilant to not allow this to become looking for people who are similar to your current people. It's quite possible for a reasonable goal (finding candidates who will work well with existing employees) to have negative consequences (finding candidates who only fit a certain racial, cultural or gender expectation).
*Edit: Okay, I read both of the articles, and they were fairly interesting, so thanks. I do have a pet peeve / complaint though: Both of the articles purported to link to research, but neither actually did. the first article linked to a list of slide decks and the second article linked to a summary of research. I've read enough bad summaries now that I am working on becoming a primary sources junky. Do you know of any research on this issue that's been done?
I'd probably measure it by creating a test to see if they make snarky HN comments in search of attention or for the sake of contributing to discussion.
I understand that. But in real world, you can't check that about a prospect employer during the few interviews and it usually boils down to the things I've mentioned.
At my employer, "cultural fit" refers to our culture of honesty and transparency.
Basically, if you're the kind of people who will deceive customers, throw your coworkers under the bus, etc., we don't want you here. It seems to work out well for us; we consistently win awards for both customer satisfaction and employee satisfaction, our net promoter score is industry leading, and it's incredibly common for new hires to come from employee referrals.
What about hire by questionnaire? We used to ask for resumes only, but we ran into the same issue as OP where qualified candidates wouldn't have key items in their resume, and unqualified candidates would have lots of things but end up failing during the coding interview. So we just started asking people up front what we wanted to know.
Here's one of our software engineering forms. It's worked extremely well at filtering for technically qualified candidates. But we worry that we're still missing people because https://imgur.com/RIamYIZ
Eh, that's a pretty reasonable questionnaire. If it was pages and pages, it'd be too much, but there's only 12 questions here (including the citizenship and email address questions) and I'm assuming you don't expect an essay for each of these. Someone who's indignant at the idea of filling this out is probably not worth working with.
I have to say, I find the SSH question at the bottom odd. Who is this screening for? Are there people who hit all your other requirements but don't know how to use SSH? Would you actually eliminate someone for this, as opposed to spending 5 minutes introducing them to SSH (or 30 seconds sending them a link)?
My question, seeing a form like that, is what is the resume field actually for?
Would the resume be used for the actual screening/selection process, or is it instead just to get all of the other details that might be necessary later in the hiring process as a catch-all?
This is mostly right, but using "cultural fit" as a criterion is the road to "hire people like us," which is as unproductive and keyword-based hiring just in a different way. In fact all the criteria cited in the article as good have significant weaknesses. Even "expertise" need some explanation, since one would hope that's not the keywords listed under "Expertise." Having an applicant write some code and defend they way they did it, and/or bring some code they wrote, would be a much better gauge of expertise.
Finally, someone who also thinks in a sensible way on hiring.
In Toronto, I keep seeing all these job posting of companies that need people with 10 years in social media experience, or 10 years in mobile app development and it's quite laughable how they are able to hire those people.
I'm curious how those people can actually perform.
Fake resumes. Indian tech shops specialize in this (I'm Indian btw). Fake resumes are extremely common among Indian tech workers. I was asked by one IT body shop to write 7 years of Java experience even though I had none. I routinely run into resumes where people sometimes write more years of experience with a package than the number of years the package has existed.
I'm interested in how that kind of thing prevails. Is it because the purpose of the lie is just to get past HR screening, and after that competent people just learn the language they lied about on their CV? I can't imagine that would work though, I mean how does someone get past a technical interview with a fake CV?
That will get you a job in the short term, but isn't great for a career that will last until retirement.
But as far as I can tell, the candidate crams for the tech screen, learns the basics between offer letter and start date, and picks up the rest as they work. The dirty little secret is that nobody actually needs any specific experience to do the job. You just need a decent brain and an Internet connection, and just enough people skills to fake it until you make it.
But it probably works better in larger organizations, where none of the people who would be able to detect the deception are involved in the interview process. You don't need to fool your peers if you can fool your boss.
It never would have worked in any of the smaller companies that I have interviewed with, as they have all (perhaps coincidentally) been ultra-paranoid about resume frauds, for some reason.
The dirty little secret is that nobody actually needs any specific experience to do the job. You just need a decent brain and an Internet connection, and just enough people skills to fake it until you make it.
Very true, and this is why these keyword searches are so absurd. It wouldn't be difficult to setup the entire hiring process (applications as well as interviews) around that dirty little secret.
Consulting companies may need to inflate staff CVs to be competitive with other consulting companies in the eyes of clients, even if they internally know it's bullshit.
It happens at major companies as well. A friend's younger brother got into Chase bank as a Java dev after listing 6 years of Java experience. He had zero years of experience and was only 24.
The ones claiming having 10 years exps of social media and mobile app development use their social media skills to look for cheap mobile app developers and pay them to do their works. Their clients/managers do not know and do not care.
The reality is that resume must be filtered out, either by tech keywords such as "clojure or ruby on rails" or social keywords such as "culture fit or team player".
No one hires by keywords, they filter resumes by keywords.
If you're smart enough, you will load up your resume with keywords if that's how your target company is filtering resume by. You just want to get to the next base which is getting an interview.
How do you get hired after an interview? Some companies will give you tests, puzzle, white board coding, all conversation/culture fit, etc. You likewise have to be a fool not to adjust accordingly. If you want to join Acme corp so bad and they require you wear a suit, wear a freaking suit. If they are laid back and cargo pants and t-shirt will do, you have to be an idiot to go in with a suit. If they are big on whiteboard coding, then practice so and do load's of exercises prior to your interview.
game theory 101, people will always look for ways to maximize their outcome.
I cringe when a recruiter wants to know which language I program in and he/she does not get it immediatelly when I reply "any that you like" or "what ever the customer wants".
Keyword based job match is however the only automatic solution, all other are to work intensive so that it makes economically sense.
Even worse is keyword technology and version. "I need someone with X version 5.12" kinds of job ads. Really, you intend to avoid upgrading for the rest of time?
There exist job ads which have the explicit purpose of not finding a qualified candidate. It tends to be a result of things like H1-B visas, union contracts, and other frameworks which provide 'first dibs' on an opportunity to a subset of the global labour pool.
I remember visiting a recruitment consultant after University in the dot com bust of 2001. He told me to add Oracle version numbers to my CV as "Techies love that".
Everybody knows one shouldn't Hire by Keyword, but they still do it.
Why ? I think this is the CYA principle in play. "I hired a $keyword specialist, it clearly says so in his resume. I am limiting any blame I get if they don't work out !"
I've worked at a company where this philosophy was compounded on during the "down" days, where the company I was at was in a sharp decline.
When the VPs and execs panicked, they started at the hiring level... They made a plan to "stop hiring junior level" employees, and our team became full of Senior level people. Then they said we need more PhDs... because a PhD is prestigious and we need prestige. There was even a brief mandate to high an industry celebrity type, basically just for show. It all started with a "hiring by keyword" mentality and pretty much led to a massive decay of passion across the entire team.
* outsiders can bring some fresh thoughts and challenge ideas that everyone inside keep as status quo and unchallenged;
* people who define themselves as e.g. 'Ruby on Rails dev' (or JavaScript dev or whatever) might have hard time adapting if the landscape changes, or they need to do something outside their comfort zone;
* specific technical skills (programming language, etc) are usually easier to develop than soft skills such as leadership, teamwork, communication.
Of course, it's not unconditional. Sometimes you really need someone who has deep knowledge of some niche, or is really a master at some technology. It's just probably not as common as one might believe.
Devil's advocate: I like it when ads have the technologies as keywords. Preferably listed explicitly & directly. I have arbitrary preferences like Apache Camel v Spring Integration & Ansible v Puppet. I'm not on the market looking, but I do occasionally peak to see if there are dream jobs available on Craigslist/StackOverflow.
Even if I can quickly grok the equivalent, I'd get frustrated after a months/years of solving problems using my less preferred stack. The stack can also tell you a lot about the philosophy of the shop: flexibility vs. convention/readability, stability vs. cutting-edge.
The truth is that those kind of companies have very little money and so they want to hire people that can be productive from day one. Of course this is utopia but that will not stop them.
Do they actually end up hiring based on the criteria in their postings? I often find that the typical listing is unreasonable. Who actually gets the job? Is it worth applying to anyway?
In my experience, I've seen direct hiring tends to focus less on "x years of experience" but recruiters, especially larger firms with junior staff doing screening, is absolutely terrible with obsessing over it.
Some postings go way overboard on skillset. You must be a master at everything. I've heard that this is done sometimes so that they can't find the talent locally and then can outsource for that specific role.
Some recruiters, not all, are basically no better than a robot. I don't have a B.S. but I have an A.S. plus 10 years of experience now. Give a recruiter a req of "B.S. or equivalent experience" and they will turn me away without a phone call because I don't have the degree. When 10 minutes on the phone is all I would need to convince them I have the experience they need. I've basically given up on interviews for awhile. It drains so much energy just to get canned responses back.
I think it's weird that the IT industry hires based on technologies you know. It seems much more relevant to hire based on whether you've completed similar kinds of projects to those that will be done at your new workplace.
It's like aiming to hire someone to build a high-rise out of wood and going "We need someone who can use a hammer and nail". Not really wrong, but it's kind of an odd emphasis.
A few years ago I built some .NET components to service a node front end. I used to get so many people contact me about Angular and node contracts. I tweaked my CV to say Microservices instead of components and replaced node with java script SPA and now I get far more relevant enquires from agents.
Bullcrap. Just look at the examples of hires he has in mind: co-founder of a startup, VP of marketing, CEO, "Could Hollywood execs have started Netflix?". This guy is a fly-high investor. Unless you're in a similar position, his advice is useless.
I agree to the article in general. But most of the keywords in job description are put up to set some expectations or if you have a project that needs people who already know things.
The broken part of tech interviews isn't that they ask technical questions, it's that no one on the hiring side looks at their process and asks "what is it that this part of our process is measuring?" and "does that factor matter in making a hiring decision?" Asking brain teasers and CS "fundamental" questions is fine as long as there is a good answer to those two questions, but instead everyone does cargo-cult interviews because Medium says that's how Big Tech does hiring.