3 ms·
My comments here are relevant only to my hiring experience, which is decidedly un-FAANG: small companies you've never heard of, teams of 3-5 on average but alwa
by pc86 5y ago
My comments here are relevant only to my hiring experience, which is decidedly un-FAANG: small companies you've never heard of, teams of 3-5 on average but always less than a dozen or so, for the entire company. But I have a lot of problems with using any programming tasks in an interview.
My biggest problem is that it doesn't have any correlation to the actual job. Coding on a white board, under stress, with multiple tech and non-tech people watching you, with a sub-30 minute time cap, with no access to the internet or debugging tools other than an interviewer who may or may not just be trying to look smart to the other people in the room, is almost entirely the opposite of what an SDE does day-to-day.
I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it. Solving programming "puzzles" is completely different than day-to-day work, especially at small non-startup shops, where you're doing line-of-business stuff and maybe a new project every 5 years. It's maintenance 99% of the time. You don't need to know how to reverse strings to implement a recursive sliding window function.
This is how we've done hiring at my current company so far and it's worked out better than any of the places I've been that used puzzles or language trivia.
1. As always, lean on your network. 1st- and 2nd-level connections will already have a lot of previous vetting completed.
2. Interview primarily for team fit. You can teach people technical details easily if they're otherwise qualified. You can't teach someone not to be an asshole, and having an asshole on the team will drive away good people who don't want to deal with it.
3. Have a very clearly communicated probationary period. We use 30 days but honestly 2-3 weeks is plenty. If things aren't working out, cut them in this period.
4. As part of #3, check in a lot more than you otherwise would during this time. We do a management one-on-one every two weeks, so we'll do daily technical one-on-ones during the first week or two of onboarding. We've let one person go during the probationary period because of performance and without these meetings it would've taken weeks longer than it did.
5. Have onboarding. Docs, calls with a defined itinerary, whatever. But don't just drop people into the thick of it if you're doing this type of interviewing.
6. Actually request references and talk to them. You'd be surprised how candid former managers will be about someone's previous performance, even when they're not supposed to be.
- Aeolun 5y ago> You don't need to know how to reverse strings to implement a recursive sliding window function. I guess I generally agree with the sentiment of your post, but if you have issues reversing a string (brute force) I’m not sure how you’d ever get to sliding window functions.
- jmaygarden 5y ago> I've worked with people who were fine programmers and when I brought up FizzBuzz had no idea how to solve it. I would not categorize FizzBuzz as a puzzle. It is one of the most straight-forward ways to test for an understanding of iteration and selection. Those are fundamental building blocks that all programmers must know. Your point about anxiety under the unusual pressure is valid. However, I personally find that to be a useful datapoint in the interview process as well. This is especially the case for a startup with time pressures or a role that may interact with customers. Otherwise, the onus is on the interviewer to set the applicant at ease.
- IggleSniggle 5y agoIt's interesting, because I do my very best work (and am happiest) in an environment of time-pressure, but something about the interview setting causes me to freeze up, lose my tongue, and lose my brain, all at once. If the question is very very easy, the effect is far worse. I've been on the other side of the interview process, and knowing how it might appear just makes this feel all the more traumatic. The brain focuses on the scenario of the interview, instead of the scenario of the question at hand. I've had successfully interviews where everything flows, and I've had awful interviews where my head inexplicably seizes up. All I'm saying is that the anxiety of interview pressure has very little in common with the anxiety of time-pressure, as far as I can tell. I would take it more as a signal that a person should not be put into negotiations (because that's what an interview really is), rather than that they do not perform under time-pressure.
- arp242 5y agoI'm never anxious during job interviews, or anything else really: I just take things as they come and I'm fairly stable under most pressures. Last week I was doing a video interview, and at the end they asked me to solve a simple problem and they were going to record it. I felt an incredible pressure to do it right and fast, which lead to basically screwing it up on the first attempt on account of not actually reading the question carefully (or at all really; it was a piece of code where I had to fill in some things, and I misunderstood because I barely skimmed the comments in the perceived pressure). I then a had state of near-panic where I almost just ended the call, from which I just barely managed to recover to stumble towards a solution. It's the closes I've ever come to an anxiety attack by far, which was an entirely novel experience and very much unlike me. I did end up solving it in a reasonable amount of time, but the way I got there was ... roundabout. The question was to square a value in-place with a pointer: not very hard at all, literally one line of code. In the moment however I was genuinely doubting if I even knew what "squared" means; I really blanked in a way I don't recall ever having done before in my life :-/ I don't know why, but being watched by someone judging you just makes a huge difference for some reason. I've actually never had to write code while someone was watching before in an interview setting (plenty of verbal questions, "take-home tests", and the like, but never any actual code writing). I had my second interview already with the third planned, so I guess I didn't do as dramatically bad as I felt I did after the interview, but still... If it had been the wrong day I might have outright failed. It was a very weird experience and I'm not yet sure what exactly to make of it since it was fairly recent, but I gained some new appreciation on how some people might flunk simple interview questions I didn't have before.