What we do instead of technical interviews
be.helpful.com
be.helpful.com
Just let the candidate talk about their career and what they have done. Ask their opinion of certain things. Ask about how they tackled certain projects and give them the time to answer and go off on tangents. Treat it like you are a few friends having an in-depth discussion over drinks.
Technical interviews focus too much on headline points. They want the candidate to touch on or mention certain things that everyone should know about the subject. I'm not interested in that, I'm more interested about them mentioning less obvious things such as known quirks, bugs or tricks about the subject matter. Stuff that only a regular user would learn about.
The problem with this approach is that for many companies HR insists on structured interviews. I once had do some interviews for a couple of C# roles. The interview format was literally the same as the game show Talk About. The interviewee was given time to talk about a subject and we had to tick off a list whether they mentioned certain keywords and phrases in the allotted time. The same format applied to the HR interview. Whoever scored highest got the job, a very silly way to do recruitment.
A conversation on relevant subjects helps filtering out people with fake or stuffed resumes in a matter of minutes, assuming the interviewer is a technical person. It also helps understanding if it's someone we can work with as a colleague. If all goes well, we would make an offer, but will make it clear that the 3 month probation period _is_ the actual interview.
Had very good results with this approach, but it doesn't really scale or work for larger projects with aggressive hiring plans.
I was in a growing company that allowed anyone who had been there six months or more to conduct interviews. It massively increased the speed of recruitment and prevented managers and senior devs being tied up with recruitment stuff.
If you can't express your competency during an interview chat I don't see how you could be a good candidate (there are exceptions), nothing more damaging to a team that someone who can't communicate.
Being able to simulate extroversion for short periods at need is a useful life skill for any introvert - I've found it invaluable in plenty of situations beyond just job interviews.
Selecting only based on chattiness is not good, but filtering out people who cannot even chat is probably a good thing from a company's point of view.
There wasn't much of a correlation between how well a candidate chatted and how well they coded, and there was some horrendously bad code and terrible habits exhibited by people who talked the talk pretty well.
Conversely, some of the less verbose people wrote excellent code and were often cheaper - possibly because they didn't interview well.
The downside of this approach is that crafting (and iterating upon) a realistic test that exercises all the necessary skills and can be squeezed into 30 minutes is hard work.
Being on the other side of the table, interviews done this way has landed me in my most interesting/best jobs, and in the best teams, in my opinion.
I've done maybe 100+ tech interviews, easily. The ones that have been the best have been conversation based. The worst are take home projects that take days to complete. (the worst I had: create a poker game)
A good inbetween can be try-before-you-buy for a day or two, but if the scope of work isn't managed correctly you may not see what you want. I had that happen recently in an interview - i asked what success looked like (being communicative on the work to be done) but at the end was told they didn't see enough front-end work.
If you can't tell within 30 minutes of talking to someone whether they are competent or not, you shouldn't be doing the hiring.
Likewise, if you can't express yourself in a casual setting - what kind of person are you to work with? How will you handle disagreements or feedback? What will you offer the team?
Lastly, if they have OSS work, take a look at it. If they have contributed to an OSS project, take a look at their PR and how they worked with the main devs to get it merged in. That is a much stronger indicator to skill and quality than a random coding exercise.
Not very easy to accomplish, from the company perspective. You have to have contracts, NDAs, and a whole bunch of stuff in place, even if the person is gonna only work for a couple of days, or for a week.
FWIW, this has not been my experience. NDA's sometimes, contracts usually - thats about it. overall, 10-20 mins of paperwork tops.
I used to do this for a multi-national tech conglomerate. Everyone else did technical interviews. I gave a laughably easy tech test (few binary operators). If you mentioned a technology I knew well on your resume I asked you a question about that.
After that, "Tell me about your favorite book, author, movie, album, musician, hobby, magazine. Anything. There's no wrong answer." Just to get a conversation going. I had a number of questions like this. The point was to get them talking.
The most memorable was a Bukowski fan. We talked about his novels and the employer happened to be just a mile from where some of the scenes were set. It was cool because the guy lit UP when he got to talk about it.
The guy who made the worst impression said Freebird was the only thing he could think of, and the last album he could remember buying... when it came out... in 1973...
I observed no correlation between test results and whether the person turned out to be a good hire.
There was also an inverse correlation between competency and "gotcha" questions. One of our least competent engineers was vicious and mean-spirited during interviews. In the 100 or so interviews we did together, the only person he ever liked was his friend. Ironically I fought hard against hiring the interviewer himself but was explicitly instructed that we were seeking "moderately competent" individuals for his role.
Then HR found out about it somehow and forbade me from asking "personal questions" because we "might get sued." I had to stick to a script.
So I quit giving interviews, and we hired people who were good test takers from then on.
Lynyrd Skynyrd's Freebird? That was a song, not an album. The album was called Lynyrd Skynyrd.
And sometimes, experts are not available. Either because the only expert is the person you want to hire, or because of a strong divide between HR and technical people.
The bullshit feeling that everyone has to live and breathe coding is the biggest nonsense thing I encounter in this field (software development). A good job with a good work environment is more than enough to get productivity and results from your coworkers.
99.9% of the issues I encounter in companies as a consultant or employee revolve around poor management. They don't have budgets. They don't have plans. They don't have people that understand IT. Their IT doesn't understand how their products affect the bottom line. Add in about 1000 other "management doesn't get it" items and you might be close to the realistic picture.
It's quite depressing in practice.
I'm not even especially interested in the actual answers, per se. I'm interested in two things: do people know what they are, and are people willing to say so out loud.
At previous jobs, I've run into candidates who interview well but code poorly. They look good at first:
1. Their resume looks reasonable.
2. They sound qualified on a phone screen.
3. They can talk about previous projects.
4. They seem like great people to work with.
...but when put to the test, they can't code. I'm talking really simple stuff, like "You have 40 minutes to write (something no harder than FizzBuzz)." They can use their own laptop, with the language of their choice, and StackOverflow. Or for a job involving Scheme, we asked them reverse a singly-linked list. These were almost insultingly easy tests, given the posted job requirements. But I saw otherwise promising candidates struggle for the better part of an hour.
But asking people to code can also help them get hired. I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds. We hired him, and he turned out to be a incredibly strong team member for many years.
I think one fair way to handle these things might be to offer interviewees a choice:
1. We can ask you to write code during the interview, or
2. You can submit a link to a small open source project for us to look at.
That gives both people who can't code under pressure and people who don't write code outside their day job an option. And it provides the interviewer with a work sample to discuss in the interview.
It's entirely possible that person just happened to have seen the problem before. Many interviewers would throw additional problems at them if they solved it that quickly because they would assume this. Especially true if you pulled the problem directly from a problem site where it has a high chance of someone seeing it before.
You can get decently far as a programmer in mediocre jobs just knowing how to write a CRUD app. You'd never use modulo or reverse a linked list in these positions, yet they pay $60k+ and otherwise deliver products. The org doesn't care that code is delivered at a bureaucratically slow pace or incredibly simple because it's dysfunctional in the first place, so delivering a feature in 3 days which would take a good programmer 2 hours doesn't matter. Lots of "the user is wrong" pushback when something in the code fails too. Unfortunately, because of the way we're made to write resumes, these positions can be made to appear like any other normal position.
I think it's more interesting that he seemed to do poorly until you gave him code.
This may also sound insulting but I certainly don't mean it to be: maybe your code base isn't that challenging, which is why he is now a strong candidate. Are they doing maintenance, or contributing a lot of new code which requires architectural decisions that weren't previously found in your code (and could be copied)?
The position I'm thinking of was a senior developer position that involved writing large amounts of Scheme code to interface with a video game engine. Typical Scheme code uses recursion where normal languages would use loops, and singly-linked lists are the most basic Scheme data structure, used for everything. So if you can't reverse a linked link in some language, you're probably not especially qualified for a job as a senior Scheme programmer. Not everything is a CRUD app.
(And it's basically the first homework question you get in a first-year Data Structures class, so it's not too much to ask for a senior dev doing low-level work.)
> I think it's more interesting that he seemed to do poorly until you gave him code.
I've found that some amazing developers have weak people skills. They don't necessarily know how to write a resume, and they don't know how to "sell" themselves in interviews. But they may still be brilliant, dedicated coders, and excellent teammates.
Actually for a senior dev, it is too much to expect low-level work they haven't used in 10 years. The analogy I quite often give is that you wouldn't assess a French teacher on their Latin class from 2005.
The bottom line is that you probably asked a useless question that was great for teaching the CS foundations in school, but that hasn't ever been used once in their careers. People discard useless information, especially smart people because they prize the efficiency that their memory can use in place of useless information.
No thanks.
This might work if you're looking to fill a pipeline with 'good enough' junior people who you can then push into an appropriate role, rather than hiring for something specific.
Actually the offers are exactly the same as if we did 7hours of interviews, so it's not an interview after we hire you.
Let me know if that answers your question.
Their suggestion is essentially "you don't need to make sure you are hiring the right people, because you can fix it later by firing them".
I think the flipside of this strategy is that you won't get the people who are good at the job and good at interviews. Imagine I am offered a job where 90% of people pass probation because of a thorough interview process vs one where only 20% pass. If I pass the interview, other things being equal, it is easy to guess the job I'll take. The 20% company won't even have a chance to "test" me.
They’d then get fired. The CEO would say, it will be better for them in the long term and I’m sure they’ll be happier. This wasn’t true, they had their issues but actually the CEO has screwed them too by not doing the due diligence and hiring too quickly...
Honestly the best solution I can think of is to work as a paid consultant for the company and see how that goes. If the relationship seems to work, then join full time. Not everybody has the time to take on consulting gigs though which is a significant downside.
You're missing out on other aspects of hiring like recruiter fees. If I were to hire every idiot that ticked off the boxes but couldn't demonstrate relate knowledge to something tangible I would've put my current and previous company out of business.
Your 90-day long interview process (this is what it is, face it) is not only a financial detriment, but a productivity tumor. Yes, I do agree that the current wide-spread use of "solve this on a whiteboard", "implement merge-sort", or some other backwards method of technical ability does not work; that is why I implement questions, and paired exercises that are tailored to the position they will be filling and the background they're coming from. The process I have in place consists of 3-parts: phone screen, and 2 in-person interviews - this process normally doesn't extend past 3 hours. The interviews are structured as a conversation to make sure the most nervous of interviewees can perform comfortably. I'd rather waste 2 hours more per candidate opposed to ~20-40k GBP for a poor trial, and a decrease in overall team velocity.
The 90-day interview (as you call it), is the same if we did 3 hours of interviews (like you do) or 15 minutes. We didn't see a better accuracy as we shrunk our interviews down from 3 hours to eventually 15 minutes.
I really like your pairing idea espescially if that's close to the reality of the actual job.
People in existing teams will be very fatigued from getting to know new people and then trying to forget them. This is well documented in the military. After a while veterans don't want to get to know the fresh reinforcements that arrive into their unit, as the new guys will probably die quickly simply because they are inexperienced and thrown to battlefield. As a result, any investment in social relationship with them is wasted. And as a result, the whole unit will get grumpy.
We never found smart effective folks who did not want to get to know newer smart and effective folks.
Less than 50% of hires stay: "oh geez, more meat to the grinder."
More than 50% of hires stay: "A new guy came, do you play ping pong?"
But my cut off point might be way off. And there might be some elasticity between those where people are more iffy about the whole deal.
I'd suggest testing this. Stack slightly not so promising new hires to one team and more promising in other. Let's hope there is different retain rate. Now you can measure the performance changes of both teams and see the net effect.
So even though this is implicit elsewhere, we make it explicit (if you don't think we're a fit for you, or we don't think you're a fit for us, we'll part ways)
Let me know if that makes sense
By interviewing and throwing away potential false negatives you also cut down on the number of people failing probation. You can't have it both ways: not interview and keep the same number of people.
Of course not all decent devs are particularly good at this [1], but from my experience below average ones are consistently unable to find flaws in both their own and someone else's code or even if they do they don't care enough to point that out.
[1] Not saying I'm an especially decent dev, but although I manage, reviews are hard for me because I'm way to lenient - I guess it boils down to trying not to hurt other people's feelings.
EDIT: accidental emphasis
It would be an interesting interview where they put some of my own code from github/bitbucket down and said "code review this, please". Especially if it was reasonably old and I'd forgotten about it...
Not sure how that would fly outside of the US. In France we have probationary periods but I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months. That sounds to me like a way to get in a bit of trouble - legally, socially, with unions - in the employment context here.
Would be interested in learning whether there’s a French company that does anything like this - maybe a half dozen CDD’s with the express commitment to hire one of the six on a CDI after three months? But who is leaving a CDI on that sort of bet?
"Hire fast, fire fast" is already ingrained in American startups, so I think the policy outlined in this article would be easier to adopt in the US. Americans in general view jobs as more transient than Europeans do.
(2) claiming people didn’t read the linked article is actually one of the few things that’s explicitly called out in the HN guidelines as not being kosher. Please don’t.
Worst case scenario is that you do quality vetting and then place these hires into other organizations that need them and (maybe) don't hire as efficiently. If you're a big org, HR people should know HR people and make that happen. If you're at a small org, just use contacts of the founder/C-suite folks -- good people don't grow on trees and will be welcome additions to other companies/teams.
The more likely result is that a not small percentage of the people actually interview way better than they perform. It's ok to let these people find a new place to work -- they have effectively engaged in false advertising.
> Not sure how that would fly outside of the US.
Why not? The purpose of probationary period is precisely that: to see if things work out. If they don't, the probationary period ends and the employer simply doesn't extend the employment.
> [...] I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months.
From the short fragment you cited I got the impression that the goal is not to choose a single candidate from the bunch, but to keep potentially all of them. Though I may be wrong, as I haven't read TFA.
Simple! Simple for the employer but a major issue for the employee.
Americans value corporations over people. In Europe it's the other way around.
If, however, you're already employed, joining this company looks like an awful proposition. Assuming they don't lie to their recruits about their likelihood to pass the probationary period, they're gonna have a really hard time recruiting anybody who already has a stable and not-horrible job. This is gonna screw the corporation pretty hard as soon as they need to hire senior people rather than startup cannon fodder.
> Simple! Simple for the employer but a major issue for the employee.
Well, yes, but from what I see around me, it's a standard practice to first hire for the probationary period of three months, so an employee has to take this into the account. And unless the employee is highly incompetent or the employer is outright hostile, the probationary period usually ends with regular employment.
It's good that the Europe is generally favourable towards the employees, but employers also need a little slack, don't you think? We can't only put obstacles in their way.
As for Helpful, I wouldn't work for a company that uses those sorts of recruitment practices. What they are doing feels very sketchy to me.
It massively balances the recruitment process in their favour. They are putting all the risk on to the candidates as they have much more to lose if they fail probation. I know from experience short duration jobs on CVs/Resumes raises alarm bells with recruiters. Plus, it could affect benefit entitlements too if they fail probation as that could be seen as a firing.
What if they have one position and decided to hire all five candidates on probation and make them compete against each other? That would be so stressful.
They could also misuse this process to quickly boost staff numbers for a short period instead of hiring contract staff.
It feels like the author is trying to use spin to make what is an unfair recruitment process sound like a good thing.
This process doesn't put more risk on the employee, because at any job and with any interview process, one would hope that both the company and the candidate are still in the honeymoon period within the first 90 days. So even if I passed the 5 hour interview, I may not pass the first 90 days.
The biggest difference, is that I'm transparent about the fact that interviews are not a good predicator (I guess I could waste everyone's time by spending 5 hours interviewing?)
No problem whatsoever in doing it in post-Communist EU countries. In fact it's the daily bread in low cost and outsourcing centers over there. It's a very fertile land for the most exploitive cost-cutting corporate practices.
Not only do I refuse to ask candidates quizzes, but after getting enough professional experience, I started refusing to answer them when I was looking for new positions. One such case involved two executives that interviewed me for a certain senior R&D position. The interview was going well when at a certain point one of them asked if he could test me on some professional stuff. I politely answered that while I respect their candidate filtering methods, it doesn't fit my MO and that I'll pass on that. Not surprisingly, I later received a negative reply from them. A couple of weeks passed and I was hired for the same position by a much larger company (and with much better compensation) that didn't insist on me standing next to a whiteboard to see if I can pick up on some silly trick. About 3 months later, I received a call from one of the executives in the company from which I received a negative reply. Apparently they hired someone who had managed to pass their interview tests with flying colours, but was terrible at his job and so they asked me whether I would like to work for them (of course, this time with no tests). I said I'll pass on that too.
I think the reason for the difficulty in finding the right people for the job stems from a deeper problem of people having lost touch with their inner drive and resorting to external means to understand what is good for them. It starts in grade school and continues on from there. This is not a problem that can (or should) go away quickly, but the more I see people at least being aware of the issue, the more hopeful I am that a more sane process for people fulfilling their potential will eventually replace the existing method.
I like to work through a problem. The problem is synthetic, unfortunately, but anything actually relevant will give too much of a leg up to people who are familiar with frameworks. Steps: (a) discuss the problem and come up with potential solutions, and once we've agreed on a solution (b) turn the solution into code in any language they want, as long as we can easily install it on Ubuntu. An explicit non-goal is actually coming up with a solution to the problem: it's great if they do come up with a solution, but far more important is mind-melding on a problem and solution, and being able to convert agreed solutions into working code.
The idea is to simulate work: I assume that everyone we interview has at least basic ability to code (we use a Codility pre-check), so I create a scenario where I'd be helping set up a team member to work on a functional piece of the application. Communicate and ensure we have a shared understanding of the problem, discuss a solution, and see them actually produce a solution.
Once we have a solution, I do want to know if they understand what the performance characteristics are; that's a very practical concern, as the company I work for deals with data batches ranging in 100 items to 10 million items, so code should be written to scale linearly at worst.
This seems a lot more important in the hiring process for tech people now as technology is usually the product or output of a company as opposed to being shut up in a basement somewhere just helping a company operate.
We've just spoke to an internal IT recruiter about this and he's echoed a lot of the sentiments put across in this thread. Links below if you wanna listen :)
* Four or five-hour interviews. * Interview prep suggested by recruiters for tech interviews. * All-day work sessions pairing with employees. * "Homework" that can take anywhere from 5 hours to days. * Multiple online sessions, each to solve a tech riddle.
I can't imagine how I could've done this when holding a job at the same time. I'd have to be incredibly picky about who I chose to interview with - which means, I wouldn't have interviewed with my current company because they didn't interest me during the screening, only until after the interview when I got to talk with actual developers.
Most candidates aren't unemployed; they're switching jobs. Leaving a job they don't like, or looking for an upgrade. Many have to be persuaded to leave their current employer.
If I were thinking about switching, I'd want a lot more commitment from my future employer than "we'll hire you and four more guys for the same position, then we'll see which one of you will last 90 days". Regardless of my confidence in being able to do the job, who wants to compete for a job for 90 days? Interviews are horrible and stressful, but this is just replacing them with what is essentially a 90 day interview for which you have you quit your current job.
Also:
> For example, let’s say that someone is working on our mobile client and it’s not going as quickly as we need it to go. We’ll
... work with them to identify and remove the impediments slowing them down, while revising our plan to be more realistic?
> let them know that they need to speed up
This guy is an asshole.
Actually, my issues are kind of entertaining when they don't get in the way of my livelihood. My brain appears to prioritize processing interaction with people, especially strangers, over some other kinds of activity, including the kind that's needed to solve logic problems. Ask me to take some open-ended time alone to write a solution to a problem, and I'll give you one when I'm done. Ask me to do the same thing with people watching or, worse, interacting with me as I do it, and you will get random results that may or may not bear any relation to the problem.
It affects things other than coding. When she was a teenager, my daughter sometimes engaged me in conversation when I was driving somewhere, just to see where we would end up. I remember a particular instance of winding up in the parking lot of a Safeway in Capitola, California, wondering why I was there, while my daughter laughed her head off.
I've been at this programming thing for a long time now. I have a reasonable idea of how good I am at it. Given the right circumstances and the right kinds of problems, I can be (and have been) extremely productive. I've been described by someone paying me as one of those "10X" programmers, and the dvcs logs bore him out (but I know what he didn't: if the tools and goals and problem space had been different, or if the work circumstances had been different, then I wouldn't have been nearly as productive).
But technical interviews aren't going to reveal any of that, certainly not about me, specifically. I'm always going to look like something between an idiot and a mediocrity in the typical technical interview.
Various critics are complaining that the OP's methods aren't going to work, but all the data we have says that current fashions in hiring already don't work. The correlation between interview performance and job performance is laughable. Companies all like to say they hire "the best"; what they really mean is that they hire the best that currently-known methods can distinguish, which is to say, a random selection of people. About the most you can say about current methods is that they select for people who want a job, which I suppose is better for hiring than pure sortition.
We don't know how to hire good people in technology. Popular hiring strategies are voodoo. The only method that has been shown to produce much better results than chance is blind, standardized skills-testing, which is not currently popular.
Technical interviews are nonsense. The proper role of interviewing is to find out whether the candidate seems to be a glaring asshole. If you want to select for skills, administer standardized tests. If you don't want to do that, then it doesn't matter much what you do. It all seems to be about equally useless.
You might try doing a Tarot card reading for the candidate.
You lost all your credibility with one sentence. Congratulations.
Can you explain the basis for that opinion?
Perhaps the focus is wrong. Perhaps it's not the 'technical' part of the technical interview that causes this disparity. Perhaps it's just good ol' fashioned racism or prejudices, and really the part of the technical interview that causes a disproportionate number of white males to be hired is simply the fact that the interviews happen with the interviewer fully cognizant of the applicants race and gender. You'll notice that the article also mentioned their disdain for being able to see the applicant.
To dismiss a fact that reasonably straightforwardly follows from empirical evidence and limited options for causality is simply obstinancr.
That wasn't the claim.
Simpler explanation: there are less women applying and therefore less women selected. IMO framing an individual getting a job as “representing” a particular group is just faulty thinking created by a faulty ideology.
1. women and minorities are underrepresented. True. That does not imply there is sexism. In reality, women have a 2:1 chance over men to get hired, just because everyone is desperate to hire women. Be it to improve the image, whatever. Source http://news.cornell.edu/stories/2015/04/women-preferred-21-o...
2. Norway (correct me if I'm wrong on the country) experimented with genderless and faceless applications. The result: Men were actually favoured over women in STEM. How can we explain that? It's certainly not sexism.
At the end of the day, it comes down to this: it is very controversial to say men and women chose differently, but they do. And there's nothing wrong with that! Isn't that what early feminists fought for? Were is the "sexism" in plumbing, oil rigs, and other less desirable jobs? There are virtually only men on those jobs. Tells you what these "diversity" people really are: jealous.
EDIT: Grammar
Norway hired men more often than women with genderless applications. Science cannot explain this, just like the tides of the ocean, or magnets.
At the end of the day, people fighting for equal representation are just jealous, and they can't accept that their Y chromosome made them not want to work on an oil rig.
However, the rest of the article makes some good points (testing on the ability to do the job is a better predictor of job performance), you shouldn’t dismiss it out of hand.