No hashtag. Yet.
March 1, 2017 2:54 PM Subscribe

I look code up on the internet all the time. Some experienced & well-respected programmers find whiteboard algorithm hazing a grueling and not necessarily useful interview process.
posted by theora55 (157 comments total) 44 users marked this as a favorite

And now it's weaponised.
posted by Artw at 3:00 PM on March 1, 2017 [18 favorites]

Was this about job interviews, or that bloke who got locked up by US immigration and quizzed about binary search trees before they'd believe he was a programmer?
posted by pompomtom at 3:01 PM on March 1, 2017 [2 favorites]

Yeah, that bloke...
posted by pompomtom at 3:01 PM on March 1, 2017

They basically looked up how to do a shitty interview, and combined it with a border grilling - two great flavour combined!
posted by Artw at 3:03 PM on March 1, 2017 [14 favorites]

According to the victim (on twitter) they would only accept answers that matched what they could look up on Wikipedia.
posted by pompomtom at 3:08 PM on March 1, 2017 [11 favorites]

At my company, we're hiring TSA agents to screen & interview our software development candidates.
posted by parki at 3:09 PM on March 1, 2017 [33 favorites]

I'm doing pretty rigorous coding-on-a-whiteboard studying for a job search, and it's tough to stay motivated, because that crap is something I need to have in my head solidly for just a couple weeks and then I can forget and go back to googling shit just like real engineers do.

I talked to a company this morning that gives candidates an at-home assignment, then elaborates on the at-home assignment in an onsite interview, and I was like "you just shot up my list." That's much closer to how I actually work, and will be a much better way for me to demonstrate that worth hiring.

(If you have a cool software engineering job vacancy in the downtown seattle area, memail me)
posted by Sauce Trough at 3:09 PM on March 1, 2017 [17 favorites]

Why I Say No To Google Recruiters
posted by the man of twists and turns at 3:10 PM on March 1, 2017 [9 favorites]

Assessing overall competency through the interview process is difficult, obviously. When I used to run interviews, I used the whiteboard method, but it was always the same question - write a method (in whatever language you want, or even pseudocode) - to determine if, given two character arrays, one array is a subset of the other. It not only helped demonstrate understanding of basic coding principles but also gave us insight into the problem-solving process and capabilities of the candidate.

Did we get the absolute right candidate 100% of the time? I doubt it. There's no way to know. But we had to test them somehow, because bullshit artists can bullshit really, really well, and firing people is expensive. You can't really bullshit your way through a technical task.

I've also been on the other side of this. I'd been writing software professionally for a couple of years and got an interview at Travelocity. Since I am not from a CS background (I studied music composition) I was not well-versed in CS terminology, despite producing (allegedly) quality code. So the interviewer asked me to define polymorphism and I was all "well..." and that was that. I offered to show him some of my code or write something on the spot and he declined.

After that I boned up on my vocabulary.
posted by grumpybear69 at 3:12 PM on March 1, 2017 [6 favorites]

The best thing I've seen in tech interviews is "talk me through something you've made". Tests useful skills (discussing your code) and abilities (what decisions you made in a non-interview situation).
posted by Wrinkled Stumpskin at 3:12 PM on March 1, 2017 [7 favorites]

The real skill is in knowing what question to ask, working out which Google search terms get you close, then knowing how to narrow 15 good answers down to the best answer. Knowing how to ask the question is 95% of the job. Knowing every answer is just bullshit, really. I've been coding with PHP (among other things) on and off for a decade, and I still pick the wrong function from explode and implode every single damn time.

The last job interview I went to, I pulled out of the process on the third interview when they wanted me to do a coding exercise in ColdFusion without any internet access or reference materials.
posted by pipeski at 3:13 PM on March 1, 2017 [13 favorites]

I'm so screwed if I ever have to do this. It's been 20 years since I took CS classes. THey want quicksort? I'm gonna have to write "java.Collections.sort" on the board and go home.
posted by thelonius at 3:19 PM on March 1, 2017 [14 favorites]

Nobody needs to remember how to implement merge sort off the top of their head, and expecting someone to regurgitate that kind of thing on command is a really bad test for whether someone's a good programmer.

On the other hand, whether they can meaningfully engage in a two-way conversation about how you might implement a sorting algorithm is a much better question, and much closer to what programmers actually do day-to-day.

This probably works better if even the interviewer doesn't know the right answer, because otherwise they might be biased in favor of people who have been exposed to the textbook solution ahead of time. Unless you're looking for an algorithms specialist, this hardly matters.

Expecting people to remember library method names ("I need to look up how to get the length of a python string") or language syntax in an interview is totally unredeemable. Anybody that would turn down a candidate based on something like that is probably somebody you wouldn't want to work for in the first place.
posted by a mirror and an encyclopedia at 3:20 PM on March 1, 2017 [11 favorites]

this is basically why a UBI will never happen, because there's too many petty little would-be tyrants out there get their jollies out of being able to play the junior edition of lord and serf

somebody prove me wrong
posted by entropicamericana at 3:22 PM on March 1, 2017 [17 favorites]

I can see being asked to whiteboard code for positions related to Search or NLP but for standard front end back end web development? Nah
posted by vuron at 3:23 PM on March 1, 2017

I guess I should temper my last comment by pointing out that interview questions without a single clear-cut answer have a pretty big disadvantage, too: They allow the personal biases of the interviewer much greater scope to affect the outcome.

I'm not really sure how to fix that.
posted by a mirror and an encyclopedia at 3:24 PM on March 1, 2017 [3 favorites]

Nowadays when I go to a technical interview I bring my laptop with a nice empty idea project all waiting to go, and with all my favorite testing libs maven'd in.

They ask a coding question, I grab my laptop and bang out an answer. Don't even give them the chance to point me at the whiteboard. Then I ask them where to mail the zipfiled solution.

It works with less assertive interviewers. I've gotten away with it a couple times.
posted by Sauce Trough at 3:25 PM on March 1, 2017 [12 favorites]

standard front end back end web development
It would be a lot more useful, I think, to give someone a broken site in a dev environment, and ask them to talk through finding out what is wrong......something like that.

How do we feel about FizzBuzz and the like? I think that sounds pretty reasonable, personally......if someone purports to know how to program but struggles with looping and simple conditional structures, that's probably enough to say "no thanks".
posted by thelonius at 3:27 PM on March 1, 2017 [5 favorites]

basically everything in tech is broken, everyone knows it, and then just do the exact same thing.

What are you talking about? My whole job is coordinating dozens of people so that people can say the name of a radio station, light up a few hundred datacenter servers and then listen to a radio station via online streaming.

Sure, you could do it with a whisker and a crystal, but whatever. Tech rulez.
posted by GuyZero at 3:32 PM on March 1, 2017 [5 favorites]

...so that people can say...

Almost every thing I think of to ask Siri (if that is what you mean) to do on my phone fails. "Siri, mark all the voicemails as read". "You have three voicemails...." "Yes; mark them as read." "You have three voicemails...."
posted by thelonius at 3:37 PM on March 1, 2017 [3 favorites]

It's not just interviews, basically everything in tech is broken, everyone knows it, and then just do the exact same thing. Same thing with source control, deploys, releases, interviews, whatever.

Them something goes wrong, so there is a team/division/meeting everyone has an opinion, nothing happens, some manager makes a wiki checklist and the cycle repeats. For a group of people who are supposed to solve problems practically, programmers sure get stuck in a rut of following broken instructions unquestioningly, just like the tools they use.

Heisenberg's uncertainty principle holds for all discrete systems (try taking a Fourier transform of a square wave sometime...), and in discrete software systems it takes the form of the tradeoff between correctness and time. A Monte Carlo algorithm (like most machine learning algorithms are) says, "fuck certainty in correctness I want a reasonable time", and the conjugate, a Las Vegas algorithm, says "fuck certainty in time, I want correctness." Most algorithms in actual production are supposed to be deterministic, but they have a nondeterminism in them from the amount of time, so they are Las Vegas algorithms.

But the two are a tradeoff: you can trade off time for correctness and get pretty good results from a mixed solution.

You, too, can have a solution as luminously correct and non-buggy as NetHack. You just have to budget the 30 years it takes to get there.
posted by hleehowon at 3:40 PM on March 1, 2017 [8 favorites]

I talked to a company this morning that gives candidates an at-home assignment, then elaborates on the at-home assignment in an onsite interview, and I was like "you just shot up my list."

This! Why can't there be more this? Take-home projects, where you comment your code, and then analyze it with your interviewers, describing your process; THAT is the way to actually see what you do when asked to produce code for somebody else.
posted by destructive cactus at 3:41 PM on March 1, 2017 [11 favorites]

At this point "whiteboard interviews" select for people who have prepared for whiteboard interviews.

There is a need at the entry-level to screen people for basic coding skills. Similarly if you claim to have expertise in "technology x" or "programming language y" you should be prepared to answer some basic questions about it. But some companies are taking things to an absurd degree, just to assure themselves they're selecting "the best of the best". Maybe, but I think think they're driving other very talented people away.
posted by dweingart at 3:44 PM on March 1, 2017 [6 favorites]

I constantly google basic syntax. I've stopped even trying to remember anything half clever to type, and have come to depend on the constant checking as a touchstone of sane coding. I find Stack Overflow answers that catch me heading down the wrong conceptual path, or make me rethink broader issues. Along the way I get more practice reading other's code.

----

We've developed what we think is a very good technical question for our developers: we take a massive git fuckup from one of our clients [*], and walk them through how it happened, asking/discussing git internals along the way, seeing if they can see what's coming, reason about why it happened, how to get out of it, and how to prevent it in the future. Along the way it's a technical discussion of a tool that everyone kind of knows, but no one studies up on, so you get that exploratory talk that combines algorithms, policies and procedures.

That said, my favourite coworker is still the young Iranian woman (who we can't actually send onsite to the client any more) who got angry in, like, 2 minutes. "Why would he do that!? He shouldn't do that!" She saw the trainwreck coming a mile away. She's now our department anger translator.

* One of the client developers, on a long lived feature branch, reverted a merge from the develop branch, and didn't merge his feature branch for another month. Memail me a :facepalm: if your stomach just sagged.
posted by fatbird at 3:51 PM on March 1, 2017 [29 favorites]

* One of the client developers, on a long lived feature branch, reverted a merge from the develop branch, and didn't merge his feature branch for another month. Memail me a :facepalm: if your stomach just sagged.

fuck shit fuck shit fuck fuck fuck fuck fuck fuck fuckfuckfuckfuckfuckfuckfuckfuckfuckshit
posted by hleehowon at 3:53 PM on March 1, 2017 [6 favorites]

Take-home projects, where you comment your code, and then analyze it with your interviewers, describing your process; THAT is the way to actually see what you do when asked to produce code for somebody else.

FWIW, this is IME completely standard in Bay Area tech companies at this point. It does have drawbacks, though, primarily that it's biased against candidates who can't carve the time out of their off-hours to do the project.
posted by asterix at 3:59 PM on March 1, 2017 [13 favorites]

asterix: "FWIW, this is IME completely standard in Bay Area tech companies at this point. It does have drawbacks, though, primarily that it's biased against candidates who can't carve the time out of their off-hours to do the project."

As a counterpoint, in my most recent job search in the bay area, I was offered zero take-home interviews. It's not "standard" perhaps, but "commonplace".
posted by TypographicalError at 4:01 PM on March 1, 2017 [2 favorites]

Take-home assignments sound good to interviewees, but as an employer I would be skeptical of the results since there is no way to know if the interviewee copied the code or had a friend help them or whatever.

The FizzBuzz article and the other linked stories were eye-opening. Double humps!

IMHO, the main things to assess about a candidate are:

1. Basic competence and understanding of fundamental concepts, including the ability to execute on that in person. (FizzBuzz style)
2. Domain expertise.
3. Problem-solving acumen, unrelated to domain.
4. Interpersonal skills.

Someone who scores in all of those categories is likely to be a valuable team member.
posted by grumpybear69 at 4:02 PM on March 1, 2017 [3 favorites]

Once in a prior life I had kind of a "bar raiser" role -- I had wide latitude to interview candidates about whatever, tho I didn't have the power to reject someone unilaterally, like bar raisers do at Amazon.

And like many people I think traditional whiteboard interviews are pretty stupid and are crap at identifying people I want to work with. So my go-to questions were:

a) can you deal with ambiguity? I'd ask something like "revenue is down, it's your first day, you're alone in the office, there's a VP asking what's going on, what do you do?" I'm looking for questions back like "what is revenue?" "how do we know it's down?" "what are the partitions in revenue?" "Is today a special day, like the day after the Superbowl where customer behavior changes a little bit?" "What's the real impact of this, is this something I need to drop everything for?" In my experience, if you can't be productively inquisitive, you're going to have a tough time working the jobs I've worked. Everywhere I've gone, no one has the complete solution to any problem, and often no one has any part of the solution, or the person who does is sick/in a meeting/fired/etc.

b) can you read code, figure out what it does, and review it for quality? I spend far, far more time reading code than writing it. Reading code helps you figure out what's going on when no one knows what's going on.
posted by Sauce Trough at 4:02 PM on March 1, 2017 [16 favorites]

This! Why can't there be more this? Take-home projects, where you comment your code, and then analyze it with your interviewers, describing your process; THAT is the way to actually see what you do when asked to produce code for somebody else.

Because people will cheat. They'll get their friends to help whether a little or a lot. This is why.

You need to be able to evaluate the candidate face-to-face, in less than an hour. The only real way to make this less than a completely random process is to have several people do it independently.
posted by GuyZero at 4:03 PM on March 1, 2017 [3 favorites]

But I should add when I ask programming questions in interviews, they're pretty basic. Like just a notch above fizzbuzz. It's not about the code really.
posted by GuyZero at 4:03 PM on March 1, 2017 [3 favorites]

2. Domain expertise.

This is mostly overrated IMO. Mostly I'd prefer to take competent candidates with little to no domain expertise over domain experts. It's nice to get them both but in some domains you don't have a lot of experienced candidates.
posted by GuyZero at 4:05 PM on March 1, 2017 [4 favorites]

They'll get their friends to help whether a little or a lot.

This is how I usually get things done at my job. I get help from my coworkers every day. I bounce ideas off them, ask for their advice, maybe even pair with them if I'm feeling social. Because they are cool and know things I don't, and sometimes I know things they don't. Beautiful mutuality. The places I like to work, everyone is someone else's Stack Overflow.

Also, if someone's cheated on a take-home thing and they aren't conversant with their solution, then you can suss that out pretty quickly when you follow up with them. And if they are conversant with their solution, I don't care what resources they used to achieve it.
posted by Sauce Trough at 4:14 PM on March 1, 2017 [12 favorites]

Take-home assignments sound good to interviewees, but as an employer I would be skeptical of the results since there is no way to know if the interviewee copied the code or had a friend help them or whatever.

---

Because people will cheat. They'll get their friends to help whether a little or a lot. This is why.

---

If you're not able to determine that by reviewing their code with them in the follow-up interview, like I mentioned, then I'm not sure what to say. I've received and given both types of interviews and I guess luckily or by virtue of actually properly interviewing them haven't had cheaters get past me.

---

It does have drawbacks, though, primarily that it's biased against candidates who can't carve the time out of their off-hours to do the project.

---

That's a good point and I'm not sure sure how that one would be solved, but I still feel as though it would be time better spent, as opposed to cramming for a whiteboard interview.
posted by destructive cactus at 4:16 PM on March 1, 2017 [5 favorites]

Yeah, cactus, if your choice is between "do a programming task of limited scope on your own time" and "cram everything about CS that Steve Yegge mentions in his famous get-a-job-at-Google post" I think the first is much more accessible.

Not perfectly so, but better.
posted by Sauce Trough at 4:19 PM on March 1, 2017 [2 favorites]

Take home projects are a double edged sword. On one hand it removes the time pressure/artifice of white boards. On the other, they can be weaponized to take up enormous amounts of time or to get work for free.

I interview a lot of candidates and others have observed that I'm rarely, if ever, wrong in my assessments. My process is four stages. First, present a problem with which any software professional should be at least passingly familiar rather vaguely and let them ask for additional information. The questions they ask tell me if they know what matters/what doesn't for this kind of problem and if they know how to break something like this down. Second, I have them present to me multiple ways to attack the problem. Not implementations - general strategies. This tells me they know there are many different ways to skin a cat. Third, I have them advocate both for and against all the solutions they laid out. Finally, I change the spec on them with previously undisclosed customer complications and ask them how that changes their answers. Not actively looking for more information disqualifies. Not considering multiple solutions disqualifies. Not arguing the merits of their solutions fairly both pro and con disqualifies. Drama over the changed spec disqualifies. It's tough to get through all this in an hour, but the ones I want to hire often do so with time to spare.

Syntax doesn't matter to me (in fact, I prefer pictures if they're going to use a whiteboard). A sucky or sub-optimal solution doesn't matter to me. I'm all about how they got there, and the manner in which they worked with me to lay it all out. Because that's the fucking job.

Software is an easy target, though. All interviewing is hard. I've found there are very few people who do it well.
posted by NoRelationToLea at 4:31 PM on March 1, 2017 [25 favorites]

My policy these days in terms of interview questions is to discover:

do you understand coding/dbs/whatever enough that I can assume you're not lying on your resume.
walk me through your last/favorite project, start to finish - what went right, what went wrong, how did you address
talk to me about something you give a damn about so I can see how your personality operates and how your brain lights up

I find this does pretty well to land me on candidates who I can work with, are fast witted and can keep pace with new tech/new approaches. I don't care if you know language Y and tool Z, we probably won't be using those in 2 years.
posted by drewbage1847 at 4:33 PM on March 1, 2017 [3 favorites]

I know that I've mentioned this a million times, but I'm currently taking CS classes at a not-super-elite university. I took the intro class for CS majors last semester, and I'm taking Discrete Structures now. And one thing that I've noticed is that the profs really seem to be preparing us for this kind of interview. For instance, I've already been told several times that it's a good idea to practice coding sorting algorithms, because that's a common interview question. (I can write bubble sort. I know this because I did, in fact, go home and write out bubble sort and get it to work. I could also tell you Big O of bubble sort and explain why it's a shitty way to sort, but I don't have any confidence that I could code up quick sort or merge sort.) Our exams last semester were all in the format that we were given a program to write and had to write it on a piece of paper and then answer some questions about it. The professor was like "you'll never do anything like this in real life, but job interviews are a lot like this, so it will be helpful." And the funny thing is that I'm now half-way through my third CS class, and I still have no fucking clue what people who work in computer science for a living actually do all day. I have literally no idea if this is right, but I kind of wonder if students in the CS major are being prepared for job interviews, rather than jobs.
posted by ArbitraryAndCapricious at 4:35 PM on March 1, 2017 [14 favorites]

On the other hand, I find this kind of question kind of fun and am now thinking about how one would write a function that determined whether one set was a subset of another set, so it's good for people who like the logic puzzle aspect of CS, I guess.
posted by ArbitraryAndCapricious at 4:37 PM on March 1, 2017 [5 favorites]

I still have no fucking clue what people who work in computer science for a living actually do all day.

Mostly glue a bunch of framework code together, and write a bunch of tests that you know will pass
posted by thelonius at 4:39 PM on March 1, 2017 [36 favorites]

I thought "why is increment usually not thread safe" would be an easy bar for anyone interviewing for a back end coding position, especially beyond entry level, but... whooooo-boy no. SO many people have no idea what I'm asking, tell me that it is, or overthink it and start talking about memory barriers. I think I've had less than a 5% success rate with that one.

The company I work for was acquired a couple years ago, and as part of the process we got interview training from the woman who wrote a book about it after leaving google in case an acquiring company interviewed us as part of due diligence.
Like the article and everyone here is saying, there is exactly nothing about implementing algorithms on a whiteboard while someone stares at you demanding perfect syntax that maps to real development work, but at least we know that, knew it was stupid but might lead to a higher sale price, and have never done interviews like that.
posted by flaterik at 4:41 PM on March 1, 2017 [1 favorite]

I still have no fucking clue what people who work in computer science for a living actually do all day.

You're not getting a telescope operation education, you're getting an astronomy education, because that's what they have for "stuff that doesn't change super quickly". I think Carter was president when quicksort was invented. If they're not awful, they'll teach you in version control, maybe mention CI once or twice, make you write some unit tests, stuff that's been reliably proven in software-engineering land.

But software tools exist and there's a huge menagerie of all of them, many used in production. And the way software folks work has fundamentally changed in the last 30 years and will fundamentally change again in the next 30. So that's the goal - to not be bullshit in 10 years. I don't know whether they succeed.
posted by hleehowon at 4:43 PM on March 1, 2017 [4 favorites]

I still have no fucking clue what people who work in computer science for a living actually do all day.

People who work in computer science are academics, so they're either teaching or doing research. Computer science has very little to do with software development.
posted by dilaudid at 4:51 PM on March 1, 2017 [14 favorites]

I think quicksort was invented when Eisenhower was president.
posted by Death and Gravity at 4:55 PM on March 1, 2017 [6 favorites]

If you're not able to determine that by reviewing their code with them in the follow-up interview, like I mentioned, then I'm not sure what to say. I've received and given both types of interviews and I guess luckily or by virtue of actually properly interviewing them haven't had cheaters get past me.

But when you catch them then it's just a waste of everyone's time. And on the off chance you don't catch them then you have a bad hire which is bad for everyone.
posted by GuyZero at 4:55 PM on March 1, 2017

People who work in computer science are academics, so they're either teaching or doing research. Computer science has very little to do with software development.

I think quicksort was invented when Eisenhower was president.

And that first quicksort is still running on an IBM 1401 today. It's due to finish in 2031.
posted by GuyZero at 5:09 PM on March 1, 2017 [14 favorites]

People mainly get CS degrees so they can get jobs in Software Development, where 9/10ths of what they learn won't be useful except in interviews, which are basically a test of how recently you took a CS degree.
posted by Artw at 5:10 PM on March 1, 2017 [12 favorites]

And the funny thing is that I'm now half-way through my third CS class, and I still have no fucking clue what people who work in computer science for a living actually do all day.

In theory I know what they do all day and there's just no one magic answer. My experience is you end up dealing with higher-level abstractions built on top of the things you studied in school. At some point things get so abstract they promote you to product management.
posted by GuyZero at 5:11 PM on March 1, 2017 [2 favorites]

I mean, that's an awesome gotcha, and you sure showed me! But I would be really surprised if 5% of the CS majors in my classes are going to be academics. So assume that I know that you think I'm a garbage person, because trust me, I am aware of that! And then read that statement as "people who have CS degrees from non-elite universities."

I'm sorry for being condescending. It's just frustrating to see the limited ways software engineering concepts penetrate into undergraduate educations, as opposed to computer science concepts (which are useful in their own way). But basically what software engineering comes down to is translating abstract ideas into code, usually in collaboration with other people. The "other people" part is where most of the complexity comes from.
posted by dilaudid at 5:15 PM on March 1, 2017 [7 favorites]

For the record, I used the disjoint set data structure on Monday. I find the "no one ever uses this stuff" presumption kind of frustrating. There are totally interviews in which the latter half of the algorithms book you never read are appropriate questions. Doesn't mean that they're bullshit in a lot of circumstances, nor that they're a barrier to greater diversity in the tech industry. But, yeah, it's frustrating when straight white men complain about how they shouldn't have to code on a whiteboard.
posted by hoyland at 5:20 PM on March 1, 2017 [8 favorites]

FWIW, this is IME completely standard in Bay Area tech companies at this point. It does have drawbacks, though, primarily that it's biased against candidates who can't carve the time out of their off-hours to do the project.

The solution to this is to pay an industry-competitive hourly rate for the number of hours you expect them to spend on the solution. It's fair, it's in the applicant's interest to finish it in the expected amount of time, the result is much more indicative of their ability, and all of the downsides (wasted time, potential for false positives) are downsides of the existing process already and are about as likely to happen.

The meta-solution is to offer candidates a choice between this and an on-site interview, and the onsite interview should consist of either completing a well-scoped, small, greenfield project or debugging task on a real computer set up with their environment of choice (and the employer should be able to provide the computer with the environment ready to go, within reasonable limits), with googling allowed.

None of these solutions are perfect, but they're more humane and give better information to boot. I think it's a combination of inertia, hazing (I went through this, so you should too) and short-sighted cost-benefit analyses (I think a lot of places would balk at paying market rate for a take-home challenge, even though it would have a negligible effect on their bottom line, and may save costs elsewhere) that keep them from being widely adopted.
posted by invitapriore at 5:21 PM on March 1, 2017 [4 favorites]

I'm basically planning on retiring at my current job rather than have to endure having an interviewer who wasn't alive when I started coding ask me to implement Fizzbuzz in Javascript.
posted by octothorpe at 5:23 PM on March 1, 2017 [25 favorites]

From the age of 7 my life's coding arc goes recreational >> educational >> recreational, so I can't claim direct experience. What I will say though is that I still feel some utterly ridiculous sense of "cheating" whenever I have to look up stuff that's in the Python Standard Library or whatever instead of knowing it off by heart. Doubly-daft when I think back on proselytising throughout my teens that "the GM doesn't need to know the rules, just where they are in the manual"!

I have a nasty suspicion that I would be one of the more idiotic of these interviewers, given enough rope!
posted by comealongpole at 5:32 PM on March 1, 2017

I know people hate "whiteboarding" and I definitely get why, but I also think every programmer should be familiar with some basic concepts and be able to reconstruct them from a clean slate, if given a bit of a reminder about what they are. Like anyone worth hiring should be able to give pseudocode for a binary search of a sorted array, or should be able to explain how a hashtable works, and why it's an attractive data structure, even if they can't come up with a complete implementation on the fly.

What drives me nuts is that I can't seem to get to the point where someone would ask me these questions because, I assume, I have a non-traditional background and no formal CS training.
posted by dis_integration at 5:36 PM on March 1, 2017 [5 favorites]

I still have no fucking clue what people who work in computer science for a living actually do all day

At its most basic? I personally try and solve problems.

Often not real problems. Often ancient problems. Problems that aren't my fault. Problems that are definitely my fault. Sometimes we get to argue with each other for hours or days or years about whether or not something is or is not, in fact, a problem. These problems can be as trivial as what tools your team are going to use to literal rocket science or its equivalent.

Once we all agree on the problem (haha - good luck), we shift to solution space. Often not real solutions. Often tried and true solutions. Etc. This part usually entails even more discussion (really, argument).

Now that we've come to an agreement (not really, but stay with me here), we need to resource someone to actually implement the solution. People might get to write some code at this point - maybe - if you have the headcount.

There are tons of nuances to all this within this particular tribe. CS degrees mainly present canonical problems/solutions/techniques/tools (like big O, discrete math, etc.) to be leveraged at the architecture or implementation stage. They don't teach you at all about engineering, or being effective working with people with poor social skills whose typical degree program completely forgoes that stuff, or how to evaluate what problems are worth your time, or what solutions have already been tried, why they worked/didn't work, etc. Crossed fingers you land at a place that can teach you some of this stuff.

In general, I'm bitching about it, but I've found that well run shops tend to spend way, way more time on the "ready, aim" part vs. "fire" as it's so easy to waste time via bullshit implementations or by signing up for technical debt, etc.
posted by NoRelationToLea at 5:39 PM on March 1, 2017 [8 favorites]

There are totally interviews in which the latter half of the algorithms book you never read are appropriate questions. Doesn't mean that they're bullshit in a lot of circumstances, nor that they're a barrier to greater diversity in the tech industry.

I think of anything you can teach yourself out of a book, demonstrate by acheiving objective results, and get paid for as a *route* to greater diversity. Better than 'passing for a gentleman' or 'social fit' or whatever homophily is defending itself as this decade.
posted by clew at 5:51 PM on March 1, 2017 [2 favorites]

On the non-technical side, travel and lodging costs for non-local interviewees should be paid up front, not reimbursed. It is insane to me that asking people to front sometimes on the order of $1K, on top of the demand on their time, isn't seen as the discriminatory practice that it is. I've been pretty vocal about this at every place I've worked that does it, and the response has always basically been "thank you for your feedback." It's an unfortunate reminder of the socioeconomic homogeneity of this industry, since I've found that most people I talk to about it aren't already aware that that would be an issue for someone.
posted by invitapriore at 5:51 PM on March 1, 2017 [4 favorites]

This is a weirdly timely article, because I'm literally just now talking to a recruiter, and oh god this is basically my major anxiety. I probably should have found myself a new job some time ago, but the crippling anxiety about this kind of bullshit hazing interview has basically kept me from doing it.

It's like companies that are hiring are trying to not hire people. Are you interested in whether I can dance like a monkey on cue, or whether I can solve problems on a daily basis as I have been doing in this industry for the past 15 years?
posted by tocts at 5:53 PM on March 1, 2017 [11 favorites]

I find the "no one ever uses this stuff" presumption kind of frustrating.

I would never say, "nobody uses this stuff" -- but, I think it's totally fair to say, "nobody implements this stuff from memory, without looking at a single goddamn piece of literature or documentation".

I think it's totally fine to want to suss out that an interviewee understands that there are different sorting algorithms or data structures, and the high level reasons they might choose one over another. Knowing the questions to ask and the places to research is like half the job. However, assuming an interviewee should be able to just bang out an implementation of one of these (or implement a particularly tricky operation with one) on a whiteboard is 100% bullshit.
posted by tocts at 5:56 PM on March 1, 2017 [6 favorites]

Take-home assignments sound good to interviewees, but as an employer I would be skeptical of the results since there is no way to know if the interviewee copied the code or had a friend help them or whatever.

As long as they will still have access to their friend while they're working I don't really care.

But more importantly, you can take the interview time they would have spent writing and ask them actual interesting questions about the tradeoffs they made, how they would do it differently under different constraints, why it was a bad question and what should have been asked instead, etc. You'll get much more useful information and in the process it will become very clear if they wrote the code or not.
posted by Tell Me No Lies at 6:00 PM on March 1, 2017 [5 favorites]

Yeah, the cheating concerns about take-home projects seem overblown. If your engineers can't determine whether I wrote something after I've presented it to them, talked them through all the decisions I made, and answered any questions they have about it, then maybe they do not have the appropriate skills to be interviewing candidates.
posted by tocts at 6:05 PM on March 1, 2017 [11 favorites]

If I had candidates do a take-home code exercise I think I'd post my question on Stack Overflow, eventually post my own solution, and see how many people copy and paste it. I'd be curious if they chose one of the other answers, or came up with something purely original. Maybe I'd even post a slightly inefficient or broken answer just to see who copied it outright and who fixed it.

The problem with this idea is that the mods would probably shut the thread down as irrelevant so I'd have to plan ahead with a real question to which I already know my answer.

Copy and paste happens all the time. One thing I want to know is if you can tell good code (to copy and paste) from bad.
posted by fedward at 6:12 PM on March 1, 2017 [3 favorites]

I hate whiteboard tests. It is an art and the interviewer needs to be quite good at it. Many are not and some want to prove how smart they are and not learn about the candidate. Like anything, the talented ones make everyone feel better about having spent the hour together.

I usually ask candidates to tell me what they would need in a new laptop or VM to do their job, and how they would organize a new project so that others could work with it. Then I want to see docs. Those things tell me a lot about the future usefulness of the person.

When it comes to coding what i want know is can they live without an IDE if necessary, and how do they debug.
posted by drowsy at 6:15 PM on March 1, 2017 [2 favorites]

Nobody needs to remember how to implement merge sort off the top of their head

A friend of mine - who is quite badass - went to an interview where they were going to ask this kind of thing. They made the mistake of asking him if he had any questions about what they were going to ask him to do, and he says "yes, can one of you guys sketch how you'd design a on the whiteboard? I just want to make sure that you guys are competent to pronounce judgment on what I'm doing."

I gather it kind of went downhill from there, but still...
posted by 43rdAnd9th at 6:16 PM on March 1, 2017 [9 favorites]

I think many interviewers are lazy so they pick a few hard problems that they personally know well and just ask everyone the same thing. I've done this in the past and regret it now.

The thing I'm worried about when I'm running interviews now is "am I quizzing this person to find out how much like me they are?" (This can apply socially as well as intellectually). Rather I want to find out "what does this person know that I don't?". If I can learn something interesting from someone in a 45 minute conversation, that's a nice sign: they've done interesting work AND can communicate it well to others. This style of interview is a lot harder on the interviewer --- you actually have to put in the effort to understand something new.
posted by sloafmaster at 6:31 PM on March 1, 2017 [13 favorites]

is can they live without an IDE if necessary

How would such a necessity arise?
posted by Sauce Trough at 6:32 PM on March 1, 2017 [5 favorites]

You're SSHed in somewhere and you're using vim

(it's not true ofc you can ssh in with IDEs too)
posted by hleehowon at 6:35 PM on March 1, 2017 [3 favorites]

I don't know if it's just me, but I just went through a few months of whiteboard coding and I extremely prefer it to the hated take-home project. Whiteboard coding is about preparation, yes, but also creativity and having a meaningful and abstract conversation, which is indeed important. It's easy to get rusty on sort algorithm fundamentals, but at least they're interesting. It can actually be pretty fun if the stakes are low (i.e., you're already employed). Take home projects mean spending a bunch of my free time working on something meaningless for free (they're rarely very interesting projects, though sometimes they are) and perfectionism is a much bigger problem for me than thinking on my feet.

That's just my preference as an interviewee, though; I don't know if interviewers genuinely find whiteboard interviews superior or if they just seem hard and therefore good. I do like that most whiteboard interviewers I've had have been extremely handwavey about implementation details so there's no need to become a human Stack Overflow before the interview.
posted by stoneandstar at 6:36 PM on March 1, 2017 [1 favorite]

I'm in the second year of my first job as a back end developer. When I interviewed at my company, the first round of actual coding related stuff was pair programming and implementing a Set class in a test-driven way in Java, even though I wasn't a Java dev and that wasn't the language the company was hiring for. I explained my thought process and implementation, and the CTO of the company would implement it based on my instructions, handling syntax and things about the language that I didn't know.

After that, I paired with one of the devs and worked with them on whatever they were working on at the time.

I found this to be a very reasonable way to be tested. And having been on the other side of it, I still feel that way.
posted by defenestration at 6:37 PM on March 1, 2017 [3 favorites]

And I also don't know if it's just me, but I've gone through a lot of interviews where I get asked "passion" questions or "tell me about a time you solved an interesting problem" questions which I find pretty annoying, since they are implicitly culture questions dressed up to look like technical questions. Yes, if I tell you what I find interesting it will tell you something about me, but then you're kind of setting yourself up as the arbiter of what is "interesting" on a supposedly objective, technical level, which as a woman in tech seems to be... not always so objective.
posted by stoneandstar at 6:44 PM on March 1, 2017 [7 favorites]

Oh hey, can this also be the thread where we complain about how bullshit it is that any company ever has put something on a job description like:

Your passion for development is illustrated in your own personal projects.

Fuck. You. I develop for a living. I do it well. Then I go home, and have a family, and a life, and many interests that do not include maintaining a bunch of side projects just like my job but without being paid so I can impress a fucking recruiter.
posted by tocts at 6:52 PM on March 1, 2017 [47 favorites]

In general, I'm bitching about it, but I've found that well run shops tend to spend way, way more time on the "ready, aim" part vs. "fire" as it's so easy to waste time via bullshit implementations or by signing up for technical debt, etc.

I always wonder where these places are. I see people online talking about how they're moving their Scala service over to an onion architecture where a free monad-based DSL at the core is interpreted at service boundaries into effectful computations, and my mind is blown, because I feel lucky if I get the time to move some logic in a grab-bag util module into the class it operates on for the sake of encapsulation, and that's how it's always been.
posted by invitapriore at 6:54 PM on March 1, 2017 [10 favorites]

Is there any chance that "your passion for development is illustrated in your own personal projects" is meant to select for people who don't have the kind of personal life that would distract them from working 80 hour weeks?
posted by ArbitraryAndCapricious at 6:55 PM on March 1, 2017 [18 favorites]

Oh, I'd say there's a chance alright.

They might as well just say, "You're young and single, with no distractions and no concept of how abusive it is that we're planning on stretching your week to 60-80hrs on the regular."
posted by tocts at 6:59 PM on March 1, 2017 [8 favorites]

We usually do a variation on the Whiteboard Interview, where we hand them a laptop with Visual Studio (or SQL management studio, depending on what we're interviewing for), and ask them to actually write and run the code.

I prefer it because you can watch them interact with the code. Do they make a small logic or syntax error? Do they recognize the problem when they run the code and look at the output? How easily do they figure out what mistake they made?

(And frankly, watching how confident someone is in manipulating a text file is not the worst piece of data to have.)
posted by Blue Jello Elf at 7:04 PM on March 1, 2017

The problem is that this is a case where the act of observing can have an effect on the thing being observed. I give people the choice for on-site coding interviews whether they want to pair or not, with the explicit addendum that I personally hate having someone hovering over my shoulder and so they will suffer no penalty if they choose to not have me watching their screen. If the tarball they give me at the end is reasonable, it's not really my business what their low-level process looks like, especially because this is such a fruitful arena for cultural biases about how someone should develop to come to the fore. Comfort with pairing isn't a requirement of any job that I've worked, so I don't see why subjecting someone to that if it makes them uncomfortable should be a requirement for making it through the interview process.
posted by invitapriore at 7:11 PM on March 1, 2017 [3 favorites]

I always wonder where these places are.

I think this ultimately comes down to craft - like, game recognize game you know?

Look, you're there to interview them, as well - right? It should be fairly obvious if you're dealing with pros or people pretending to be.

Is the product well sorted? Are there signs of organizational chaos? How much "pivoting" (jeez I hate that word) have they done? Are they buzzword compliant? How long have people been on the team? What technologies are they using? It's bad if they never updated, but it might be worse if they're mostly volunteering to be guinea pigs for the latest greatest language/framework/trend.

Relevant to this thread: are their interviews bullshit? Do you get to talk to people with whom you'd actually be working? I can't believe we even need to ask that question, but somehow we've gotten to the point where that's not a given.

Resources are scarce - none more so than time. If they don't make effective use of their time talking to you, or respect the time you need to put in on your side - that tells you tons.
posted by NoRelationToLea at 7:18 PM on March 1, 2017 [1 favorite]

I was chatting about this on a Slack the other day. Interviews are a designed process, and they tell the candidate a lot about you. If the process sucks, like coding on a whiteboard, that's probably a sign. If they don't value your time, that's a sign.

Can I book a session with your anger translator? I have this comment on a pull request I need to discuss with somebody or I will esplode.
posted by fifteen schnitzengruben is my limit at 7:33 PM on March 1, 2017 [3 favorites]

I would question whether this contributes to the dearth of diversity in tech. I'm not questioning minorities they start from a disadvantage in these situations. I'm just remembering that every study is in how we subjectively evaluate (like "walk me through your approach on this project") is that those are massively biased towards people thinking "smart" = "like me."

I suppose by analogy locking candidates in a room, having them code for two hours, then doing blinded evaluations of the output would be the way to avoid this. It's still not a real world problem but it does put people on more of an equal footing, at least for those early career positions.

I think this ultimately comes down to craft - like, game recognize game you know?

Look, you're there to interview them, as well - right? It should be fairly obvious if you're dealing with pros or people pretending to be.

I've never seen a study in the computer industry but every one I have seen suggests in aggregate (a) people are horrible at predicting candidate performance using any interview technique and (b) people believe they are good at it.

I have worked with enough people in the software world that I'm pretty sure this is not the exception to the rule. People seem to slide through.
posted by mark k at 7:36 PM on March 1, 2017 [2 favorites]

Re: FizzBuzz. I do a lot of tech interviews, and I use FizzBuzz as the most basic of vanilla checks. Lots of people have obviously looked it up as part of their interview prep, which is just fine--it wasn't going to tell me a whole lot on its own.

After they do it on the whiteboard, I ask my real FizzBuzz question: How would you test that? Way too many people can't think of anything other than writing the results to a file and verifying the expected contents.
posted by Ickster at 8:11 PM on March 1, 2017 [4 favorites]

RE: The interview experience I had, and why I thought it was good. It focused on problem solving and communication. It wasn't overly complex, but it was complex enough to allow someone to form an opinion of the applicant based on those (and some other) factors.

Then the follow up—actually I pair programmed with two different devs, now that I think about it—allows you to see how someone gets started in an existing codebase, how they communicate, and how they implement things and organize them, etc. And the general skills in the language and frameworks and libraries used in the company's stack, etc.

Again, having now been on the pairing side of it, as part of the process of interviewing applicants, I still think it works well. By the time we give make an offer and someone starts, I feel like we have a good idea of how they'll work and communicate, etc.

It's probably harder for larger and more competitive companies though. We hire a lot of people who are somewhat newer to the field, though not necessarily junior. So our goals and what we look for might be different than other types of companies.
posted by defenestration at 8:17 PM on March 1, 2017

More in tune with the point of the post though, is that none of the questions we ask are the sort that have a "right" answer. Algorithms and trivia can easily be looked up, and everyone I work with does it absolutely all the time with no embarrassment. (At a different job, I once had a co-interviewer ask a candidate what the parameters were for a JDBC connection string. I interrupted and waved the question off while privately staring daggers at the questioner.)

What we ask are questions about concepts and principles, with the goal of engaging in conversation. The job of the interviewer is to do our damnedest to put the candidate at ease and to guide the candidate through the questions. The ones who have at least heard of a lot of the concepts and are willing to discuss them are the ones who generally end up hired. Our track record isn't perfect, but it's been good.
posted by Ickster at 8:21 PM on March 1, 2017 [2 favorites]

* One of the client developers, on a long lived feature branch, reverted a merge from the develop branch, and didn't merge his feature branch for another month. Memail me a :facepalm: if your stomach just sagged.

WHAT

WHY

NO
posted by verb at 8:24 PM on March 1, 2017 [4 favorites]

every day and in every way we stray further from god's light
posted by hleehowon at 8:28 PM on March 1, 2017

Good git practice and flow is a must. That scenario is stressing me out, and I have nothing to do with it.
posted by defenestration at 8:29 PM on March 1, 2017 [4 favorites]

I'd tell you about my place of work, but our deployment and branching practice would probably cause your head to explode. Honestly we should make "what is wrong with this?" an interview question/warning.
posted by Artw at 8:30 PM on March 1, 2017 [2 favorites]

I would question whether this contributes to the dearth of diversity in tech. I'm not questioning minorities they start from a disadvantage in these situations. I'm just remembering that every study is in how we subjectively evaluate (like "walk me through your approach on this project") is that those are massively biased towards people thinking "smart" = "like me."

Diversity is complicated, and you can't attribute whatever problems tech has with diversity to merely bad interviews.

FWIW, I ran my company's numbers, and at least for the folks that would be subject to technical interviews: about 1/5th are women, over half are POC, almost 2/3rds are 1st generation immigrants. Of the managers, 1/3rd are women, almost 2/3rds are POC, and almost 2/3rds are 1st generation immigrants.

At least in my experience, barring companies filled with javascript, beards, and IPAs - those kinds of numbers are really not that hard to find in tech companies.

I've never seen a study in the computer industry but every one I have seen suggests in aggregate (a) people are horrible at predicting candidate performance using any interview technique and (b) people believe they are good at it.

Tech is a completely different animal. You can't extend those studies across industries, and even across companies would be problematic. Not everyone is Uber, thank goodness.
posted by NoRelationToLea at 9:16 PM on March 1, 2017 [1 favorite]

>>> is can they live without an IDE if necessary

>>How would such a necessity arise?

> You're SSHed in somewhere and you're using vim

I get precisely one "Get off my lawn" per year and I'm using it for this:

Unix command shells were IDEs before anyone even thought of that name. The fact that kids are stuck on GUIs does not change their effectiveness a bit.
posted by Tell Me No Lies at 9:22 PM on March 1, 2017 [11 favorites]

Nobody needs to remember how to implement merge sort off the top of their head

Damn straight. Who needs to remember mergesort? Just reinvent it on the fly from first principles!

I do whiteboard algorithms for a living. I have a PhD in algorithms. I write algorithms research papers. I teach algorithms. I wrote this. If you've taken an algorithms class or interviewed at a major tech company in the last ten years, you've probably been asked one of my old homework questions. I'd kick ass and chew bubblegum in a whiteboard algorithms interview, and I'm all out of bubblegum.

I wouldn't last two weeks in a real coding job.

And I wouldn't get the interview in the first place, because my undergrad GPA is too low.
posted by erniepan at 9:22 PM on March 1, 2017 [19 favorites]

I've never seen a study in the computer industry but every one I have seen suggests in aggregate (a) people are horrible at predicting candidate performance using any interview technique and (b) people believe they are good at it.

No question the largest interviewing issue I've seen virtually everywhere is zero training for interviewers.
posted by Tell Me No Lies at 9:25 PM on March 1, 2017 [3 favorites]

I sent back a layered Photoshop file which contained the words, "I don't work for free" and unsurprisingly (and thankfully) never heard from them again.
FWIW none of the takehome assignments I've been given have ever been anything that could have been actually useful to the companies I was talking to. I've had bullshit assignments (I never want to see anything to do with generating prime numbers ever again), and I've had poorly-spec'ed assignments, but none of them fell into the category of real work product.
posted by asterix at 9:32 PM on March 1, 2017 [3 favorites]

You're SSHed in somewhere and you're using vim

vim has syntax highlighting, brace matching, a ton of IDE-ish richness.

vim was a big help when I learned Ruby and Python.
posted by Sauce Trough at 10:12 PM on March 1, 2017 [2 favorites]

Presuming there's still a civilization in a couple of decades, the best revenge will be when these kids who look down their noses at those of us with decades of experience now are in turn looked down on by kids not yet born who think anything written before 2032 isn't worth knowing about.
posted by ob1quixote at 10:31 PM on March 1, 2017 [2 favorites]

Yeah, um, that is not a take home assignment. A takehime assignment is more like "here's some xml, parse it, mapilulatd the data a bit and do something pretty with the output", not "build us an entire videogame".
posted by Artw at 10:34 PM on March 1, 2017 [2 favorites]

Good git practice and flow is a must. That scenario is stressing me out, and I have nothing to do with it.

It has a happy ending: none of the files affected by the revert had commits following the merging of the feature branch, so reverting the revert undid the problem in one step without issue.

Honestly we should make "what is wrong with this?" an interview question/warning.

You absolutely should. Ability to intelligently critique tooling and process has proven to be a good marker for us. We've hired five people based partly on doing well on that question, and they've all proven to be good hires.

Diversity is complicated, and you can't attribute whatever problems tech has with diversity to merely bad interviews.

Agreed. In our group of nine, we've hired five based on strong technical interviews that were largely subjective, conversational exercises including the git question, just to see if the person had a brain in their head and got along with us. That's meant two women, a very conservative Asian Christian, a French open source fanatic, and someone I'd charitably describe as neuro-atypical. Our group has never performed or gotten along better. The "culture fit" aspect doesn't need to be about homogenizing if you're conscious that the qualities you're looking for are orthogonal to personality and appearance.
posted by fatbird at 10:42 PM on March 1, 2017 [2 favorites]

FWIW, I ran my company's numbers, and at least for the folks that would be subject to technical interviews: about 1/5th are women, over half are POC, almost 2/3rds are 1st generation immigrants. Of the managers, 1/3rd are women, almost 2/3rds are POC, and almost 2/3rds are 1st generation immigrants.

At least in my experience, barring companies filled with javascript, beards, and IPAs - those kinds of numbers are really not that hard to find in tech companies.

I'm not sure I follow your point. Are you saying this to indicate diversity? If PoC and immigrants means mostly South and East Asians that indicative of the rather standard limited diversity you find in tech--overwhelmingly male and and white / Asian.

It almost exactly matches the Google demographics of their employees that they released.
posted by mark k at 11:01 PM on March 1, 2017 [3 favorites]

"Can you show me some issues and incidents in your (bugzilla/trac/mantis/jira/whatevs..)" separates the companies I'd consider from idiots I want nothing to do with. Unless it's a C-level gig, and I have the mandate to fix shit.

That and if they have an issue with my hair. You got a problem with my hair, and I'm "Nexting" you immediately.
posted by mikelieman at 11:44 PM on March 1, 2017 [2 favorites]

I was asked for some input into our interviewing process, and suggested that we do a code review together with the candidate instead of whiteboarding or questions. So I pulled some code from production, added a couple of easy-to-find issues to get people started and we used that as the technical part of the interview. We're pretty big on reviews, and going through the code with the candidates gave us a good feel of both problem solving, social and technical skills. Some candidates didn't find much, but were able to give an account of what they were looking for and how they would approach the review, and some candidates found most of the issues and were able to suggest fixes. One candidate even found an issue we didn't know was there.

The people we hired have turned out to be excellent fits and great contributors, but the sample size is of course really small.

We were also very clear up front that this was production code and that there were no trick questions buried in the source somewhere.
posted by Harald74 at 12:11 AM on March 2, 2017 [9 favorites]

I love you and want to have your company's babies.
posted by mikelieman at 12:18 AM on March 2, 2017

I'm not sure I follow your point. Are you saying this to indicate diversity? If PoC and immigrants means mostly South and East Asians that indicative of the rather standard limited diversity you find in tech--overwhelmingly male and and white / Asian.

In what world does POC mean everyone but Asians? My South Asian co-workers who are having trouble getting back into this country because of our current immigration policy would take serious issue with your insinuation that their current experience represents "standard limited diversity."

Know who else would take issue with your position? Srinivas Kuchibhotla and Alok Madasani, whose murder/attempted murder in Kansas have (fucking finally) been declared an "act of racially motivated hatred" by a White House spokesperson.

"Meh, there sure are lots of Asian in tech, therefore they don't count" is not an argument that holds water. Especially when it's been less than a week since at least one person you characterize as apparently fake diversity were yelled at to "Get out of my country" before being killed. But hey, those victims were Asian and male and in tech - so murdering them can't be a hate crime, right?
posted by NoRelationToLea at 1:02 AM on March 2, 2017 [2 favorites]

It can simultaneously be true that your South Asian colleagues face systemic racism and that women of all races, African-Americans, Latinos, and members of various other groups are underrepresented in tech. Those things aren't contradictory. And there are, in fact, plenty of instances in which people talk about underrepresented groups, rather than PoC, because lumping together all PoC would obscure things that need to be addressed. Medical schools, for instance, have a pretty finely-grained definition of "underrepresented" and release stats about both the percentage of their classes that are PoC and that are from underrepresented groups.

I understand that this is an industry-wide problem, but the idea that there's anything impressive about a team that is 20% women is mind-boggling to me.
posted by ArbitraryAndCapricious at 2:00 AM on March 2, 2017 [9 favorites]

I developed a technical screening system for work, and it is one of our most successful methods. I won't describe it or even mention for whom I work, but I'll tell you a general secret about it:

It's the Kobayashi Maru.

I've seen the solutions to the apparent technical puzzles on Internet forums, like Infocom game walkthroughs. "Oh yeah, if you get stuck on this bit, do that and you'll prove the problem is really this other thing." etc. I am kind of happy for these answers to be spread far and wide, because the actual technical details aren't what's being examined.

The overall situation is an impossible one, and we're using the way that the candidates manage the tradeoffs to see how they work. Researching the thing as much as possible is expected when you're about to dive into a difficult problem, and we're more interested in how careful and responsible you are with important things when you actually have them in your hands.

So yeah, fuck whiteboard trivia quizzes. Give people a turd to polish, and don't expect gold to come out the other side: just look at how they hold the rag and whether they wash their hands after.
posted by rum-soaked space hobo at 2:02 AM on March 2, 2017 [1 favorite]

After they do it on the whiteboard, I ask my real FizzBuzz question: How would you test that?

Honestly, I wouldn't. If I can't trust the computer or myself to get remainders by 3 and 5 right, why should I think we'd be any better at testing?
posted by thelonius at 2:10 AM on March 2, 2017 [3 favorites]

So when do I start?
posted by thelonius at 2:50 AM on March 2, 2017 [1 favorite]

I understand that this is an industry-wide problem, but the idea that there's anything impressive about a team that is 20% women is mind-boggling to me.

Relative to what? I'll ask the question differently - what represents a "high" percentage for women engineers in a given company?

It turns out the typical tech company's percentage of women engineers (tech roles, not their entire workforce) is around 12-13%, with the highest at ~20%. Google is at 17% in technical roles, 21% in leadership - my hunch is that if you were to look at percentage of women in technical leadership roles, that number would be significantly less than 17%.

To use your formulation - it can simultaneously be true that we'd all like tech to be more representative and that you actually *should* be impressed by 20%, given the current state of play. In fact, let's take this a step farther: there are no tech companies that will remotely approach representative percentages - zero. So the question you really want to ask is (in addition to fixing this in the future via growing and retaining more engineers of all identifications): who's doing the best given the industry dynamics overall?

I submit you'll be hard-pressed to find tech companies in the US where 1) the majority of the employees are non-white and 2) the percentage of women in technical leadership roles is actually higher than the percentage of women in technical roles, in general. In fact, I challenge you to find companies in any industry where any under-represented group's representation increases at the leadership level vs. at the level of individual contributors.
posted by NoRelationToLea at 3:25 AM on March 2, 2017

When used to interview tech people my approach was to find out what the candidate knows not what they don't know. It's the same result but everyone is happier.

(Though interviewing is probably the worse way to figure out if you should hire.)
posted by lowtide at 5:38 AM on March 2, 2017 [1 favorite]

I've been in the industry for 13+ years, and have shipped many successful projects that made a whole lot of money for my employers. There's a good chance that many of you have used my software in the past year.

Whiteboard interviews give me a full-on panic attack. Like, I lose half my IQ points. Things that would be easy or common sense in a normal job situation turn up missing inside my head. My heart beats faster. I get a sinking feeling in my stomach. I develop tics. I start to sweat. I stutter and repeat myself. It doesn't matter how much "preparation" I do. When put on the spot and expected to perform, my mind goes blank and I'm overcome with dread.

It always puzzles me to see people defend the sadistic ritual of whiteboard hazing. They typically say some variation of : "Yeah, we know you don't like it. But if you can solve a problem in real life, you should be able to solve it on a whiteboard." And yet, nine times out of ten, you ask them if they've ever tried any other interviewing method, they'll tell you "No."

For an industry predicated on innovation, we are remarkably pigheaded about sticking with an interviewing style that was invented when your company only had one computer. Hiring is the most important thing a company does. It is absolutely shameful that we've resisted innovation for so long in an area so crucial.

End whiteboard interviews. End them now.
posted by panama joe at 5:49 AM on March 2, 2017 [9 favorites]

The unfortunate reality is, there are two primary reasons these shitty interview methods are so entrenched:

First, because it is easy for the interviewer. Interviewing is a skill, but one that tech companies think obviously anyone on staff should just automatically have, and so no company I've ever worked for has bothered training people how to perform an interview. In that vacuum, most people revert to what others have done; they fire up google and search "interview questions", or they just do an impression of whoever first interviewed them.

Second, because being on the interviewer side of many of these things is incredibly ego-stroking. You're basically given the power of life and death over a candidate, and making them dance to your tune. Every organization has some people for whom this is far too big a temptation, and they just can't wait to pull out some absurd trivia question or algorithm question that they themselves would never actually be able to answer if they hadn't memorized the complicated solution beforehand.

It's so bad in both these regards that even years after e.g. the big shops that actually have the time/money to analyze results abandon a particular practice, it's still finding use all over the goddamn place. Microsoft did it for 10 years in the '90s so clearly it must be good practice, right?

Right?
posted by tocts at 6:21 AM on March 2, 2017 [2 favorites]

Why is computer programming seemingly unique as a white collar profession where people pick up "Teach yourself language X in 24 hours!" or sign up for pricy boot camps in order to get in? Sure, you can't do the same with law, medicine, or other types of engineering. But what about something like accounting or actuary work, are they just less well-paying or something

Don't know about accounting, but for actuaries, maybe it's because there's an actual professional organization that does credentialing? Employers aren't going to care if you attended some class or boot camp. They only care if you are taking/have passed the credentialing exams. CS doesn't really have that kind of gate-keeping.
posted by LizBoBiz at 6:43 AM on March 2, 2017 [1 favorite]

Heisenberg's uncertainty principle holds for all discrete systems (try taking a Fourier transform of a square wave sometime...)

This is not true. Not at all. Consider, for example, a billiard ball on a table. That is a "discrete system", right? You can measure both the position and velocity of the billiard ball.

Whatever difficulties exist in taking a Fourier transform of a square wave are not due to Heisenberg's uncertainty principle, which is not a catch-all term for epistemic uncertainy of any type at all.
posted by thelonius at 6:58 AM on March 2, 2017 [3 favorites]

Whatever difficulties exist in taking a Fourier transform of a square wave are not due to Heisenberg's uncertainty principle, which is not a catch-all term for epistemic uncertainy of any type at all.

I agree that the Heisenberg uncertainty principle is over-applied. That said, Fourier transforms are intimately related to the HUP; I think the person you were quoting may have been thinking of a rectangular pulse (the narrower the pulse, the wider its Fourier transform). I'm not sure how they're relating that to the rest of the discussion.
posted by a snickering nuthatch at 7:29 AM on March 2, 2017 [2 favorites]

This thread is making me realize that:

- I was right to turn down Google interview offers since I would have totally bombed due to my lack of a CS background

- I was probably a middling-to-bad interviewer since I brought lots of preconceptions re: what made a Good Engineer to the table which were based on the Example Of Me

- Steve Yegge's blog post is a goldmine for reference material.
posted by grumpybear69 at 7:34 AM on March 2, 2017 [2 favorites]

Oh, good. I've been looking for a place where I can state my recently-acquired conviction that timed online coding tests can go die in a fucking fire. It's not as bad as standing in front of a whiteboard while someone watches you desperately trying to remember the finer points of an algorithm you haven't had to implement by hand since undergrad classes, but the constant goddamned ticking-down clock in the corner of your vision is still a pretty bad nerve-wracker.

A smaller, less hot fire is reserved for the company that sent me a take-home Python web-scraping test last week. I much prefer this style of thing, and I both finished their task and got it working in a reasonable amount of time, and felt pretty okay about it. Their only feedback , though, was along the lines of "Ehhh, well...we really want to see someone nail this perfectly, and yours was good, but not quite there. Sorry".

Thanks for your valuable and pithy insight into my process and any room for improvement, you asshats. May you mistake discarded crankcase oil for your next cup of coffee.
posted by Mr. Bad Example at 7:49 AM on March 2, 2017 [1 favorite]

Also important is making sure that interview with multiple interviewers goes well.

I turned down a position because the people who interviewed me, who would both be my managers, got into an argument during the interview. I actually had to hold up my hand and say, "Please just give me whichever version of the test now, and figure out why you have two versions of it later."

I was interviewing someone with a coworker, and everytime I would ask the candidate something, my coworker would turn to me and answer the question as if I didn't know the answer, with a scowl on his face. I took him aside after and said, "In an interview, when I ask the candidate something, it's not because I don't know the answer. I'm asking to hear them answer the question. I don't use job interviews to satisfy my curiosity about a job I'm already doing." It was almost impressively misguided of him, and he was one of the better programmers I've ever worked with.

All this to say, job interviews are hard, and I still don't know if I'll bother to go to the whiteboard next time someone asks me to. It'll be hard not to say, "That's not a good indicator of how good a programmer I am", and ask them to please figure out a different way to continue with the interview. I like the idea of bringing a laptop.
posted by tillermo at 8:11 AM on March 2, 2017 [2 favorites]

the people who interviewed me, who would both be my managers

RED FLAG RED FLAG RED FLAG
posted by grumpybear69 at 8:19 AM on March 2, 2017 [5 favorites]

Honestly, I wouldn't. If I can't trust the computer or myself to get remainders by 3 and 5 right, why should I think we'd be any better at testing?

So here's how I'd respond to that statement in an interview:

Yup, I know it's trivial, and neither of us would ever actually write something like this, let alone write tests for it. What I'm curious about though is the process you'd use to test a non-trivial piece of code, and this is a much simpler starting point than real-world code.

With a little coaching, I'd expect someone to be able to identify the need to extract the modulo logic to a separate method to be unit-testable.
posted by Ickster at 8:22 AM on March 2, 2017 [2 favorites]

My problem with "do algo on the whiteboard" problems is they are biased to hiring new college grads but they aren't great indicators for people who have been out of college for a while. NCGs are used to professors doing this exact thing to them for the last 4-8 years: "Do this homework. Memorize it. Then barf out the same thing or a slight variation onto a written test sheet".

Once you're out in industry, being able to perfectly implement a linked list or tree at the drop of a hat isn't something you need to generally do. You will obviously need to know about these data structures and know when to apply them. However, the details can be something you can mostly forget about until you are in a position where you can't reuse an existing implementation but have to implement the code yourself. At that point, you can refresh your memory by looking at references. What's more important to fill your head with? The exact details of a particular implementation of a data structure or the current design problems you have to deal with? The exact details of the algorithm can be written out to long term storage and refreshed by looking at a copy of the CLRS algo book.

Also, if you have any experience at all, you know that even simple data structures are not to be trifled with. I've lost track of the number of times I've found subtle bugs in friggin' linked list implementations written and reviewed by very smart people. So it seems entirely ridiculous to me to expect anybody to just barf out an implementation of some random algorithm on a whiteboard error-free the first time. If that happens, it is almost certainly due to luck more than skill.

No, to me, if you're going to do stuff on the whiteboard, make it a more practical, open-ended problem that will require engagement. Do they understand the general domain? If not, do they ask good questions? If they do, do they have insightful ideas? Can they explain them well? Etc. And even then, people get nervous, or flip out because they are staring at a blank whiteboard, we only have an hour, and so what conclusions can anybody really draw?

Basically, all interviewing methods are terrible, and whiteboard interviews doubly so.
posted by delicious-luncheon at 8:25 AM on March 2, 2017 [2 favorites]

So it seems entirely ridiculous to me to expect anybody to just barf out an implementation of some random algorithm on a whiteboard error-free the first time.

Of course it is. The idea is to see if the candidate can get to the correct solution and observe how they got there, not for them to write it out from rote memory.
posted by grumpybear69 at 8:48 AM on March 2, 2017 [4 favorites]

Best technical interview I had was asked to do whiteboard data modeling. Not even pseudocode, just a discussion about what objects would be needed to solve a problem, what fields those objects would have, and what methods would be necessary on those objects. Obviously, the details of that one only work for OOP, but I'm sure you could come up with an FP equivalent.

That same interview also asked me to do a presentation on a project I had developed, discussing the problem to be solved and how I solved it.

There's still some pressure involved, but the pressure was more "how do you think as an engineer" and less "struggling to remember stupid shit that you'd just look up in an API doc if you had to do it for real". I'd probably take a similar approach if I had to give someone else a technical interview now. Unfortunately, that company was a dumpster fire in every other regard.
posted by tobascodagama at 8:59 AM on March 2, 2017 [2 favorites]

I recently failed a Google white board interview which was a bit of a personal disappointment, but also quite fun and interesting. In practice, a lot of the complaints about how they work didn't appear to be true.

That said, it's a very different social situation than many people are comfortable with and very hard to practice for before the interview. Having a pool of friends who are familiar with the process does help a lot and that *is* a problem for diversity.

I guess my take away point is, if anyone ever tells you not to pursue your dream of working at Google because something about a whiteboard, don't buy it. Still, the task is skewed toward people who are like the people who already work there, so be aware of the values that underlie it.
posted by ethansr at 9:11 AM on March 2, 2017 [4 favorites]

Decades ago I used to describe the job of programmer as someone who spent all their time looking stuff up in books.

Only the source of data has changed :)
posted by twidget at 9:12 AM on March 2, 2017 [4 favorites]

Of course it is. The idea is to see if the candidate can get to the correct solution and observe how they got there, not for them to write it out from rote memory.

I used to actually enjoy them a little back when they were like that.
posted by Artw at 9:13 AM on March 2, 2017 [2 favorites]

With a little coaching, I'd expect someone to be able to identify the need to extract the modulo logic to a separate method to be unit-testable.

I was kind of kidding, kind of serious. What am I testing for? That my function can correctly determine if integers modulo 3 or modulo 5 (or both) = 0? Suppose I write a unit test that checks a few integers where that's true, and a few where it's false. You cannot establish that the function will return correct results for any integer, by just testing a few of them. It seems to me that all you can prove, with that kind of unit test, is that such a function is not known to be incorrect - if there is some integer that it fails for, it wasn't one of the ones in our test. Maybe that's good enough. At a certain point, you have to believe that the programming language implements the mod operator correctly. It does seem to me like a waste of effort to do that by writing unit tests about Fizzbuzz. So am I testing to see that I used the operator correctly? That I didn't screw up and say, return false if the input mod 3 = 0, when I should have returned true?

I believe that writing meaningful unit tests is very hard, and that a large amount of them are kind of pointless because they really aren't testing anything that could ever even break. A discussion of how to write unit tests, and how unit tests work with other kinds of testing ( a lot of people seem to think that unit tests are all you need, which seems to me to be very wrong), though, would be a great thing to discuss at an interview.
posted by thelonius at 9:15 AM on March 2, 2017 [4 favorites]

- I was right to turn down Google interview offers since I would have totally bombed due to my lack of a CS background

I feel compelled to point out that there are hundreds of open positions at Google (and other large companies) where having a CS background is either a requirement or very valuable but that are not straight SWE positions and as such the interview requirements are less daunting.
posted by GuyZero at 9:20 AM on March 2, 2017

Decades ago I used to describe the job of programmer as someone who spent all their time looking stuff up in books.

I often describe myself as a professional forgetter. Without any citations to back me up, I've come to believe that there's a medium-term memory that holds more than short term memory but isn't really useful long term. When I'm working on part of a program I have to know a lot of things about how all the parts of it work, but when I'm done I don't need to remember that stuff and I repopulate my medium-term memory with whatever other part I'm working on next. Lather, rinse, repeat. Mix in a bunch of different programming languages and database platforms and I'm always looking up little details like how to figure out how many elements are in an array and what syntax to use for joins. If somebody wanted me to whiteboard something I'd declare up front that I was only going to be using pseudocode, because come on.
posted by fedward at 9:30 AM on March 2, 2017 [5 favorites]

I just landed a new job as a developer at a small media marketing firm, and their hiring process was perfect and organic. After the initial phone interview, they reviewed my existing work. Then, they invited me in to the office and gave me an hour to solve a typical real-world problem a client may have, with all necessary information on a typed page. Satisfied with my performance, they then performed an in-person interview. Two weeks later, I was hired. The process took about two months, and was done with care. And I think that's a major difference, here.

Larger companies are trying to sort through a large field of applicants as fast as possible (most likely because turnover is already a problem.) The types of interviews they use are meant to sift through a bunch of candidates quickly to find one willing to bend over backwards enough to make a conforming employee. They embody a complete disregard for the candidates as actual human beings, and seem almost malicious in their wasting of an applicant's time and effort preparing for the process. I feel very lucky to have found a position at a firm like the one I just joined. I empathize with the people being subjected to these bad practices, too.
posted by pedmands at 9:37 AM on March 2, 2017

Only the source of data has changed :)

Companies decided to optimize for candidates' cache size instead of disk lookup time.
posted by Apocryphon at 9:39 AM on March 2, 2017 [2 favorites]

This is not true. Not at all. Consider, for example, a billiard ball on a table. That is a "discrete system", right? You can measure both the position and velocity of the billiard ball.

Well, if the variables are position and velocity, those seem like two continuous variables if we stay in Newtonian-land, don't they?

Fun little fact: the 1/f noise is (with large caveats) invariant under Fourier transform. Heavy-tailed CSP problems (ones near the phase transition) have a time-to-satisfy distribution pretty similar to distribution of power for 1/f noise.
posted by hleehowon at 9:39 AM on March 2, 2017

(fun little fact that doesn't mean anything, to be clear)
posted by hleehowon at 9:43 AM on March 2, 2017

Hey, thelonius. The occasional candidate who answers like that are the ones I really get interested in. Want a job? :-)
posted by Ickster at 9:55 AM on March 2, 2017 [1 favorite]

Thanks for your valuable and pithy insight into my process and any room for improvement, you asshats. May you mistake discarded crankcase oil for your next cup of coffee.

As someone who's been on both sides of this... it's frustrating. I know how much it burns to put a bunch of effort into something and be turned down flat, but OTOH from the employer's perspective there's way too much downside to giving people feedback. You and I want to improve and are looking for anything that will help us do a better job in the future; a lot of other candidates will take that as an opening to start arguing with the person turning them down.
posted by asterix at 10:00 AM on March 2, 2017

I really don't want a job, but I already have one!
posted by thelonius at 10:16 AM on March 2, 2017 [5 favorites]

plus you already know I read Metafilter all day
posted by thelonius at 10:19 AM on March 2, 2017 [6 favorites]

So am I testing to see that I used the operator correctly? That I didn't screw up and say, return false if the input mod 3 = 0, when I should have returned true?

Yes.

Maybe I am an idiot, but test-driven-development has made me understand just how easy it is to make tiny-but-extremely-signficant errors like that, and has radically cut down the time I lose to such errors.

"Test Fizzbuzz" is an interesting question because there's dragons on either side of it; candidates can fail by testing the modulo implementation, or can assert that the method doesn't need testing because it's trivial.
posted by Sauce Trough at 10:21 AM on March 2, 2017 [5 favorites]

I also like asking the "Test Fizzbuzz" question because I know the biggest obstacle to getting tests into a project is that lots of people don't know how to decompose things to test. (Not a criticism or smarter-than-thou observation; I went through that too.)

If someone's stuck on the question of how to test it, that's not a strike against them (although it influences the level at which I'll place them). I'll walk them through the thought process of decomposing the problem to get to a couple of testable methods.

With a lot of more junior people, we do as much teaching as questioning in our interviews, and if people respond well, it's a good sign. I've heard more than once that someone decided to accept an offer from us because of the learning experience they had in their interview.
posted by Ickster at 10:28 AM on March 2, 2017 [2 favorites]

It's funny, because I've read this whole thread, and I thought "well, clearly every kind of interview sucks, and the best thing to do would just be to hire a developer that someone in your company has worked with and can vouch for personally." And that kind of network-dependence really is a barrier to diversity, but you can see why it would be very appealing.

My other takeaway is that, while I am in no way qualified to be a software developer, I might totally crush a whiteboard interview. I'm thinking that I might look up whiteboard interview questions, just because they're fun little coding challenges that I can do during my lunch break.
posted by ArbitraryAndCapricious at 10:46 AM on March 2, 2017 [4 favorites]

that subset thing you mentioned, ArbitraryAndCapricious, sounds like fun, for sure
posted by thelonius at 10:59 AM on March 2, 2017

The whiteboard thing can certainly be done badly (and, worse, uselessly, as an indicator of competence), but I think the problem in nearly every discussion of interviewing techniques that I've seen in decades, is that people who are competent programmers, and who aren't involved in hiring or interviewing, don't really appreciate how many totally incompetent charlatans there are out there, shopping their resumes around.

At a former employer, before we implemented a more robust hiring process, we hired a guy in a Java development role who claimed all sorts of experience, but made it very quickly apparent that he didn't know how to program. Like, at all. Zero experience. I have no idea if he'd been hit on the head and forgotten everything, or if he literally ripped off somebody else's resume. But he interviewed well and basically bluffed his way through the process. It took months to build the performance case and fire him, during which he was drawing a paycheck. I'm sure he's somewhere else now, probably using that company's name on his resume as a reason for why he should be hired. These people are out there, although if you have a decent HR department most of them will never make it to an interview with you, if you're an engineer.

So yeah, companies—at least companies who've had a couple of bad experiences—are desperate to screen folks like that out. And they're willing, often as not, to implement a screen that cuts out good candidates in order to guarantee that fewer bad ones squeak through. Hence the overly-aggressive whiteboarding and other BS that companies sometimes do.

That said, the ability to talk through how you'd solve a problem isn't a terrible indicator of competence. I mean, it's pretty dumb in 2017 to care about syntactical issues that an IDE will catch, or standard library method names... but it doesn't seem unreasonable to give someone a simplified business problem and then ask them to step you through how they'd solve it. That's a legitimate thing to expect a developer to be able to do, at least in my experience; it's not just a totally synthetic benchmark for the purpose of the interview.

I get that some people don't like or do well with the on-the-spot nature of whiteboarding, but there are other people who are (somewhat understandably) very hostile to the "take home test" approach as well. I actually got an employer to try that for a time, and we got so much pushback from candidates that we actually dropped it and went back to whiteboarding. (A surprising number of people were totally fine taking a day off work for a 6-hour interview but were totally unwilling to spend an hour at home in an evening writing sample code. And in fairness I can sorta get why it's off-putting; it seems one-sided.)

As a candidate, honestly the best thing you can do for yourself in the hiring process is to have code samples online (GitHub or similar), and put that prominently on your resume. That way you're much more likely to end up discussing and stepping through code you wrote at your own pace, rather than trying to solve and explain that solution at the same time. But for people who don't have code samples available, which is definitely the majority of non-web programmers that I've worked with, particularly people who aren't right out of school and may not have rights to things they've written recently, then you're a bit stuck.
posted by Kadin2048 at 11:43 AM on March 2, 2017 [2 favorites]

Yeah, "put code on github" is a non-starter, for a variety of reasons. For one thing, I'd have to get the OK of my legal department, because due to the state of our shitty industry practices they by default have rights to anything I produce (or at least believe they do, and may choose to make my life hell legally if they think I've done something of value and given it away). For another, even if they OK'd me putting such work online, they'd certainly never give me time during the workday to produce it, so now we're back on, "if you want a job, please spend what little free time you have after developing software all day to do it all over again but without getting paid."

I have zero problem with, "here's a business problem, talk me through how you'd approach it". I have massive problems with, "whiteboard some code to reverse and invert this linked list of binary trees". And, for me personally, I'd much rather do something take-home. Let me show you what I can do in an environment where I'm comfortable, and I'll be happy to explain in detail all the thought processes that went into it.
posted by tocts at 11:58 AM on March 2, 2017 [5 favorites]

how many totally incompetent charlatans there are out there, shopping their resumes around.

The interview failures that have really haunted me have been the toxic people -- the narcissists, the teflon-coated blame shifters, the zero-sum people who only win when people lose, the stubborn new grad who regards every disagreement as a personal affront, the lazy architect who steers every conversation towards how poorly our organization is modelled and uses that as an excuse to never contribute business value...

All of these people were competent programmers -- the new grad was super smart and I actually learned a few cool shell and git tricks from them. The architect had a lot to offer too. But they were not people who reciprocated good faith.

One toxic person can screw up an entire team, and it's way harder to fire someone for being toxic than it is to fire them for being bedshittingly incompetent. I've assembled cases to fire incompetents. It's a pain in the ass and it takes awhile, but it's at least somewhat objective and in both cases I was satisfied that they'd gotten a fair shake from me.

So, nowadays, when I get a twinge in an interview that I'm dealing with a toxic person, I dig on that twinge and if it doesn't go away, I'll do whatever I can to keep them out. I feel conflicted about that, because I think that the critique of "culture fit" interviewing has some validity. But having suffered through a number of toxic people, I feel entitled to gatekeep people who make my spidey-sense tingle.
posted by Sauce Trough at 12:59 PM on March 2, 2017 [4 favorites]

Mr. Bad Example: "Oh, good. I've been looking for a place where I can state my recently-acquired conviction that timed online coding tests can go die in a fucking fire. It's not as bad as standing in front of a whiteboard while someone watches you desperately trying to remember the finer points of an algorithm you haven't had to implement by hand since undergrad classes, but the constant goddamned ticking-down clock in the corner of your vision is still a pretty bad nerve-wracker.

A smaller, less hot fire is reserved for the company that sent me a take-home Python web-scraping test last week. I much prefer this style of thing, and I both finished their task and got it working in a reasonable amount of time, and felt pretty okay about it. Their only feedback , though, was along the lines of "Ehhh, well...we really want to see someone nail this perfectly, and yours was good, but not quite there. Sorry".

Thanks for your valuable and pithy insight into my process and any room for improvement, you asshats. May you mistake discarded crankcase oil for your next cup of coffee."

Epistonyrical?
posted by Samizdata at 1:00 PM on March 2, 2017

Having been on both sides of the equation, I think I'm coming close to the general opinion that if a technical interview isn't somewhat about pairing, you're probably doing it wrong. The bad common denominator between all the toxic interview styles is that they try to evaluate a candidate's skills in isolation.
posted by ethansr at 1:31 PM on March 2, 2017 [3 favorites]

Epistonyrical?

No, that would have been if I'd actually followed through on my momentary impulse to change the main file in the Github repository I pointed them at to "suck_my_ENTIRE_dick_you_pigfuckers.py".

They almost certainly wouldn't have seen it, having moved on, but you know...catharsis.
posted by Mr. Bad Example at 1:49 PM on March 2, 2017 [1 favorite]

(A surprising number of people were totally fine taking a day off work for a 6-hour interview but were totally unwilling to spend an hour at home in an evening writing sample code. And in fairness I can sorta get why it's off-putting; it seems one-sided.)

Yeah, I think a big problem with the "take home" interview is that if it's the second step after a phone screen, you're not going into their office, seeing the environment, asking questions, taking the temperature of the interview, meeting staff, etc. If interviews supposedly "go both ways," why am I learning nothing about you? It's a lot to put focused effort into a programming assignment when you're not even sure it's going to be evaluated, at the end of the day. An in-person interview might be all day, but at least you're definitely getting some attention, and learning something about the internals of the company.

I think I'm coming close to the general opinion that if a technical interview isn't somewhat about pairing, you're probably doing it wrong.

Strong agree.
posted by stoneandstar at 3:01 PM on March 2, 2017 [4 favorites]

Yeah, I think a big problem with the "take home" interview is that if it's the second step after a phone screen, you're not going into their office, seeing the environment, asking questions, taking the temperature of the interview, meeting staff, etc. If interviews supposedly "go both ways," why am I learning nothing about you?

To play devil's advocate a bit, I've definitely had take-home coding assignments that have made it obvious I don't particularly want the job. If your data science take home involves d3 and angular on top of some trivial analysis, you are both not respecting my time and suggesting it's not a job I want, if it's at all representative of the work. That sort of work floats some people's boats, but it'll still take them several hours.

I think the trivial take home problems are dumb, but I'm more inclined to cut them some slack. It'll filter out the totally hopeless people and takes less than an hour of someone competent's time. And, having had to come up with a take home assignment, it's hard to balance "at least mildly interesting" with "not time consuming". Then again, we hired someone who "failed" our take home by completely missing the point of what we were asking. The company's recruiting process left something to be desired, so he'd been invited to an in person interview before we even saw the take home response. On the day, it was obvious we should hire him.
posted by hoyland at 4:32 PM on March 2, 2017

oh you fuckers I deleted this long comment because I left the page to look something up!

I quit the tech world and now program exclusively for myself to build things I need for my new profession.

I could easily write quick sort on a white board and I'm bummed that there are so few women engineers at tech companies. I'm also sometimes bummed that I am not a woman engineer at a tech company. I do secretly believe I am slowly and steadily building something awesome in my spare time. Hehe.

I wish it was all: Hi, I'm goneill! I'm off to be a senior engineer at google!

Alas, I was recently recruited to work at an evil tech company in a non-technical role. They made sure to let me know that I should not have any technical aspirations as I am 'too old' to be one of the 'tech guys'.
posted by goneill at 6:48 PM on March 2, 2017 [1 favorite]

Personally, I like the take-home assignments. I guess I'm biased in that if a company gives me an actual on-the-computer programming assignment, I usually get the job. But the thing is, a programming assignment tests the candidate's ability to write a program that works and is understandable by other people--that is, the actual work of programming.

On the other hand, a whiteboard exercise tests the candidate's ability to come up with an efficient algorithm under time pressure. That never happens during the actual work; you just Google for it and that gets you the answer. (Or, if you're doing something genuinely new or obscure, you think about the problem for a day or two and implement the best solution you can come up with.)

And that assumes that the whiteboard problem is actually something a competent programmer can be expected to solve and not some obscure problem that was solved over a five-year period in the fifties (e.g. cycle detection). In that case, it becomes a trivia question.
posted by suetanvil at 7:48 PM on March 2, 2017 [1 favorite]

That's what started happening, in my field at least, which is web development. It used to be whiteboarding involved working out how you'd approach some question in pseudocodecand was very chatty and fun, and then at some point I think people started getting anxiety about being real programmers and it all became about optimizing algorithms, and at that point you better have the fucker memorized because you don't want to have to come up with a textbook quality sort or whatever off the top of your head with some dude breathing down your neck.

The pseuocode went away at some point too, so they're wanting actuall code with all the semicolons and everything and no room to fudge if you can't remember some obscure language detail.
posted by Artw at 8:36 PM on March 2, 2017

I've only had one programming interview, and it was mostly a conversation about what sort of work they do and what I've done. I got 24 hours to put together a project consuming and presenting data from an API they kept alive for that specific reason, and sent them the relevant files.

They checked it was above board and displayed an eye for detail, error handling and all that.

Good experience all in all.

I've only encountered situations twice now, two years on, that have warranted a harder look at what sort of data structures we use, much less sorting methods. Whiteboarding algorithms can't have much relevance to most day-to-day SWE.
posted by flippant at 8:56 PM on March 2, 2017

Thinking back to when I was hired for my first job out of college (1995), I think the only reason I made it through the interview is that the senior programmer who was overseeing the programming test part was called away in the middle. I don't recall if that meant I was just left on my own for a long time to figure out what I needed or if he just never came back to finish that part of the interview.

Several years later, moving on from that job, I interviewed at Blizzard and absolutely tanked the programming-on-paper screening. For some reason I used pen to do it instead of pencil. They asked why and I didn't have a reason. (My previous job had been at a sister company. I was the lead on a project that used the core library developed at Blizzard, and I had written full documentation for the library and shared it with them before I had left that job.)

At a later job, the worst experience I had with a developer that I hired was someone who wrote O'Reilly books on the technologies we used.

I don't know what lessons I'd draw from any of that. Only that I hope I don't find myself in the position of ever having to go back back to interviewing for programming jobs. I'm not a brilliant coder, but am very good at grinding it out. I know how to ship. I'm not sure how easy that is to discover or show through an interview.
posted by jimw at 11:49 PM on March 2, 2017 [2 favorites]

Why not just pay people for a day of their lives, have them come in, sit with the team they might be working for, ask questions, mention things they would do, etc...

All that after a bit of screening, of course, but the main interview would be a paid experience of interacting with the team that you would eventually work on. Because you're paid, you can be asked to do anything up to and including actual work on your interview day. They can watch how you set up your dev environment, what questions you ask, how you find information, and all of the real indicators of how effective you are at programming.

Also, for people looking for a job, the money will come in handy, and will probably be a drop in the bucket operationally for the organization.
posted by tillermo at 7:15 AM on March 3, 2017 [2 favorites]

I suggested the "pay for a day" model once, and the HR / compliance people freaked out. Apparently (some people feel that) doing that in the context of a job interview creates the risk of an unintentional employer/employee relationship and unacceptable levels of both tax paperwork and legal exposure. I haven't looked into the underlying law, I just took HR at their word because it was clear it wasn't a battle I was going to win. Maybe it depends on state law, or maybe you get a really good contract drawn up and signed ahead of time, because I've certainly heard of companies that do it. It seems like the sort of thing you can mitigate with a well-written contract...

There's at least one company I know of locally that hands out Amazon.com giftcards at the conclusion of group interviews to people who aren't making it to the next round. I haven't decided if that's cheesy or not.

I mean, it'd suck to be in a group interview and get cut before lunch, but being given $200 in Amazon bucks wouldn't make it suck more...
posted by Kadin2048 at 1:26 PM on March 3, 2017 [1 favorite]

On the lighter side, Kyle Kingsbury on Acing the Technical Interview. The William Gibson-styled follow up in the comments is not to be missed.
posted by fragmede at 9:49 AM on March 20, 2017 [3 favorites]

« Older Max Martin Interview | RTFA Newer »

This thread has been archived and is closed to new comments

MetaFilter

No hashtag. Yet.
March 1, 2017 2:54 PM Subscribe

Tags

Share

No hashtag. Yet. March 1, 2017 2:54 PM Subscribe

Tags

Share

No hashtag. Yet.
March 1, 2017 2:54 PM Subscribe