Is that… is that from Harry Potter?
June 19, 2017 11:23 AM Subscribe
Haha, but also oh no I'm sad now and I'm not even looking for a job right now.
Nothing kills my desire to create tech like tech culture.
posted by one of these days at 11:43 AM on June 19, 2017 [30 favorites]
Nothing kills my desire to create tech like tech culture.
posted by one of these days at 11:43 AM on June 19, 2017 [30 favorites]
One would think that eliminating stupid hiring questions would be a competitive advantage in hiring.
Also, how far up the hiring chain do stupid interview questions go? When Facebook scalps a Google VP, presumably they're not expecting them to whiteboard anything.
posted by leotrotsky at 11:56 AM on June 19, 2017 [4 favorites]
Also, how far up the hiring chain do stupid interview questions go? When Facebook scalps a Google VP, presumably they're not expecting them to whiteboard anything.
posted by leotrotsky at 11:56 AM on June 19, 2017 [4 favorites]
Painful read.
One would think that eliminating stupid hiring questions would be a competitive advantage in hiring.
There are companies that specifically advertise it.
posted by Tell Me No Lies at 12:06 PM on June 19, 2017 [4 favorites]
One would think that eliminating stupid hiring questions would be a competitive advantage in hiring.
But what if having this sort of gauntlet of mind puzzles is part of your "brand"? And what if, even though it doesn't actually help you get the most suited employees, it does make those employees feel like they won a contest and thus increase their loyalty to the company at a subconscious level?
And what if being able to craft this sort of test for applicants is just a kind of intellectual masturbation for the people in power in tech culture? Huh? What then?
posted by Navelgazer at 12:09 PM on June 19, 2017 [28 favorites]
But what if having this sort of gauntlet of mind puzzles is part of your "brand"? And what if, even though it doesn't actually help you get the most suited employees, it does make those employees feel like they won a contest and thus increase their loyalty to the company at a subconscious level?
And what if being able to craft this sort of test for applicants is just a kind of intellectual masturbation for the people in power in tech culture? Huh? What then?
posted by Navelgazer at 12:09 PM on June 19, 2017 [28 favorites]
Yep. I was asked to do some whiteboarding at an interview a while ago and this was more or less my experience, even though the interviewers were coders themselves.
Them: Okay, here's the input and here's the expected output. Write some code that will transform one into the other.
5 minutes later…
Them: Okay, well, I guess that works, but that's not the answer we have written down. Can you think of another way of doing it?
5 minutes later…
Them: I suppose, but what if the input was -this- and the output was -that- instead?
5 minutes later…
Them: Right, but the solution we actually have written down is this.
Me: Interesting. That solution is more complicated and provably less efficient than what I wrote. Here's why:…
Them: But… it's the solution we have written down!
Result: I didn't get the job. (Though I don't think this was the reason.)
posted by WaylandSmith at 12:09 PM on June 19, 2017 [66 favorites]
Them: Okay, here's the input and here's the expected output. Write some code that will transform one into the other.
5 minutes later…
Them: Okay, well, I guess that works, but that's not the answer we have written down. Can you think of another way of doing it?
5 minutes later…
Them: I suppose, but what if the input was -this- and the output was -that- instead?
5 minutes later…
Them: Right, but the solution we actually have written down is this.
Me: Interesting. That solution is more complicated and provably less efficient than what I wrote. Here's why:…
Them: But… it's the solution we have written down!
Result: I didn't get the job. (Though I don't think this was the reason.)
posted by WaylandSmith at 12:09 PM on June 19, 2017 [66 favorites]
The central thing that this piece satirizes is the prevalence of cargo cult practices. It's so odd. Programmers *seem* to tend towards independence in temperament, and have to have *some* degree of logical thinking skills in order to model domain logic in code. And then there's the whole "disruption" thing which would imply some resistance towards simply adopting a given observed practice because it's a fashionable norm. From those givens you might suppose there would be wide variations in hiring practices.
But that's not how it pans out either for engineering or hiring engineers. Cargo cult stuff is everywhere, people adopt solutions without thinking about what problems they purport solve let alone any evidence that they're effective, popularity drives picks more surely than it does for dates to a high school prom. The mere fact that Angular is one of the top front-end frameworks in terms of mindshare is a severe indictment of the industry on its own -- it just shouldn't have happened, yet here we are.
The charitable explanation I can think of is that at some level, a good portion of the industry (possibly including myself) is really out of their depth because of the complexity involved in doing good software development, so we're relying on heuristics of varying real utility. Likewise, the complexity involved in *hiring* someone to do software development places most people out of their depth both on first-order and second-hand levels.
So, cargo cult hiring it is!
posted by wildblueyonder at 12:09 PM on June 19, 2017 [29 favorites]
But that's not how it pans out either for engineering or hiring engineers. Cargo cult stuff is everywhere, people adopt solutions without thinking about what problems they purport solve let alone any evidence that they're effective, popularity drives picks more surely than it does for dates to a high school prom. The mere fact that Angular is one of the top front-end frameworks in terms of mindshare is a severe indictment of the industry on its own -- it just shouldn't have happened, yet here we are.
The charitable explanation I can think of is that at some level, a good portion of the industry (possibly including myself) is really out of their depth because of the complexity involved in doing good software development, so we're relying on heuristics of varying real utility. Likewise, the complexity involved in *hiring* someone to do software development places most people out of their depth both on first-order and second-hand levels.
So, cargo cult hiring it is!
posted by wildblueyonder at 12:09 PM on June 19, 2017 [29 favorites]
Note to self: when we send a rejection letter to this candidate, be sure to include feedback that is too vague to be of any use to them, but will avoid any lawsuits.
So these companies, they actually send rejection letters? And the letters actually have feedback, albeit vague feedback? Quick, someone tell me where the online application is. I have a few hours to kill.
posted by scratch at 12:16 PM on June 19, 2017 [8 favorites]
So these companies, they actually send rejection letters? And the letters actually have feedback, albeit vague feedback? Quick, someone tell me where the online application is. I have a few hours to kill.
posted by scratch at 12:16 PM on June 19, 2017 [8 favorites]
This is slightly "can you do my homework for me" but what does a *good* dev interview look like? I realised pretty quickly that interview performance and job performance are very different things. Right now I'm looking for the first person I'll actually be in charge of in my life - ideally a decent developer with some maths aptitude who can talk to business people (willing to compromise slightly on one of those three things). And no, I won't be asking any stupid stupid "gotcha" interview questions.
It's very frustrating to deal with recruiters because they want to match a list of buzzwords ("10 years Angular experience") when in practise if someone is decent they can pick up whatever technologies we happen to use quickly enough. So ultimately what mostly matters is a proven track record, and proving that is at the whim of previous managers to an extent (it's not their fault if their last boss was an arsehole who won't give them a reference out of pettiness).
So, given that some people are much slicker in interviews than others, for non job-performance-related reasons, what do you do?
posted by kersplunk at 12:22 PM on June 19, 2017 [6 favorites]
It's very frustrating to deal with recruiters because they want to match a list of buzzwords ("10 years Angular experience") when in practise if someone is decent they can pick up whatever technologies we happen to use quickly enough. So ultimately what mostly matters is a proven track record, and proving that is at the whim of previous managers to an extent (it's not their fault if their last boss was an arsehole who won't give them a reference out of pettiness).
So, given that some people are much slicker in interviews than others, for non job-performance-related reasons, what do you do?
posted by kersplunk at 12:22 PM on June 19, 2017 [6 favorites]
I can't tell... was this poking fun at what coders are expected to know or poking fun at translation? Non-tech folks doing interviews, Scrum Masters that don't know what things take? I can't... I can't... I can't tell... I feel entirely too familiar with this level of nonsense.
I mean... there was no question about the interdependencies of everyone's translations... and for the other groups that I have to wait on to build my base translations, getting on their calendar... finding funding for them to get headcount to do said preliminary translation work... No talk about why I always have to attend the French-> Japanese translation sessions... No talk about about the efficiencies of translating everything to root languages first and then translating from the roots back out... No talk about certain groups only accepting their label translations if it met certain design criteria totally different from every other group... I'm... I'm ...
I'm lost... was this satire?
posted by Nanukthedog at 12:24 PM on June 19, 2017 [6 favorites]
I mean... there was no question about the interdependencies of everyone's translations... and for the other groups that I have to wait on to build my base translations, getting on their calendar... finding funding for them to get headcount to do said preliminary translation work... No talk about why I always have to attend the French-> Japanese translation sessions... No talk about about the efficiencies of translating everything to root languages first and then translating from the roots back out... No talk about certain groups only accepting their label translations if it met certain design criteria totally different from every other group... I'm... I'm ...
I'm lost... was this satire?
posted by Nanukthedog at 12:24 PM on June 19, 2017 [6 favorites]
Our new approach to interviewing is to send a interview project after the initial phone screening. For web devs, it's a basic sketch of a web page that we ask them to build out in whatever framework they feel is best. We usually give them a week to complete the exercise, but try to make it simple enough that they could reasonably complete it in under an hour.
When they come in for the in person interview, they present their solution to the project and walk us through how they built it, and why they chose the approach that they took.
This seems to work really well. It gives us a feel for how a candidate approaches the project. On the candidate side, they seem to like it. There aren't any gotcha questions. If they want to use a white board to illustrate something they can, but it's not required.
posted by Eddie Mars at 12:34 PM on June 19, 2017 [27 favorites]
When they come in for the in person interview, they present their solution to the project and walk us through how they built it, and why they chose the approach that they took.
This seems to work really well. It gives us a feel for how a candidate approaches the project. On the candidate side, they seem to like it. There aren't any gotcha questions. If they want to use a white board to illustrate something they can, but it's not required.
posted by Eddie Mars at 12:34 PM on June 19, 2017 [27 favorites]
So, cargo cult hiring it is!
Joel Spolsky's whiteboarding interview blogposts and Google's clever word question practices - both hugely influential - have long since been abandoned and disavowed by those companies. Google has admitted that their core function was to make the interviewer feel clever, and that they had no measurable benefit to effective hiring or retention. But they practices have persisted, and the result has a been a brutally broken (and structurally sexist and racist as a side effect) hiring environment.
The cruelly ironic upshot of all this is that the same people who deride "stack overflow programmers" have adopted all these broken, garbage HR practices that they read about on the Web without really understanding what they're supposed to do or how they're supposed to work.
posted by mhoye at 12:48 PM on June 19, 2017 [11 favorites]
Joel Spolsky's whiteboarding interview blogposts and Google's clever word question practices - both hugely influential - have long since been abandoned and disavowed by those companies. Google has admitted that their core function was to make the interviewer feel clever, and that they had no measurable benefit to effective hiring or retention. But they practices have persisted, and the result has a been a brutally broken (and structurally sexist and racist as a side effect) hiring environment.
The cruelly ironic upshot of all this is that the same people who deride "stack overflow programmers" have adopted all these broken, garbage HR practices that they read about on the Web without really understanding what they're supposed to do or how they're supposed to work.
posted by mhoye at 12:48 PM on June 19, 2017 [11 favorites]
Joel Spolsky's whiteboarding interview blogposts and Google's clever word question practices - both hugely influential - have long since been abandoned and disavowed by those companies. Google has admitted that their core function was to make the interviewer feel clever, and that they had no measurable benefit to effective hiring or retention.
Heh, Google hasn't disavowed shit. They still do the same ridiculous interviews that are the inspiration of this post. The difference is that the recruiter you work with is upfront with the fact that their hiring process rejects 9 good enough engineers to for each one that gets hired.
posted by sideshow at 1:02 PM on June 19, 2017 [7 favorites]
Heh, Google hasn't disavowed shit. They still do the same ridiculous interviews that are the inspiration of this post. The difference is that the recruiter you work with is upfront with the fact that their hiring process rejects 9 good enough engineers to for each one that gets hired.
posted by sideshow at 1:02 PM on June 19, 2017 [7 favorites]
So, given that some people are much slicker in interviews than others, for non job-performance-related reasons, what do you do?
I don't claim to be an expert in hiring programmers, but we just hired one (although not 100% of his duties), and here's the questions I asked:
posted by AzraelBrown at 1:06 PM on June 19, 2017 [14 favorites]
I don't claim to be an expert in hiring programmers, but we just hired one (although not 100% of his duties), and here's the questions I asked:
- What was the last C# project you worked on? (get them talking about their process, and confirm they had the skills -- a couple applicants failed this question because, even though they put C# on their resume, they had never actually written a really-real, non-class-assignment program in C# that actually does something)
- Can you explain what a class or a struct is, and the difference between them? (Again, to filter out the people who understand programming vs think they can muddle through it)
- If have a file, but it doesn't have a file extension, how do I figure out what kind of file it is? (a real-world example of a problem they might encounter here, plus testing thinking process and technical knowledge; the best answer is Magic Number, but if they showed some technical understanding of how files are structured it gets them points)
- Have you ever written anything that interacted with a Web Service? (another real-world thing we work with)
- A couple more specific questions (SQL, image formats, etc.)
posted by AzraelBrown at 1:06 PM on June 19, 2017 [14 favorites]
In all the years I have done interviewing people for computing jobs I have never used the interview to find the technical skills of the applicant - well not directly.
As far as I am concerned those should have been sorted out before then.
The interview is for determining the personality and whether they will fit in with the existing staff
posted by Burn_IT at 1:07 PM on June 19, 2017 [4 favorites]
As far as I am concerned those should have been sorted out before then.
The interview is for determining the personality and whether they will fit in with the existing staff
posted by Burn_IT at 1:07 PM on June 19, 2017 [4 favorites]
This is slightly "can you do my homework for me" but what does a *good* dev interview look like?
On the hardware side, the popular interviewing technique recently is called "behavioral interview questions". Here's one quick guide on formulating tech-based behavioral questions but there are dozens of resources. You do need someone in the room who at least at a high level understands the technical requirements, these can't really be conducted by someone in HR or a recruiter except to screen for the basic ability to string two words together.
posted by muddgirl at 1:08 PM on June 19, 2017 [2 favorites]
On the hardware side, the popular interviewing technique recently is called "behavioral interview questions". Here's one quick guide on formulating tech-based behavioral questions but there are dozens of resources. You do need someone in the room who at least at a high level understands the technical requirements, these can't really be conducted by someone in HR or a recruiter except to screen for the basic ability to string two words together.
posted by muddgirl at 1:08 PM on June 19, 2017 [2 favorites]
I worry less about what they are asking me and more about the responses to things I ask them :)
I have seen some absolutely stupid interview processes. Things that will daunt even an intelligent and qualified applicant. That tells me a lot about the company culture when I run into that and I am so not going there... I have gotten a few flabbergasted responses when they follow-up and I tell them they failed the interview. :)
posted by twidget at 1:20 PM on June 19, 2017 [10 favorites]
I have seen some absolutely stupid interview processes. Things that will daunt even an intelligent and qualified applicant. That tells me a lot about the company culture when I run into that and I am so not going there... I have gotten a few flabbergasted responses when they follow-up and I tell them they failed the interview. :)
posted by twidget at 1:20 PM on June 19, 2017 [10 favorites]
Heh, Google hasn't disavowed shit. They still do the same ridiculous interviews that are the inspiration of this post. The difference is that the recruiter you work with is upfront with the fact that their hiring process rejects 9 good enough engineers to for each one that gets hired.
I think he meant they no longer do the lateral thinking/Fermi estimation/straight-up puzzle questions which they popularized/with which they became associated some years ago - at least not for technical positions. Unless it's changed substantially in the last few years they do still put you through five hours of technical-ish questions and whiteboard stuff, as do most of the big software companies.
posted by atoxyl at 1:24 PM on June 19, 2017 [3 favorites]
I think he meant they no longer do the lateral thinking/Fermi estimation/straight-up puzzle questions which they popularized/with which they became associated some years ago - at least not for technical positions. Unless it's changed substantially in the last few years they do still put you through five hours of technical-ish questions and whiteboard stuff, as do most of the big software companies.
posted by atoxyl at 1:24 PM on June 19, 2017 [3 favorites]
What you do instead: two approaches I've used.
One: ask detailed questions about a project they did (their choice). Basic idea: look at actual work: people are far more revealing about what they've really done rather than considering how they'd approach an abstract task Ask about problems they had and how they faced them. Look out for whether they do any planning or documentation, how they made sure they understood the requirements, how they worked with their team, how they test, what they considered a problem, what they consider interesting.
Two: give a short programming exercise, in any language they can work with, and an actual computer; leave them alone to work on it. I've done this in multiple interviews so someone else will cover, y'know, actually talking to the person. The intention is not to stress them out or play gotcha; the idea is to see if they, as a coder, can write code. Just as important: do they ask questions about the task? Did their code work? Did they think about bad input or edge cases?
posted by zompist at 1:25 PM on June 19, 2017 [4 favorites]
One: ask detailed questions about a project they did (their choice). Basic idea: look at actual work: people are far more revealing about what they've really done rather than considering how they'd approach an abstract task Ask about problems they had and how they faced them. Look out for whether they do any planning or documentation, how they made sure they understood the requirements, how they worked with their team, how they test, what they considered a problem, what they consider interesting.
Two: give a short programming exercise, in any language they can work with, and an actual computer; leave them alone to work on it. I've done this in multiple interviews so someone else will cover, y'know, actually talking to the person. The intention is not to stress them out or play gotcha; the idea is to see if they, as a coder, can write code. Just as important: do they ask questions about the task? Did their code work? Did they think about bad input or edge cases?
posted by zompist at 1:25 PM on June 19, 2017 [4 favorites]
Not that the life sciences are perfect either, and there are bits of the article that undermine the title, but I thought this was interesting: How One Tech Startup Ditched Its Brogrammers. tldr, instead of the typical aggro whiteboard interview they actually have candidates give job talks instead.
(Of course a more proximal factor in the increased gender diversity of the team is probably that the life sciences themselves are a lot more evenly split, but, still, Zymergen does do software engineering in addition to biology.)
posted by en forme de poire at 1:29 PM on June 19, 2017 [5 favorites]
(Of course a more proximal factor in the increased gender diversity of the team is probably that the life sciences themselves are a lot more evenly split, but, still, Zymergen does do software engineering in addition to biology.)
posted by en forme de poire at 1:29 PM on June 19, 2017 [5 favorites]
...the lateral thinking/Fermi estimation/straight-up puzzle questions which they popularized/with which [Google] became associated some years ago...
I mean, yes, they adopted it, but credit/blame where it's due: this was Microsoft's interview style before it was Google's (or Facebook's, or Amazon's...).
posted by The Tensor at 1:49 PM on June 19, 2017 [6 favorites]
I mean, yes, they adopted it, but credit/blame where it's due: this was Microsoft's interview style before it was Google's (or Facebook's, or Amazon's...).
posted by The Tensor at 1:49 PM on June 19, 2017 [6 favorites]
Yeah, I guess whether you think of the "why are manhole covers round" or Fermi estimation questions as Microsoft or Google questions depends on your age. To me, thats the classic early 90's-ish Microsoft interview style which a bunch of companies then adopted (including Google).
Both Microsoft and Google have long since banned those kind of questions, but I guess some places still do them? I haven't encountered them in a long time but I also have been with my current employer for 9 years, so I really only know how we do interviews.
posted by thefoxgod at 1:52 PM on June 19, 2017
Both Microsoft and Google have long since banned those kind of questions, but I guess some places still do them? I haven't encountered them in a long time but I also have been with my current employer for 9 years, so I really only know how we do interviews.
posted by thefoxgod at 1:52 PM on June 19, 2017
Speaking of "why are manhole covers round," there is this take on what Feynman would be like being interviewed with that question.
posted by Hactar at 2:30 PM on June 19, 2017 [20 favorites]
posted by Hactar at 2:30 PM on June 19, 2017 [20 favorites]
Both Microsoft and Google have long since banned those kind of questions
I don't know about long since, I had an interviewer at Google unapologetically throw some awfully Fermish questions my way in 2015. But maybe he was an outlier.
posted by Two unicycles and some duct tape at 2:42 PM on June 19, 2017 [1 favorite]
I don't know about long since, I had an interviewer at Google unapologetically throw some awfully Fermish questions my way in 2015. But maybe he was an outlier.
posted by Two unicycles and some duct tape at 2:42 PM on June 19, 2017 [1 favorite]
One would think that eliminating stupid hiring questions would be a competitive advantage in hiring.and/or add themselves to the requisite hipster Github README tracking these sorts of things
There are companies that specifically advertise it.
(though it looks like the original maintainer is starting to neglect it, which is potentially a shame)
posted by bl1nk at 2:43 PM on June 19, 2017 [1 favorite]
Them: Right, but the solution we actually have written down is this.
Me: Interesting. That solution is more complicated and provably less efficient than what I wrote. Here's why:…
Them: But… it's the solution we have written down!
I had this experience in an intermediate Python course in my Data Science program. I was given an input task and a desired output and no restrictions but the feedback I received tended to be "Well, ok, but you didn't do x like in the solution." My response being "My code is brief, faster and does exactly what you wanted. Are there bugs? No? Then give me my points." I had to drop the course because I was tired of arguing with the GAs. Seriously, as someone without a traditional comp sci degree what the fuck do people actually want when it comes to functional code?
posted by Young Kullervo at 3:09 PM on June 19, 2017 [2 favorites]
Me: Interesting. That solution is more complicated and provably less efficient than what I wrote. Here's why:…
Them: But… it's the solution we have written down!
I had this experience in an intermediate Python course in my Data Science program. I was given an input task and a desired output and no restrictions but the feedback I received tended to be "Well, ok, but you didn't do x like in the solution." My response being "My code is brief, faster and does exactly what you wanted. Are there bugs? No? Then give me my points." I had to drop the course because I was tired of arguing with the GAs. Seriously, as someone without a traditional comp sci degree what the fuck do people actually want when it comes to functional code?
posted by Young Kullervo at 3:09 PM on June 19, 2017 [2 favorites]
I interviewed for SoundCloud and their technical challenge was writing a fairly simple python script that was directly applicable to the actual work they did, and I had a week to work on it. It was interesting, and actually made it clear to me that it wasn't a job I'd be interested in, particularly--which was a good thing. If it had been a generic logic puzzle, it wouldn't have told me anything about he job.
posted by empath at 3:21 PM on June 19, 2017 [2 favorites]
posted by empath at 3:21 PM on June 19, 2017 [2 favorites]
This article really isn't making fun of the Fermi estimation and puzzle question interviews -- it's making fun of "CS fundamentals" interviews, which Google most definitely does (at least as of my experience least year), and which many companies cargo cult to varying degrees. Stuff like tree traversal, sorting, and the computational complexity thereof. The "Cracking the Coding Interview" book is full of examples and solutions for them, and the article pokes fun of it by talking about a so-called "Cracking the Translating Interview" book.
posted by zsazsa at 3:36 PM on June 19, 2017 [9 favorites]
posted by zsazsa at 3:36 PM on June 19, 2017 [9 favorites]
A real world project is the gold standard. I not only have people do them I will at the final and elaborate project stage pay candidates to do them. Amazing how much you learn about someone when you see what they consider to be worth the $1,000 you are paying them for it.
posted by MattD at 3:38 PM on June 19, 2017 [5 favorites]
posted by MattD at 3:38 PM on June 19, 2017 [5 favorites]
Question number one: how did the Arabic invasion in the Iberian Peninsula between the years of 711 and 1492 affected the Spanish language?
I’m not sure whether the typo is a feature or a bug in this article. Kind of both, right?
posted by limeonaire at 3:38 PM on June 19, 2017
I’m not sure whether the typo is a feature or a bug in this article. Kind of both, right?
posted by limeonaire at 3:38 PM on June 19, 2017
went to a company that had a surprisingly good interview process. in the morning were a few quite reasonable whiteboard questions that dealt concretely with actual problems they had faced in the course of business. there were no set answers, just interesting non-adversarial discussion between engineers. that was great!
then they had a 3 hour uninterrupted coding portion, with a large pot of coffee, where you had to develop a small subsystem that was also directly related to their business. realistic project under realistic conditions, i.e. free to use stack overflow and free software libraries. (note: they did not pay me.)
if you're going to take a whole day on a technical interview, this is a way better thing to do things than the "interview loop" where you answer 6 inane questions from 6 different people, any of whom could veto you if they're just in a bad mood.
my experience was good enough that I ended up taking the job at the company! then, about a month later, I found the code I had written during the interview in their codebase, in production. that should have been a red flag. things went downhill.
I maintain that their interview process was great, though. Even better would be to have the coding portion evaluated blind, which is totally feasible, because it's actually supposed to be finished and working in some capacity.
posted by vogon_poet at 3:51 PM on June 19, 2017 [6 favorites]
then they had a 3 hour uninterrupted coding portion, with a large pot of coffee, where you had to develop a small subsystem that was also directly related to their business. realistic project under realistic conditions, i.e. free to use stack overflow and free software libraries. (note: they did not pay me.)
if you're going to take a whole day on a technical interview, this is a way better thing to do things than the "interview loop" where you answer 6 inane questions from 6 different people, any of whom could veto you if they're just in a bad mood.
my experience was good enough that I ended up taking the job at the company! then, about a month later, I found the code I had written during the interview in their codebase, in production. that should have been a red flag. things went downhill.
I maintain that their interview process was great, though. Even better would be to have the coding portion evaluated blind, which is totally feasible, because it's actually supposed to be finished and working in some capacity.
posted by vogon_poet at 3:51 PM on June 19, 2017 [6 favorites]
A friend of mine had a couple of interviews for a Google team fairly recently, having been encouraged by another recent hire who assured her she's easily good enough. The first interviewer decided that her theory is shit hot but her practical coding is a bit weak, the second concluded that her practical coding is excellent but her theory needs work. As a lab scientist, the most obvious conclusion I draw from this is that their assay sucks.
"Everything is in a flat structure, except when it comes to salary and responsibilities"
Heh. I work in a (generally very functional, as far as I can tell) biotech startup. On joining I was told that the company has a flat structure, and also that the virology department consisted of me and a guy whose title is "head of virology". Hmmm.
posted by metaBugs at 3:57 PM on June 19, 2017 [6 favorites]
"Everything is in a flat structure, except when it comes to salary and responsibilities"
Heh. I work in a (generally very functional, as far as I can tell) biotech startup. On joining I was told that the company has a flat structure, and also that the virology department consisted of me and a guy whose title is "head of virology". Hmmm.
posted by metaBugs at 3:57 PM on June 19, 2017 [6 favorites]
But maybe he was an outlier.
Well, at both companies they are certainly not _supposed_ to, but they also don't monitor individual interviewers that closely so I'm sure it does still happen sometimes.
The "CS fundamentals" style is more meh, it's not terrible since you should at least be able to learn these things for an interview, but it is weird in that it requires you to study things you don't often use (or can just look up).
The value, such as it is, is that you prove you can understand such things. The problems are many, including the fact that it requires a lot of prep work (like the SAT, with the attendant class/time issues). Someone who can't understand the problems even with study time is unlikely to be a good programmer, IMO. But lots of good devs couldn't do it as a pop quiz, so the prep issue is huge.
Even as a dev with 20 years experience at some of the "top" companies in the field, I would have to spend considerable study time before I could pass one of these interviews again (I mean, CS class was 20+ years ago...). And in the past when I've looked for jobs I always had to study again.
posted by thefoxgod at 3:57 PM on June 19, 2017
Well, at both companies they are certainly not _supposed_ to, but they also don't monitor individual interviewers that closely so I'm sure it does still happen sometimes.
The "CS fundamentals" style is more meh, it's not terrible since you should at least be able to learn these things for an interview, but it is weird in that it requires you to study things you don't often use (or can just look up).
The value, such as it is, is that you prove you can understand such things. The problems are many, including the fact that it requires a lot of prep work (like the SAT, with the attendant class/time issues). Someone who can't understand the problems even with study time is unlikely to be a good programmer, IMO. But lots of good devs couldn't do it as a pop quiz, so the prep issue is huge.
Even as a dev with 20 years experience at some of the "top" companies in the field, I would have to spend considerable study time before I could pass one of these interviews again (I mean, CS class was 20+ years ago...). And in the past when I've looked for jobs I always had to study again.
posted by thefoxgod at 3:57 PM on June 19, 2017
then, about a month later, I found the code I had written during the interview in their codebase, in production. that should have been a red flag. things went downhill.
Why is this a problem? I mean I guess they technically got a days work out of you for free, but they did hire you in the end.
posted by empath at 4:03 PM on June 19, 2017
Why is this a problem? I mean I guess they technically got a days work out of you for free, but they did hire you in the end.
posted by empath at 4:03 PM on June 19, 2017
I know this is meant to be a deeply satirical piece, but judging by my friends working as translators, their jobs are often a bit like being on Jeopardy. Continue all your dev talk - the piece is just a bit of a missed mark for me.
posted by kariebookish at 4:05 PM on June 19, 2017
posted by kariebookish at 4:05 PM on June 19, 2017
Best technical interview I ever had, I got to do a real life, open book programming task that directly pertained to the business. In fact, even though I ultimately declined that position, my understanding is my code went into production because it was literally a task the project team was then working on. Worst interview: white board interview with confrontational interviewer. Or the super aggressively timed test (30 minutes for something like ten coding questions) administered in a room with people walking in and out while I was taking the test.
All the technical tests should be open book/on a computer doing actual relevant kinds of small coding tasks in an IDE. Personally, I rely on reference docs as a psychological crutch, and very frequently Google things I already basically know just because my memory of precise syntax is generally pretty poor even for many languages I'm very experienced with and comfortable working in on the job (ADHD strikes again). I Google technical references for things I already know all the time as a security/anxiety soothing thing. Do the same thing with English and German words I already know, even though I've occasionally gotten accused of being good with words. Tests that are meant to see how people perform under high pressure, if not strictly necessary, are a bad idea because it's been understood for a while now that a lot of really high performers have inordinate levels of doubt and anxiety about their abilities. The pressure cooker approach to candidate selection may be accidentally cutting out many candidates with the very highest potential. That and the "presentability" criteria I've seen used to rule out otherwise technically qualified candidates.
posted by saulgoodman at 4:05 PM on June 19, 2017 [2 favorites]
All the technical tests should be open book/on a computer doing actual relevant kinds of small coding tasks in an IDE. Personally, I rely on reference docs as a psychological crutch, and very frequently Google things I already basically know just because my memory of precise syntax is generally pretty poor even for many languages I'm very experienced with and comfortable working in on the job (ADHD strikes again). I Google technical references for things I already know all the time as a security/anxiety soothing thing. Do the same thing with English and German words I already know, even though I've occasionally gotten accused of being good with words. Tests that are meant to see how people perform under high pressure, if not strictly necessary, are a bad idea because it's been understood for a while now that a lot of really high performers have inordinate levels of doubt and anxiety about their abilities. The pressure cooker approach to candidate selection may be accidentally cutting out many candidates with the very highest potential. That and the "presentability" criteria I've seen used to rule out otherwise technically qualified candidates.
posted by saulgoodman at 4:05 PM on June 19, 2017 [2 favorites]
If the odds are in your favour, poke fun at the awful stuff in tech culture or straight up talk about it. If it misses it will hurt you but if it hits then you have just passed the "will they fit in" test and developed a good rapport with the interviewer/interviewee. There is a lot of hate for tech culture among the people working in it. If you are trying to hire and experienced person this is practically required: "and we definitely don't do X, Y and Z here - man isn't that terrible, haha". Warning: This is so well known that companies lie about this to cover up that they definitely have those problems.
As to good tech interviews: Hopefully their resume had a github profile on it (or similar) so you can read some of their code before the interview and skip a lot of screener questions. If not, then a repo of some code/data and unit test stubs are much better than a written test or whiteboard interview questions. "Make these tests pass, here's the wifi password, I'll be back in a bit".
Then you ask open ended questions, "How would you go about solving problem X in situation Y?", "What are the tradeoffs?", "What bugs/problems would you anticipate and prepare for?". This can be questions about algorithms, high level design, process or all sorts of things.
Get them talking about code that excited or at least interested them, ask general questions and specific questions. Then ask them similar stuff about the most boring and frustrating aspect of the job.
And the standard, "Tell me about a time you've dealt with X" where X is a common bug/problem/culture annoyance/interpersonal issue/etc.
posted by Infracanophile at 5:04 PM on June 19, 2017
As to good tech interviews: Hopefully their resume had a github profile on it (or similar) so you can read some of their code before the interview and skip a lot of screener questions. If not, then a repo of some code/data and unit test stubs are much better than a written test or whiteboard interview questions. "Make these tests pass, here's the wifi password, I'll be back in a bit".
Then you ask open ended questions, "How would you go about solving problem X in situation Y?", "What are the tradeoffs?", "What bugs/problems would you anticipate and prepare for?". This can be questions about algorithms, high level design, process or all sorts of things.
Get them talking about code that excited or at least interested them, ask general questions and specific questions. Then ask them similar stuff about the most boring and frustrating aspect of the job.
And the standard, "Tell me about a time you've dealt with X" where X is a common bug/problem/culture annoyance/interpersonal issue/etc.
posted by Infracanophile at 5:04 PM on June 19, 2017
As a side note, I've recently done a fair amount of interviewing of 'fresh' MS level candidates with little / minimal real world experience. When asked about projects, methodologies and the contents of group work - consistently those with GPAs approaching 4.0 have a much lower grasp of the technical aspects of the project / don't consider alternate methodologies / don't understand whether a different approach would be better. 3.54-3.69 is the GPA sweet spot of the most knowledgeable candidates on fundamentals. From 30ish interviews in the past 3 months, 3.80+ generally talk a big game but have significant deficiencies in their skills, and are overly risk averse with their project work and skills.
I can train soft skills and how to put together a proper presentation. I can't train you to break apart a problem and build out the best first-pass model with minimal instruction in your first two weeks - that takes someone willing to take risks, who asks questions, work through the problem, tries a few solutions, and picks the best one. That my friend, is someone who got into the assignment when he was in grad school and was willing to crack a few eggs in the process.
posted by Nanukthedog at 5:15 PM on June 19, 2017 [2 favorites]
I can train soft skills and how to put together a proper presentation. I can't train you to break apart a problem and build out the best first-pass model with minimal instruction in your first two weeks - that takes someone willing to take risks, who asks questions, work through the problem, tries a few solutions, and picks the best one. That my friend, is someone who got into the assignment when he was in grad school and was willing to crack a few eggs in the process.
posted by Nanukthedog at 5:15 PM on June 19, 2017 [2 favorites]
a real world project …
a github repo …
Both of these select against candidates with day jobs and social lives who work on non-public projects.
Programming is an important part of my life, but I'm not going to spend hours of my precious free time trying to qualify for your opening. (Unless you are SpaceX!)
posted by monotreme at 6:04 PM on June 19, 2017 [12 favorites]
a github repo …
Both of these select against candidates with day jobs and social lives who work on non-public projects.
Programming is an important part of my life, but I'm not going to spend hours of my precious free time trying to qualify for your opening. (Unless you are SpaceX!)
posted by monotreme at 6:04 PM on June 19, 2017 [12 favorites]
I wish I could talk more freely about this, I've interviewed about 50 candidates this year.
Most of us interviewers really want to do a good job, and keep up with research on the subject. We try to make the experience non adversarial, to give candidates a chance to shine. We stay away from gotcha questions and for "guess my favorite algo/data structures" questions.
We would love to do pair programming for a few hours with each candidate. On real world problems. But we work with watch we have.
One thing that is true is that we would rather err on the side of rejecting a good candidate than making a bad hire, but not 9 to 1 like someone suggested.
Reading this thread and similar ones make it sound like the majority of interviews suck. I don't know if it is me and the dozens of other interviewers I know living in bubble, or if there is a very loud minority of people with bad experiences.
Either way, I can assure you that at least one interviewer at at least one of the big tech companies is working really hard on making interviews both a pleasant experience and a good hiring tool, and is aware that the process is very far from ideal.
posted by Dr. Curare at 6:12 PM on June 19, 2017 [4 favorites]
Most of us interviewers really want to do a good job, and keep up with research on the subject. We try to make the experience non adversarial, to give candidates a chance to shine. We stay away from gotcha questions and for "guess my favorite algo/data structures" questions.
We would love to do pair programming for a few hours with each candidate. On real world problems. But we work with watch we have.
One thing that is true is that we would rather err on the side of rejecting a good candidate than making a bad hire, but not 9 to 1 like someone suggested.
Reading this thread and similar ones make it sound like the majority of interviews suck. I don't know if it is me and the dozens of other interviewers I know living in bubble, or if there is a very loud minority of people with bad experiences.
Either way, I can assure you that at least one interviewer at at least one of the big tech companies is working really hard on making interviews both a pleasant experience and a good hiring tool, and is aware that the process is very far from ideal.
posted by Dr. Curare at 6:12 PM on June 19, 2017 [4 favorites]
I just got a tech job at an awesome place that does job talks for interviews.
I'm pretty good at technical presentations, so this worked out great for me, but I do wonder how ESL folks or non-neurotypical folks might have difficulty here.
posted by Sauce Trough at 6:14 PM on June 19, 2017 [1 favorite]
I'm pretty good at technical presentations, so this worked out great for me, but I do wonder how ESL folks or non-neurotypical folks might have difficulty here.
posted by Sauce Trough at 6:14 PM on June 19, 2017 [1 favorite]
Both of these select against candidates with day jobs and social lives who work on non-public projects.
That's why you pay an industry-standard rate up to some hour maximum for their toy project. It's fair, it's among the best ways to actually gauge technical skill set, and it's time the person doesn't have to spend doing whiteboard problems in your office. Instead you can focus on a review of what they wrote and a behavioral interview, which saves time for everyone and is less stressful for the interviewer besides. To suit different working styles you could offer the choice between this and an on-site pairing session.
It wouldn't be a perfect hiring method, but it's an improvement along basically every axis that matters: it's more fair to and inclusive for the interviewee and grants them more flexibility, it's a better means for evaluating their work style, and it's less time intensive for interviewers.
posted by invitapriore at 6:19 PM on June 19, 2017 [1 favorite]
That's why you pay an industry-standard rate up to some hour maximum for their toy project. It's fair, it's among the best ways to actually gauge technical skill set, and it's time the person doesn't have to spend doing whiteboard problems in your office. Instead you can focus on a review of what they wrote and a behavioral interview, which saves time for everyone and is less stressful for the interviewer besides. To suit different working styles you could offer the choice between this and an on-site pairing session.
It wouldn't be a perfect hiring method, but it's an improvement along basically every axis that matters: it's more fair to and inclusive for the interviewee and grants them more flexibility, it's a better means for evaluating their work style, and it's less time intensive for interviewers.
posted by invitapriore at 6:19 PM on June 19, 2017 [1 favorite]
Any code samples are fine. This is a job where a portfolio is necessary, like many jobs. Yes, it does select against people applying for a non-entry level job who can't build a portfolio for some reason (hiring junior programmers works differently, code samples aren't important there).
It's also a job in very high demand, that pays very well, requires a lot of education and the tools and information necessary to build a portfolio are all free (free because other people donated it to the world, so there is a cultural expectation that you will give back when you can). I can't bring myself to feel bad about a cultural norm that expects the mid and upper tiers of an upper tier job to come with work samples that take a couple sundays to build up.
Graphic/UI/UX designers, who are paid less, will play a tiny violin for you.
posted by Infracanophile at 6:19 PM on June 19, 2017 [2 favorites]
It's also a job in very high demand, that pays very well, requires a lot of education and the tools and information necessary to build a portfolio are all free (free because other people donated it to the world, so there is a cultural expectation that you will give back when you can). I can't bring myself to feel bad about a cultural norm that expects the mid and upper tiers of an upper tier job to come with work samples that take a couple sundays to build up.
Graphic/UI/UX designers, who are paid less, will play a tiny violin for you.
posted by Infracanophile at 6:19 PM on June 19, 2017 [2 favorites]
what do you do?
Consider Manager Tools which was pitched by some lawyers as the place to go to learn to be a manager because Engineers are not people people like lawyers.
posted by rough ashlar at 6:32 PM on June 19, 2017
Consider Manager Tools which was pitched by some lawyers as the place to go to learn to be a manager because Engineers are not people people like lawyers.
posted by rough ashlar at 6:32 PM on June 19, 2017
As someone familiar with both academic talks and tech culture, en forme de poire's link is a fascinating bit of convergence. I've long thought that a smart company would realize that hiring outside the typical profile would get them better, more accessible candidates. It's interesting that one would be willing to put it out there in writing.
One thing people aren't mentioning: tech has functioned as winner take all for quite some time. What that means, in practice, is that people are desperate to work for the winners for all sorts of reasons. Often times it's prestige, or for resume boosts, but lately it's because of restricted stock units (RSUs). It's not at all uncommon to run into someone at a place like Google that's effectively doubled (or more) their already too high comp package via RSUs. In this environment, broken interview processes are actually a feature in that they help create false negatives from the enormous candidate pool they've got to navigate.
Which would be fine if they actually hired for effectiveness instead of...whatever it is for which they're testing. This would also be fine if they were only screwing themselves, but 1) they're creating a terrible example, which the rest of the industry follows, regardless and 2) they're also purposely depriving competitors or emerging threats of talent.
posted by NoRelationToLea at 6:45 PM on June 19, 2017
One thing people aren't mentioning: tech has functioned as winner take all for quite some time. What that means, in practice, is that people are desperate to work for the winners for all sorts of reasons. Often times it's prestige, or for resume boosts, but lately it's because of restricted stock units (RSUs). It's not at all uncommon to run into someone at a place like Google that's effectively doubled (or more) their already too high comp package via RSUs. In this environment, broken interview processes are actually a feature in that they help create false negatives from the enormous candidate pool they've got to navigate.
Which would be fine if they actually hired for effectiveness instead of...whatever it is for which they're testing. This would also be fine if they were only screwing themselves, but 1) they're creating a terrible example, which the rest of the industry follows, regardless and 2) they're also purposely depriving competitors or emerging threats of talent.
posted by NoRelationToLea at 6:45 PM on June 19, 2017
Any code samples are fine. This is a job where a portfolio is necessary, like many jobs.
Most programmers can't provide code samples because their work product is company property. I don't have any code I've written in the last 20 years that I can legally share with prospective employers.
I mean, I guess I could make something up, but thats no different from just giving me a "homework assignment" interview.
posted by thefoxgod at 6:52 PM on June 19, 2017 [16 favorites]
Most programmers can't provide code samples because their work product is company property. I don't have any code I've written in the last 20 years that I can legally share with prospective employers.
I mean, I guess I could make something up, but thats no different from just giving me a "homework assignment" interview.
posted by thefoxgod at 6:52 PM on June 19, 2017 [16 favorites]
It also depends on the tools you work with on the job. I'm a designer, not a programmer, but all my design is in discrete assets in our content management system--which is not the latest technology, and which updates much less quickly than the bleeding edge does, as is typical in a corporate environment. And as unflattering as it is to admit it, after I get home from work, I just wanna chill and put my feet up, not work on more design. Yes, this leads to skill stagnation (and has, in my case), but it seems like if you want to stay competitive, it invariably means putting in more hours of your own time on top of the demands of your job--with no end in sight, except to go to ridiculous interviews and be asked irrelevant questions to finally be low-balled for your skills set because it's such a "great opportunity". Yeah, being expected to work 50-hour weeks for peanuts isn't an "opportunity".
posted by Autumnheart at 6:58 PM on June 19, 2017 [1 favorite]
posted by Autumnheart at 6:58 PM on June 19, 2017 [1 favorite]
a 3 hour uninterrupted coding portion [...] (note: they did not pay me.)
Yeah, this is is the point where I'd generally say either you let me do this at home, or you get the Harlan Ellison Answer. (I.e., "Fuck you--pay me.")
posted by Mr. Bad Example at 7:04 PM on June 19, 2017
Yeah, this is is the point where I'd generally say either you let me do this at home, or you get the Harlan Ellison Answer. (I.e., "Fuck you--pay me.")
posted by Mr. Bad Example at 7:04 PM on June 19, 2017
Most programmers can't provide code samples because their work product is company property.
This, 100%. Nothing I work on is something I could share with a prospective employer, and I don't do professional quality development on my own time because I have a life and a family and hobbies outside of development.
I recently interviewed for some positions, and ended up taking one at a company that I felt like did a good job of focusing on fit and collaboration, so I will say: it can be done.
It was an arduous interview, to be sure (most of a day), but involved bringing a laptop (or using a provided one) with any language or tools I wanted, and programming along with someone. This included writing code, but it was for very simple, abstract stuff (basically small games with no UI or any fancy requirements), and a lot of what they were looking for was clearly how I approached the problem, the questions I asked, etc. None of it involved stupid whiteboard tricks, it was all just logical thinking and sussing out requirements, with a little bit of debugging added in. There was also some design discussion, but that again largely focused on thought process and approach and how I would prioritize parts of functionality based on the information provided, etc.
Compared to another interview where I spent like 5 hours doing 3-on-1 whiteboard interviews implementing all sorts of shit (stop asking me about linked lists and binary trees, people), it was a major improvement.
posted by tocts at 7:04 PM on June 19, 2017 [1 favorite]
This, 100%. Nothing I work on is something I could share with a prospective employer, and I don't do professional quality development on my own time because I have a life and a family and hobbies outside of development.
I recently interviewed for some positions, and ended up taking one at a company that I felt like did a good job of focusing on fit and collaboration, so I will say: it can be done.
It was an arduous interview, to be sure (most of a day), but involved bringing a laptop (or using a provided one) with any language or tools I wanted, and programming along with someone. This included writing code, but it was for very simple, abstract stuff (basically small games with no UI or any fancy requirements), and a lot of what they were looking for was clearly how I approached the problem, the questions I asked, etc. None of it involved stupid whiteboard tricks, it was all just logical thinking and sussing out requirements, with a little bit of debugging added in. There was also some design discussion, but that again largely focused on thought process and approach and how I would prioritize parts of functionality based on the information provided, etc.
Compared to another interview where I spent like 5 hours doing 3-on-1 whiteboard interviews implementing all sorts of shit (stop asking me about linked lists and binary trees, people), it was a major improvement.
posted by tocts at 7:04 PM on June 19, 2017 [1 favorite]
How about the part where they're riding in an Uber, and the Uber app decides based on their destination that they're probably a translator, and starts asking them random translation questions while they're still in the car?
posted by miyabo at 7:20 PM on June 19, 2017
posted by miyabo at 7:20 PM on June 19, 2017
A long stint doing only proprietary work can be a real pain for all the reasons people here have mentioned. I'd love it if creatives didn't need portfolios but how else can you reliably hire creatives? You have to look at some code at some point when interviewing someone, it's either done in the interview or at some other time. The only alternative is the truly heinous practice of leaning on probationary periods to protect you from the people who interview well but can't contribute.
And btw, with a job and a healthy social life I can keep my skills up to date, often bleeding edge. Mostly because I like it and not out of some kind of strict discipline (no kids, that's a big one), but this bumps my pay up considerably and allows me to say "No." to mandatory overtime or any other crap like that. I think this has less effect in the huge company enterprise realm but that equivalent-of-a-couple-tv-shows-I-don't-watch a week pays for itself in time alone. The skills and the public work also make better jobs easier to get, which in this stupid industry where you have to job hop to get raises is important.
Of course not everyone can do this, but if you can it's an excellent investment. I've been the interviewer enough times to know that when you have more than one good candidate and one of them can actually prove they are good at the main part of their job ...
posted by Infracanophile at 8:01 PM on June 19, 2017 [1 favorite]
And btw, with a job and a healthy social life I can keep my skills up to date, often bleeding edge. Mostly because I like it and not out of some kind of strict discipline (no kids, that's a big one), but this bumps my pay up considerably and allows me to say "No." to mandatory overtime or any other crap like that. I think this has less effect in the huge company enterprise realm but that equivalent-of-a-couple-tv-shows-I-don't-watch a week pays for itself in time alone. The skills and the public work also make better jobs easier to get, which in this stupid industry where you have to job hop to get raises is important.
Of course not everyone can do this, but if you can it's an excellent investment. I've been the interviewer enough times to know that when you have more than one good candidate and one of them can actually prove they are good at the main part of their job ...
posted by Infracanophile at 8:01 PM on June 19, 2017 [1 favorite]
Keeping skills up to date doesn't require side work, in my experience. I guess that depends on what company you work for, but I am constantly doing new things. I just can't share any of it.
Realistically I personally am fine because the company names on my resume are enough to get in the door anywhere, but thats not true for most people in my position. And I've never actually been asked to show any personal code, all the interviews I've ever done have been whiteboard or "code this thing for us right now".
The expectation that developers _also_ code for fun is one of the big drivers of the lack of diversity in tech. Not only does it drive out people who don't have the time for that, but also those who just have other interests (I code 50+ hours a week for work, I *could* do more but I have more interests than just code). It's as bad as the "culture fit" nonsense (its actually part of that, I guess). I've definitely fudged that kind of question before since I know its BS anyway, and I've seen zero correlation between "writes code outside of work" and programmer quality.
posted by thefoxgod at 8:19 PM on June 19, 2017 [7 favorites]
Realistically I personally am fine because the company names on my resume are enough to get in the door anywhere, but thats not true for most people in my position. And I've never actually been asked to show any personal code, all the interviews I've ever done have been whiteboard or "code this thing for us right now".
The expectation that developers _also_ code for fun is one of the big drivers of the lack of diversity in tech. Not only does it drive out people who don't have the time for that, but also those who just have other interests (I code 50+ hours a week for work, I *could* do more but I have more interests than just code). It's as bad as the "culture fit" nonsense (its actually part of that, I guess). I've definitely fudged that kind of question before since I know its BS anyway, and I've seen zero correlation between "writes code outside of work" and programmer quality.
posted by thefoxgod at 8:19 PM on June 19, 2017 [7 favorites]
I'll give kind of a hybrid answer - I also have seen good results from at-home project + presentation interviews - they give a candidates a good opportunity to show what kind of dev they are with a more reasonable ramp-up.
That said, I think people sometimes ignore the potential value in the bullshit parts of the interview (whiteboard, pointless knowledge regurgitation, lots of time spent) - it's a signaling mechanism for the employee to show they really care enough about their job to study and prepare, and communicate, even if the connection to the real job is weak.
Programming (at least for me) is not all flowers and daisies, in fact, it's mostly bullshit that I don't want to do. That bullshit though is very important to actually ship a product, and I don't want to work with someone who isn't willing to do what's necessary.
posted by temancl at 8:20 PM on June 19, 2017
That said, I think people sometimes ignore the potential value in the bullshit parts of the interview (whiteboard, pointless knowledge regurgitation, lots of time spent) - it's a signaling mechanism for the employee to show they really care enough about their job to study and prepare, and communicate, even if the connection to the real job is weak.
Programming (at least for me) is not all flowers and daisies, in fact, it's mostly bullshit that I don't want to do. That bullshit though is very important to actually ship a product, and I don't want to work with someone who isn't willing to do what's necessary.
posted by temancl at 8:20 PM on June 19, 2017
Going through this right now... glares at Cracking the Coding Interview reproachfully. Seventeen years of experience, five industries, multiple degrees, couple dozen shipped products... please reverse this linked list.
One company (let's call them 'Oracle') gave me a take home project. After a week, they said "Oh, position's been rescinded, haha, isn't that funny, bye!" I'll be using postgres for my next project.
Seriously, though, this is an unsolved problem, and is likely to remain so. I think it gets so much visibility just because programmers really want a precise, repeatable solution when there isn't one available.
posted by cowcowgrasstree at 8:24 PM on June 19, 2017 [5 favorites]
One company (let's call them 'Oracle') gave me a take home project. After a week, they said "Oh, position's been rescinded, haha, isn't that funny, bye!" I'll be using postgres for my next project.
Seriously, though, this is an unsolved problem, and is likely to remain so. I think it gets so much visibility just because programmers really want a precise, repeatable solution when there isn't one available.
posted by cowcowgrasstree at 8:24 PM on June 19, 2017 [5 favorites]
it's a signaling mechanism for the employee to show they really care enough about their job to study and prepare, and communicate, even if the connection to the real job is weak.
There's a difference between "show me you care enough to do some tedious tasks, irrelevant to the efficacy of your code, that are important for some other department of the company" (e.g. logging time spent on specific sub-tasks, showing up at the same time each day, putting together presentations of watered-down documentation for the marketing department) vs "do some tedious, irrelevant tasks to show that you're willing to follow orders even when they not only don't matter for your code, but don't improve any other part of the company as well."
Getting potential employees to provide evidence that they can follow a set of procedures they think are stupid has value. Presumably, some other department set up those procedures for a reason that it may not be worth the time to explain in detail. However, setting up hoops to jump through that have no similarity to the tasks of the actual job, is pointless. It means candidates "proving" they have skills you don't need. You wind up with a cadre of excellent hoop-jumpers who haven't shown they can actually work on your projects.
posted by ErisLordFreedom at 9:55 PM on June 19, 2017 [1 favorite]
There's a difference between "show me you care enough to do some tedious tasks, irrelevant to the efficacy of your code, that are important for some other department of the company" (e.g. logging time spent on specific sub-tasks, showing up at the same time each day, putting together presentations of watered-down documentation for the marketing department) vs "do some tedious, irrelevant tasks to show that you're willing to follow orders even when they not only don't matter for your code, but don't improve any other part of the company as well."
Getting potential employees to provide evidence that they can follow a set of procedures they think are stupid has value. Presumably, some other department set up those procedures for a reason that it may not be worth the time to explain in detail. However, setting up hoops to jump through that have no similarity to the tasks of the actual job, is pointless. It means candidates "proving" they have skills you don't need. You wind up with a cadre of excellent hoop-jumpers who haven't shown they can actually work on your projects.
posted by ErisLordFreedom at 9:55 PM on June 19, 2017 [1 favorite]
I only had to interview and hire a programmer once so far, but I got them to open up their laptop and walk me through the code for a recent project they had built (their choice which one).
Of the shortlisted candidates:
One didn't actually have any completed/working projects.
One couldn't remember his password to get into his laptop, and when we went to Github to download some code on my computer instead, he couldn't remember his Github username or find his own repository.
One had code, but it didn't have any comments, and he couldn't remember what most of it did or how it worked.
One had nicely commented code that compiled into a working project. I hired him, he built me half a project, and then stopped answering emails and completely disappeared.
posted by lollusc at 10:27 PM on June 19, 2017 [4 favorites]
Of the shortlisted candidates:
One didn't actually have any completed/working projects.
One couldn't remember his password to get into his laptop, and when we went to Github to download some code on my computer instead, he couldn't remember his Github username or find his own repository.
One had code, but it didn't have any comments, and he couldn't remember what most of it did or how it worked.
One had nicely commented code that compiled into a working project. I hired him, he built me half a project, and then stopped answering emails and completely disappeared.
posted by lollusc at 10:27 PM on June 19, 2017 [4 favorites]
"do some tedious, irrelevant tasks to show that you're willing to follow orders even when they not only don't matter for your code, but don't improve any other part of the company as well."
I was thinking more about learning new, rather arbitrary and shitty technical tasks as they arise on the job, like doing a 64-bit code base conversion. I hope I'm not screening them for what you're talking about, I'd fail that one for sure...
>50% of them fail to explain how much memory allocating a structure can take, and cannot reverse a linked list. That comes *after* they pass the phone screen, where they have to explain how a thread is different from a process, with another >50% fail.
Sorry, I'm just whining. Dev hiring is hard, and there's got to be a better way.
posted by temancl at 10:38 PM on June 19, 2017
I was thinking more about learning new, rather arbitrary and shitty technical tasks as they arise on the job, like doing a 64-bit code base conversion. I hope I'm not screening them for what you're talking about, I'd fail that one for sure...
>50% of them fail to explain how much memory allocating a structure can take, and cannot reverse a linked list. That comes *after* they pass the phone screen, where they have to explain how a thread is different from a process, with another >50% fail.
Sorry, I'm just whining. Dev hiring is hard, and there's got to be a better way.
posted by temancl at 10:38 PM on June 19, 2017
it's a signaling mechanism for the employee to show they really care enough about their job to study and prepare, and communicate, even if the connection to the real job is weak.
I've heard this same rationale used to justify drug testing for employment.
posted by invitapriore at 10:48 PM on June 19, 2017
I've heard this same rationale used to justify drug testing for employment.
posted by invitapriore at 10:48 PM on June 19, 2017
I've heard this same rationale used to justify drug testing for employment.
My argument needs work then - I've touched the wrong nerves and that's not at all what I wanted to convey.
On a less serious note, if a piss test could detect the ability to understand pointers and recursion, we'd really be on to something.
posted by temancl at 11:08 PM on June 19, 2017
My argument needs work then - I've touched the wrong nerves and that's not at all what I wanted to convey.
On a less serious note, if a piss test could detect the ability to understand pointers and recursion, we'd really be on to something.
posted by temancl at 11:08 PM on June 19, 2017
Coming from the design world and having interviewed many young and experienced designers my approach is slightly different. If you're asked to come in for an interview it means I've seen your portfolio and want to hire you and now need to determine if I'm willing to work with you. That takes about five minutes. Done!
This has never let me down and I've hired probably 100 designers at various companies over the years. I don't care where you went to school, what software you know or who you're friends with. Just give me a good book and non-crazy/annoying.
posted by misterpatrick at 1:20 AM on June 20, 2017
This has never let me down and I've hired probably 100 designers at various companies over the years. I don't care where you went to school, what software you know or who you're friends with. Just give me a good book and non-crazy/annoying.
posted by misterpatrick at 1:20 AM on June 20, 2017
> "... they had a 3 hour uninterrupted coding portion ... (note: they did not pay me.) ... about a month later, I found the code I had written during the interview in their codebase, in production."
> "In fact, even though I ultimately declined that position, my understanding is my code went into production because it was literally a task the project team was then working on."
> "One company (let's call them 'Oracle') gave me a take home project."
If I were an evil person, I would have a new business model now.
posted by kyrademon at 3:17 AM on June 20, 2017
> "In fact, even though I ultimately declined that position, my understanding is my code went into production because it was literally a task the project team was then working on."
> "One company (let's call them 'Oracle') gave me a take home project."
If I were an evil person, I would have a new business model now.
posted by kyrademon at 3:17 AM on June 20, 2017
All the comments in this thread about how coding exercises should be based on real world problems where an interviewee's solution should be launched into production makes me wonder: how does that work when you're interviewing a dozen candidates and trying to grade them on a consistent basis? Are you splitting your repos off into distinct instances for each candidate? Does a candidate who's interviewing next week get the same bug that someone else had to tackle last week? How do you decide on any given week what's a fair exercise for a technical eval?
I ask because we had considered this path for our own process and we found it relatively impractical in a context of continuous code delivery and constant hiring. Having a problem of the week to solve adds inconsistency in the long term because that adds a somewhat arbitrary shift in your testing criteria from week to week or month to month.
Here's what we do:
* 30-45 min recruiter screen following resume review to gauge viability (are you looking for a job that is actually like this job? Can we answer any obvious questions you may have? Etc.)
* 45 min hiring manager behavioral prelim (basic skills and background assessment. Both of us hype ourselves up to the other. Determine if candidate has any red flags that prohibit them from succeeding in the later stages)
* 2 hr tech eval (we give you a code repo for a microservice based on a existing service in our ecosystem that interacts with a stub API, a readme of tasks based on seniority of position, and a 2 hour time box. You can choose to either pair on this with the two interviewing developers for 2 hours or you can opt for a 24 hour take home and honor system a 2 hr time box then do a 1 hr panel interview with the two devs as they review your solution)
* 1 hr team fit with product manager and another senior dev or dev mgr (basic behavioral assessment and opportunity for candidate to talk to non devs in the company)
* Optional open-ended followup with hiring manager if questions need to be answered before proceeding to offer.
We're distributed so all of this happens over Google Hangout. All of our coding exercises involve working with GitHub as we use it everyday. We are explicit about saying that live and take home options are graded on the same basis and the take home version is closer to our everyday process as we don't do a lot of pair programming but we review pull requests like it's the second half of our jobs, which it is.
We came to this process iteratively over many problems/bugs. We used to do exclusive pair programming but saw a lot of people flame out spectacularly on the live exercise and thought that was suboptimal. We revamped our exercise to let it be take home and opted for 24 hour lead time (window at candidate's choosing) so we could be fair to people with busy schedules. We used to ask problem of the week questions but then moved to one common problem to allow different interviewers to sub in for each other and get used to evaluating candidates on the same criteria.
We stopped seriously considering public repos because it's a biasing vector similar to what many others have pointed out already. Sometimes it's a nice bonus, but any coding strengths that the candidate may have should come out in the technical eval. When evaluating mobile devs I sometimes review the portfolio apps that they have in their platform's store, but honestly, we aren't at a great spot for hiring boot camp grads who've only ever done solo projects, which is what 95% of store apps are.
This process generally works for us in bringing in good people and getting them excited to work with us at each step of the process. It's not a silver bullet for solving bad interviews, but I do offer it as an example for others looking for something to model or demand.
posted by bl1nk at 4:52 AM on June 20, 2017
I ask because we had considered this path for our own process and we found it relatively impractical in a context of continuous code delivery and constant hiring. Having a problem of the week to solve adds inconsistency in the long term because that adds a somewhat arbitrary shift in your testing criteria from week to week or month to month.
Here's what we do:
* 30-45 min recruiter screen following resume review to gauge viability (are you looking for a job that is actually like this job? Can we answer any obvious questions you may have? Etc.)
* 45 min hiring manager behavioral prelim (basic skills and background assessment. Both of us hype ourselves up to the other. Determine if candidate has any red flags that prohibit them from succeeding in the later stages)
* 2 hr tech eval (we give you a code repo for a microservice based on a existing service in our ecosystem that interacts with a stub API, a readme of tasks based on seniority of position, and a 2 hour time box. You can choose to either pair on this with the two interviewing developers for 2 hours or you can opt for a 24 hour take home and honor system a 2 hr time box then do a 1 hr panel interview with the two devs as they review your solution)
* 1 hr team fit with product manager and another senior dev or dev mgr (basic behavioral assessment and opportunity for candidate to talk to non devs in the company)
* Optional open-ended followup with hiring manager if questions need to be answered before proceeding to offer.
We're distributed so all of this happens over Google Hangout. All of our coding exercises involve working with GitHub as we use it everyday. We are explicit about saying that live and take home options are graded on the same basis and the take home version is closer to our everyday process as we don't do a lot of pair programming but we review pull requests like it's the second half of our jobs, which it is.
We came to this process iteratively over many problems/bugs. We used to do exclusive pair programming but saw a lot of people flame out spectacularly on the live exercise and thought that was suboptimal. We revamped our exercise to let it be take home and opted for 24 hour lead time (window at candidate's choosing) so we could be fair to people with busy schedules. We used to ask problem of the week questions but then moved to one common problem to allow different interviewers to sub in for each other and get used to evaluating candidates on the same criteria.
We stopped seriously considering public repos because it's a biasing vector similar to what many others have pointed out already. Sometimes it's a nice bonus, but any coding strengths that the candidate may have should come out in the technical eval. When evaluating mobile devs I sometimes review the portfolio apps that they have in their platform's store, but honestly, we aren't at a great spot for hiring boot camp grads who've only ever done solo projects, which is what 95% of store apps are.
This process generally works for us in bringing in good people and getting them excited to work with us at each step of the process. It's not a silver bullet for solving bad interviews, but I do offer it as an example for others looking for something to model or demand.
posted by bl1nk at 4:52 AM on June 20, 2017
In the dim, distant past Mrs. Wombat and I arrived on the shores of a new land with a simple instruction: "Hire as many good programmers as you can in the next two months, or we're all screwed." Our beloved employer had sold some software that didn't exist to a demanding customer in a country where we had no team.
We rocked up and started interviewing people. Mrs. Wombat and I started with about seven or eight interview questions designed to separate the wheat from the chaff. After ten interviews we discovered one question that acted as a binary test. Either a candidate would answer it quickly, confidently, and accurately or they would flounder, bluster and fail.
Candidates who could answer it breezed through the rest of the exam without any trouble, and all went on to be awesome members of the team.
For reasons related to start-up behaviour, our management hired several people who couldn't answer the question. Every one was a disaster.
It was a simple - almost trivial - question. I am still astonished that it was such an accurate scalpel between the capable and the incompetent. Good people had no problem, posers and idiots failed.
I still use variants of it in the rare times I'm involved in hiring programmers. It still works.
Some people can code. Hire all of them, then fire the bigots later.
Most people can't code. A CS degree is no yardstick. Identify them, and don't hire them.
And, if you can't hire them everyone who passes, hire the women. The single best indicator for project success is the number of women on the team.
posted by Combat Wombat at 4:54 AM on June 20, 2017 [4 favorites]
We rocked up and started interviewing people. Mrs. Wombat and I started with about seven or eight interview questions designed to separate the wheat from the chaff. After ten interviews we discovered one question that acted as a binary test. Either a candidate would answer it quickly, confidently, and accurately or they would flounder, bluster and fail.
Candidates who could answer it breezed through the rest of the exam without any trouble, and all went on to be awesome members of the team.
For reasons related to start-up behaviour, our management hired several people who couldn't answer the question. Every one was a disaster.
It was a simple - almost trivial - question. I am still astonished that it was such an accurate scalpel between the capable and the incompetent. Good people had no problem, posers and idiots failed.
I still use variants of it in the rare times I'm involved in hiring programmers. It still works.
Some people can code. Hire all of them, then fire the bigots later.
Most people can't code. A CS degree is no yardstick. Identify them, and don't hire them.
And, if you can't hire them everyone who passes, hire the women. The single best indicator for project success is the number of women on the team.
posted by Combat Wombat at 4:54 AM on June 20, 2017 [4 favorites]
Once had a tech job interview with two interviewers, meaning both interviewers were in the same room at the same time asking the same questions. Never heard back. Later asked somebody I knew there what happened. "One interviewer thought you were too passive and withdrawn to work for our company. The other interviewer thought you were too arrogant and overbearing to work for our company." Seems like that ought to have averaged out.
posted by lagomorphius at 5:10 AM on June 20, 2017 [1 favorite]
posted by lagomorphius at 5:10 AM on June 20, 2017 [1 favorite]
this thread is making me realize how much I despise everything about working, except for getting paid
posted by thelonius at 5:33 AM on June 20, 2017 [12 favorites]
posted by thelonius at 5:33 AM on June 20, 2017 [12 favorites]
It was a simple - almost trivial - question. I am still astonished that it was such an accurate scalpel between the capable and the incompetent. Good people had no problem, posers and idiots failed.
C'mon, you can't say that and then not say what the question was.
posted by kersplunk at 5:57 AM on June 20, 2017 [19 favorites]
C'mon, you can't say that and then not say what the question was.
posted by kersplunk at 5:57 AM on June 20, 2017 [19 favorites]
Being expected to prep for this sort of interview is every bit as much a deliberate act of subjugation as being expected to buy and wear an interview suit (an outfit you will never otherwise use on the job) for such occasions; it signals that the Patron requires the applicant to humble themselves before the power and majesty of their future employer.
Relevance to actual job performance: zip.
posted by cstross at 6:29 AM on June 20, 2017 [7 favorites]
Relevance to actual job performance: zip.
posted by cstross at 6:29 AM on June 20, 2017 [7 favorites]
C'mon, you can't say that and then not say what the question was.We were looking for people to configure and extend an application that managed a database that described a complex network. The question was simple:
Here's a database. In our petting zoo, we have some people who take care of some animals. Person Table |id|name | | 0|Alice | | 1|Tegan | | 2|Emma | PersonPet Table |Person|Pet| | 0| 0| | 1| 1| | 1| 2| | 2| 0| Pet Table |id|Species |Name | | 0|Echidna |Rupert | | 1|Wombat |Emily | | 2|Emu |Eliana | Write an SQL query that shows which person cares for which animal. Include the species of the animals.That was it. The whole thing. Either they could write the query correctly in one go, or they couldn't. It wasn't a subtle thing. It was glorious success or abject failure.
These were all people who professed knowledge in SQL and relational databases. The ones who could do it were also always capable of hacking in Java, Python and the simple webby stuff we wanted. Those who couldn't do it were also unable to actually write real code.
I truly believe that coding can't really be taught. Either you have the curious and playful mind that loves it, or you simply don't get it. And that trivial question seemed to separate the two camps like a scalpel.
posted by Combat Wombat at 6:40 AM on June 20, 2017 [13 favorites]
Bono, The Edge, Adam and Larry have to get across a bridge in order to play a concert. Bono has a fox, a rabbit and a lettuce. Adam has the torch. Larry has a pair of tens. The Edge is tripping balls. Only one of them can fit in the boat. Where are my car keys?
posted by flabdablet at 7:51 AM on June 20, 2017 [6 favorites]
posted by flabdablet at 7:51 AM on June 20, 2017 [6 favorites]
These were all people who professed knowledge in SQL and relational databases.
Once I asked applicants to discuss 1) different kinds of SQL queries and 2) the parts (I switched to "parts" after "clauses" seemed to confuse a couple of people) of a SELECT query. I didn't think that was too taxing, but I just got blank stare after blank stare. Was this a bad question? For 1), I would have been delighted if they said there are queries that delete rows, update rows, or select rows, or that there are queries which select data, queries that alter tables by, oh, adding or deleting columns, or queries that create tables. I don't even care if they didn't know the right jargon for these things; I just wanted to find someone who had actually worked a little bit with SQL. For 2), I was figuring it was a softball question.....there's a SELECT clause, a FROM clause, a WHERE clause, an ORDER BY clause....there's a GROUP By and HAVING clause in aggregate queries.......that is not so esoteric, right? I wasn't asking them to discuss some weird vendor-specific windowing function or something like that.
posted by thelonius at 8:43 AM on June 20, 2017 [1 favorite]
Once I asked applicants to discuss 1) different kinds of SQL queries and 2) the parts (I switched to "parts" after "clauses" seemed to confuse a couple of people) of a SELECT query. I didn't think that was too taxing, but I just got blank stare after blank stare. Was this a bad question? For 1), I would have been delighted if they said there are queries that delete rows, update rows, or select rows, or that there are queries which select data, queries that alter tables by, oh, adding or deleting columns, or queries that create tables. I don't even care if they didn't know the right jargon for these things; I just wanted to find someone who had actually worked a little bit with SQL. For 2), I was figuring it was a softball question.....there's a SELECT clause, a FROM clause, a WHERE clause, an ORDER BY clause....there's a GROUP By and HAVING clause in aggregate queries.......that is not so esoteric, right? I wasn't asking them to discuss some weird vendor-specific windowing function or something like that.
posted by thelonius at 8:43 AM on June 20, 2017 [1 favorite]
Like Combat Wombat, I have a single question litmus test (which I've talked about previously, here). I'm similarly annoying in my response there in that I also don't mention the specific technical issue/problem that I characterize as "any software professional should be at least passingly familiar."
That would be semaphores. Mine is at the database level (like in read/write locks), but we could talk about that at application code level (or very-close-to-the-metal system level), as well. Except I present it as a generalized performance problem - it's the candidates' task to pull what they need from me to figure out where the bottleneck is. Bad ones never get to the proper diagnosis. Good ones get there eventually. Great ones get there quickly, then give me multiple ways to address the problem, and pick different ones as I change what the customer can/can't do to help or accept. I don't ask for any code or syntax, and there's a pretty good correlation between great candidates and skipping the whiteboard altogether.
And yeah, this isn't a theoretical thing - we see multi-threaded/multi-process conflicts all the time. The one I'm dealing with right now isn't even in our stuff, but deep in the guts of AWS hypervisors. I don't need a Xen expert for this, but I do need someone who knows both how to see and what to do about stuff like this in levels of the stack they might not own or be otherwise familiar.
posted by NoRelationToLea at 8:52 AM on June 20, 2017 [2 favorites]
That would be semaphores. Mine is at the database level (like in read/write locks), but we could talk about that at application code level (or very-close-to-the-metal system level), as well. Except I present it as a generalized performance problem - it's the candidates' task to pull what they need from me to figure out where the bottleneck is. Bad ones never get to the proper diagnosis. Good ones get there eventually. Great ones get there quickly, then give me multiple ways to address the problem, and pick different ones as I change what the customer can/can't do to help or accept. I don't ask for any code or syntax, and there's a pretty good correlation between great candidates and skipping the whiteboard altogether.
And yeah, this isn't a theoretical thing - we see multi-threaded/multi-process conflicts all the time. The one I'm dealing with right now isn't even in our stuff, but deep in the guts of AWS hypervisors. I don't need a Xen expert for this, but I do need someone who knows both how to see and what to do about stuff like this in levels of the stack they might not own or be otherwise familiar.
posted by NoRelationToLea at 8:52 AM on June 20, 2017 [2 favorites]
A country road has a one-lane bridge over a river. Specify the operation of a control for regulating the passage of cars over the bridge. The control needs to have the following properties:
1. At most one car is to be permitted to occupy the bridge at any time.
2. If there is no contention for bridge occupancy, cars approaching the bridge must not be delayed.
3. If there is contention for bridge occupancy, any car that will be made to wait for access to the bridge must be given enough warning to be able to stop safely before reaching it.
4. Under no circumstances may the number of cars waiting on one side of the bridge exceed the number waiting on the other by more than 1.
posted by flabdablet at 10:12 AM on June 20, 2017
1. At most one car is to be permitted to occupy the bridge at any time.
2. If there is no contention for bridge occupancy, cars approaching the bridge must not be delayed.
3. If there is contention for bridge occupancy, any car that will be made to wait for access to the bridge must be given enough warning to be able to stop safely before reaching it.
4. Under no circumstances may the number of cars waiting on one side of the bridge exceed the number waiting on the other by more than 1.
posted by flabdablet at 10:12 AM on June 20, 2017
Mine is at the database level (like in read/write locks), but we could talk about that at application code level (or very-close-to-the-metal system level), as well. Except I present it as a generalized performance problem - it's the candidates' task to pull what they need from me to figure out where the bottleneck is.
This sounds very similar to the worst interview I've ever had. YMMV, but you're probably making a lot of people sad for no reason.
posted by TypographicalError at 10:21 AM on June 20, 2017
This sounds very similar to the worst interview I've ever had. YMMV, but you're probably making a lot of people sad for no reason.
posted by TypographicalError at 10:21 AM on June 20, 2017
flabdablet: "4. Under no circumstances may the number of cars waiting on one side of the bridge exceed the number waiting on the other by more than 1."
Is this a trick question? Because unless you impose some further criteria (e.g.: on the arrival rate of cars), this is not a circumstance that can be avoided. For example, suppose that cars only arrive on one side of the bridge, they arrive every five minutes, but it takes two hours to cross the bridge.
posted by mhum at 10:28 AM on June 20, 2017 [4 favorites]
Is this a trick question? Because unless you impose some further criteria (e.g.: on the arrival rate of cars), this is not a circumstance that can be avoided. For example, suppose that cars only arrive on one side of the bridge, they arrive every five minutes, but it takes two hours to cross the bridge.
posted by mhum at 10:28 AM on June 20, 2017 [4 favorites]
4. Under no circumstances may the number of cars waiting on one side of the bridge exceed the number waiting on the other by more than 1.
Easy! Don't allow cars to wait on one of the sides - just shove them into the river, if they try.
requirements class is hard!
posted by thelonius at 10:49 AM on June 20, 2017 [6 favorites]
Easy! Don't allow cars to wait on one of the sides - just shove them into the river, if they try.
requirements class is hard!
posted by thelonius at 10:49 AM on June 20, 2017 [6 favorites]
unless you impose some further criteria (e.g.: on the arrival rate of cars), this is not a circumstance that can be avoided
That right there? That's a pass.
didn't find my car keys tho
posted by flabdablet at 11:45 AM on June 20, 2017 [2 favorites]
That right there? That's a pass.
didn't find my car keys tho
posted by flabdablet at 11:45 AM on June 20, 2017 [2 favorites]
OK, after eight years, it looks like I can still write a SQL query. I had to refresh my memory on creating and inserting in order to test it, though.
(Unless the trick is in how the output is described. I get four lines giving person-pet relationships, e.g. Alice, Rupert, Echidna.)
posted by zompist at 1:24 PM on June 20, 2017 [1 favorite]
(Unless the trick is in how the output is described. I get four lines giving person-pet relationships, e.g. Alice, Rupert, Echidna.)
posted by zompist at 1:24 PM on June 20, 2017 [1 favorite]
"OK Google. Which person cares for which animal? Include the species."
posted by Dr. Curare at 2:28 PM on June 20, 2017 [1 favorite]
posted by Dr. Curare at 2:28 PM on June 20, 2017 [1 favorite]
What other domain-specific FizzBuzz questions (the SQL question above strikes me as an instance of this) do people use? In the past I've asked people who claim experience with concurrent programming and primitives to implement a basic RW lock with semaphores, although I don't do really quiz-style interviews like that now.
posted by invitapriore at 2:37 PM on June 20, 2017
posted by invitapriore at 2:37 PM on June 20, 2017
Huh, maybe I should reconsider the programming career, because I found that SQL question really easy.
posted by sauril at 2:41 PM on June 20, 2017 [2 favorites]
posted by sauril at 2:41 PM on June 20, 2017 [2 favorites]
What other domain-specific FizzBuzz questions do people use?
Reverse a string.
a deliberate act of subjugation
It's just a string, sdrawkcab! I'm really not looking for rocket surgeons.
posted by Leon at 6:08 PM on June 20, 2017
Reverse a string.
a deliberate act of subjugation
It's just a string, sdrawkcab! I'm really not looking for rocket surgeons.
posted by Leon at 6:08 PM on June 20, 2017
Reverse a string.
How many libraries can I import, sir?
posted by Kyol at 6:44 PM on June 20, 2017 [3 favorites]
How many libraries can I import, sir?
posted by Kyol at 6:44 PM on June 20, 2017 [3 favorites]
Huh, maybe I should reconsider the programming career, because I found that SQL question really easy.
You should. More than 75% of prospective DBAs here couldn't answer that kind of question (or write any other SQL at all). These are people who claim to be 'senior DBA' and the like.
posted by dmd at 6:09 AM on June 21, 2017 [1 favorite]
You should. More than 75% of prospective DBAs here couldn't answer that kind of question (or write any other SQL at all). These are people who claim to be 'senior DBA' and the like.
posted by dmd at 6:09 AM on June 21, 2017 [1 favorite]
These are people who claim to be 'senior DBA' and the like.
I thought that meant you know all about indexing and optimizing and physical partitioning and backup/restore and all kinds of things more deep than just selecting some rows with a simple join!
posted by thelonius at 6:15 AM on June 21, 2017
I thought that meant you know all about indexing and optimizing and physical partitioning and backup/restore and all kinds of things more deep than just selecting some rows with a simple join!
posted by thelonius at 6:15 AM on June 21, 2017
Which is why you start with the "have you literally any knowledge whatsoever" question. It saves a lot of time.
posted by dmd at 6:32 AM on June 21, 2017 [3 favorites]
posted by dmd at 6:32 AM on June 21, 2017 [3 favorites]
I know one guy who was a DBA for 20 years at a large health care company and was prohibited from ever running queries for patient privacy reasons. He kept the database running but was not allowed to have any knowledge of the data in it. Jobs are weird.
posted by miyabo at 9:30 AM on June 21, 2017 [1 favorite]
posted by miyabo at 9:30 AM on June 21, 2017 [1 favorite]
What other domain-specific FizzBuzz questions do people use?
When I lived in the print design world we would see amazing portfolios that turned to be all digital work designed to be seen on a computer screen. We were a print shop, and we did not have the resources to have a full pre-press department to turn digital dreams into printed objects. Our fizz-buzz was to show them identical text on identical paper, one black and one really dark black. We would ask them to figure out the difference. Candidates with real world experience would say "rich black" almost instantly, good ones would know the different rich black formulations for coated and uncoated paper.
When I was in this disreputable job, 'Alice' would stress the importance of discretion and anonymity then describe 'Bob' and direct them to go him and give him a note. The fizz buzz was that there was no Bob, but plenty of helpful strangers offering to help. The only right answer was to go report back to Alice without disclosing the names or descriptions of Alice or Bob, or the existence of the note.
posted by Dr. Curare at 3:18 PM on June 21, 2017
When I lived in the print design world we would see amazing portfolios that turned to be all digital work designed to be seen on a computer screen. We were a print shop, and we did not have the resources to have a full pre-press department to turn digital dreams into printed objects. Our fizz-buzz was to show them identical text on identical paper, one black and one really dark black. We would ask them to figure out the difference. Candidates with real world experience would say "rich black" almost instantly, good ones would know the different rich black formulations for coated and uncoated paper.
When I was in this disreputable job, 'Alice' would stress the importance of discretion and anonymity then describe 'Bob' and direct them to go him and give him a note. The fizz buzz was that there was no Bob, but plenty of helpful strangers offering to help. The only right answer was to go report back to Alice without disclosing the names or descriptions of Alice or Bob, or the existence of the note.
posted by Dr. Curare at 3:18 PM on June 21, 2017
« Older Well, I was killed in 1963 one Sunday morning in... | "The smell is potent for a quarter mile, and lasts... Newer »
This thread has been archived and is closed to new comments
That is just so wonderfully perfect. Pure gold.
posted by Infracanophile at 11:29 AM on June 19, 2017 [65 favorites]