Interviews

So I tried just writing in paragraph format, but I wound up talking all over the place and answering none of the questions in the writing prompt. Therefore, I decided to structure my blog to directly answer the questions asked in order to stay focused. Sure, it's less of a blog-y format, but whatever, I don't like writing blogs anyways.

What has your interview process been like?
So I've actually done only a few interviews. I thought that was kinda weird, until I read Joel Spolsky's "199/200 Applicants Can't Code" article - linked in the "Why Can't Programmers.. Program?" article. He hits a lot of topics, and at one point says this: " I know lots of great people who took a summer internship on a whim and then got permanent offers. They only ever applied for one or two jobs in their lives." That's me. I applied for a summer internship at ViaSat, got a permanent offer, and was happy with it. So I've done very little interviewing.

I've been in 4 interviews, ever. The first was for a minimum wage job at Legoland. (The fact that I even count that shows that I don't do this much). The next was a technical phone interview for the ViaSat internship, then a mostly general interview with Altera, and finally a practice technical interview with professor McMillan (for Software Engineering). So 4 total, but none of those really count. The ViaSat one was just an internship, and only over the phone. Altera, I already had the ViaSat job, so I wasn't hugely invested, and they wanted more of a hardware guy anyways. The Software Engineering one was great, but just practice.

Of those, my favorite by far was the technical interview with McMillan. Maybe just because he explained exactly how I did and what every part of the interview was supposed to be doing. There was the use of a whiteboard, but it was "draw out a diagram of how you would build a program to these requirements," not "invert a binary tree." That was my least favorite part of the interview, but it seemed fair.

What surprises you?
One thing is that I usually feel pretty terrible coming out of an interview. I tend to evaluate myself worse than the person giving the interview does. So I'll come out of something thinking that I failed it, then get an offer. On the practice one, I thought that I did just ok, but the professor says I nailed it, somehow. So I guess the idea that anyone would want to hire me after an interview surprises me.

What frustrates you? 
Deep technical questions about C. No, I don't know what the volatile keyword means, I never needed to! But also I don't really talking about myself or group projects either, so I don't know what I want. I guess I don't like the whole process. Writing code is ok, but I feel like I'm making some terrible mistake the whole time. And I've only ever been asked to write really simple programs, none of this Google whiteboard "invert a binary tree" nonsense.

What excites you?
Getting a question right? But during the interview, they almost never congratulate you on that. It's always on to the next one. So really the only exciting part is hearing back?

How did you prepare? 
I read my resume and tried to guess what types of questions they'll ask about it. I mostly focused on group work stuff. I think the most I ever prepared was for the phone interview, and even that I think was only a few hours. (I prepared completely wrong, I focused on group stuff, figured I had the technical stuff down, only to be asked about the "volatile" keyword in C, and lots of stuff about C++ that I was really rusty with. Goddamn polymorphism. Why the hell is it called that? The name makes no sense. We're computer scientists, we don't have to use Greek naming, we can call it ThatThingWhereYouCastTheChildPointerToItsParentAndItJustKindaWorks.) Anyways. I probably should have brushed up on Polymorphism.

How did I perform?
Legoland: got the job! yay!
ViaSat Internship: got the internship! Yay!
Altera: Never heard back. Oh well.
Professor Practice: I did really well! Yay!

What do I think of the "general interview process?"
There's a lot of different processes. McMillan's was great. Started with weeder C questions, then to data structures, then memory discussion, then to mildly challenging C function, then to writing a program block diagram on the whiteboard. All of which seemed fair, and each of which evaluated a specific part of what I knew. The ViaSat one was I think a little too technical? I don't know how I passed. Maybe I was supposed to fail them all, but I managed a few and so that was great? The Altera one was meh. Mostly general stuff, with a really basic function at the end (either Fibonacci or factorial). The Google whiteboards sound terrible; everything I hear says "read the entire cracking the coding interview textbook if you even want a chance," which sounds like a pretty bad way to filter out new hires.

One thing that is mentioned in a few articles is the idea of having someone work with someone else in the company for anywhere from a day to a few weeks. That sounds like a much better kind of way to filter out new hires. I feel like it's basically impossible to judge a person from that snap encounter of an interview, but actually doing work means you can get a sense what the person will be like. Maybe have a basic "weeder" interview to make sure the person can actually write code, then put them on a team for a day to a week.

Is it efficient?
In the sense of money invested vs. money at risk (for hiring the wrong person), I'd say yes. If FB is paying >100k per year for each employee, it makes sense to invest a lot up front and try to make sure you get the best person for the job. If you hire the wrong person, it could be difficult to lay them off, and that's a waste of 100k yearly.

Is it effective?
Maybe. It seems like Google, FB, etc. really do get the "best" talent--or, more likely, a a subset of the best. The problem is that the subset of the "best" that they select probably suffers heavily from the People Like Us problem.

Is it humane?
Ya, probably. The ones I have been in, definitely. (At least, no more inhumane than finals). The whiteboard algorithm problems described at Google sound cruel, but I wouldn't say they're inhumane.

Is it ethical?
I would say not. As one article mentioned, selecting only those you see as an absolute perfect fit maximizes for "People Like Us" bias. One possible effect of this may be the gender gap in our industry. And passing up perfectly qualified people is unethical, one article even mentions that an "injustice" may have been done.
But there are also ways to do interviews that are ethical. The industry right now is tending away from them because the market is apparently on fire. It sounds like the best way is coding with a future coworker for a day or more. However, interviews that ask structured questions can work as well, as long as they try to judge them as objectively as possible. Also, I think the worst thing to do is to throw the interviewee into the "algorithm lottery."