Oh we don’t make the candidate do actual work. It’s basically a simple app that shouldn’t take longer than 2-3 hours. And basically, you write a simple app that loads a bunch of images from an image server like flicker or google photos using a public api, display it in a grid view, and allow you to zoom in on the image. Should be easy peasy….
Actually for our interview process, we offer a choice.
1. Take home assignment
or
2. Answer programming questions on an whiteboard in front of engineers
We don’t care which approach, and either is fine, but a lot of us wanted to offer this 1st option because a lot of us, including me don’t do well with the traditional whiteboard approach because we don’t write good code under duress and with people looking over our shoulder. And some people like me, knowing there’s the google/facebook style “grilling” interview, I don’t want spend time studying for an interview pretending I can solve these irrelevant brain teaser IQ questions that Google and similar companies love to give candidates to test their IQ than their skillset, and don’t want to be part of a system that encourages that practice. But that’s just me.
Almost all candidates choose (1)
Because a lot of candidates who otherwise would write software well but can’t do so under stress (like an 1 hour interview in front of people on a whiteboard) would rather take the same time at home in the comfort of their own place. And since it’s open book, open internet, open anything, we encourage people to be resourceful as if they were on the job and didn’t know how to do something to look it up themselves. We don’t care, as long as they are honest about it, and during the panel interview we ask questions about why they did certain things, and made certain decisions, or how does a piece of code they (might have) copied and pasted works…Because that’s what people these day do anyway….As long as you know what it does, doesn’t really matter if you wrote it from scratch or not.
And there’s been studies that the old style of technical interview does not really work well.
“Tech sector job interviews assess anxiety, not software skills”
“Technical interviews are feared and hated in the industry, and it turns out that these interview techniques may also be hurting the industry’s ability to find and hire skilled software engineers,” says Chris Parnin, an assistant professor of computer science at NC State and co-author of a paper on the work. “Our study suggests that a lot of well-qualified job candidates are being eliminated because they’re not used to working on a whiteboard in front of an audience.”
Technical interviews in the software engineering sector generally take the form of giving a job candidate a problem to solve, then requiring the candidate to write out a solution in code on a whiteboard — explaining each step of the process to an interviewer.
Previous research found that many developers in the software engineering community felt the technical interview process was deeply flawed. So the researchers decided to run a study aimed at assessing the effect of the interview process on aspiring software engineers.
For this study, researchers conducted technical interviews of 48 computer science undergraduates and graduate students. Half of the study participants were given a conventional technical interview, with an interviewer looking on. The other half of the participants were asked to solve their problem on a whiteboard in a private room. The private interviews did not require study participants to explain their solutions aloud, and had no interviewers looking over their shoulders.
Researchers measured each study participant’s interview performance by assessing the accuracy and efficiency of each solution. In other words, they wanted to know whether the code they wrote would work, and the amount of computing resources needed to run it.
“People who took the traditional interview performed half as well as people that were able to interview in private,” Parnin says. “In short, the findings suggest that companies are missing out on really good programmers because those programmers aren’t good at writing on a whiteboard and explaining their work out loud while coding.”
Also, interesting note:
The researchers also note that the current format of technical interviews may also be used to exclude certain job candidates.
“For example, interviewers may give easier problems to candidates they prefer,” Parnin says. “But the format may also serve as a barrier to entire classes of candidates. For example, in our study, all of the women who took the public interview failed, while all of the women who took the private interview passed. Our study was limited, and a larger sample size would be needed to draw firm conclusions, but the idea that the very design of the interview process may effectively exclude an entire class of job candidates is troubling.”
What’s more, the specific nature of the technical interview process means that many job candidates try to spend weeks or months training specifically for the technical interview, rather than for the actual job they’d be doing.
“The technical interview process gives people with industry connections an advantage,” says Mahnaz Behroozi, first author of study and a Ph.D. student at NC State. “But it gives a particularly large advantage to people who can afford to take the time to focus solely on preparing for an interview process that has very little to do with the nature of the work itself.
“And the problems this study highlights are in addition to a suite of other problems associated with the hiring process in the tech sector, which we presented at ICSE-SES [the International Conference on Software Engineering, Software Engineering In Society],” adds Behroozi. “If the tech sector can address all of these challenges in a meaningful way, it will make significant progress in becoming more fair and inclusive. More to the point, the sector will be drawing from a larger and more diverse talent pool, which would contribute to better work.”
