4 ms·
I see one aspect of this trend of asking programming questions that require a lot of memorization: We have had for the past ~10-15 years people in the workforc
by Zelphyr 8y ago
I see one aspect of this trend of asking programming questions that require a lot of memorization: We have had for the past ~10-15 years people in the workforce (and thus acting as interviewers) who went through a public education system where heavy emphasis was placed on passing tests that required a lot of memorization.
I'd be interested to know how many of these interviewers actually think they're able to identify a solid candidate this way? Not to mention, are they even factoring in how many people don't test well but are otherwise superb software engineers?
Ultimately it seems like there is a soft element to interviewing that is being tossed out now, which is: do I think we can work with this guy/gal? Are they someone that can become part of our team on a personal level? Can they get good work done? Fizz Buzz can't tell you that. What can tell you that is experience. It's a hard-to-put-your-finger-on-it X-factor that I think companies think they can ignore.
- paulddraper 8y ago> It's a hard-to-put-your-finger-on-it X-factor that I think companies think they can ignore. Devil's advocate: It's also the thing that is very hard measure without bias, unless you do something reductionist like total years of experience.
- alchemism 8y ago> Ultimately it seems like there is a soft element to interviewing that is being tossed out now, which is: do I think we can work with this guy/gal? A colleague offered this simple heuristic for the soft side of [the] interview: "If they are going to be equal or junior teammates, I ask myself, 'Would I feel comfortable sitting in a conference room with this person and hashing out a design or troubleshooting a problem for two hours?' If I'm evaluating someone who is going to be senior to me, or my direct boss, I ask myself, 'Would I feel comfortable following this person's technical instructions if they handed them to me in a document?'" In my personal professional opinion, this measure is more useful to an engineering org. than any "Stump the Chump" style technical-trivia screening.
- nybblesio 8y agoSo much this. I've been programming for 30+ years. My brain only has so much cache space and it dumps frequently. Asking me questions that clearly are testing my ability to hold large amounts of data in my meat computer isn't testing my ability to design and write computer programs. Sure, I'd love to have a "mind palace" like Sherlock. Alas, I do not. I often admit this as early in the interview process as possible to avoid wasting time.
- bunderbunder 8y agoIf anything, it's testing your ability to misdesign computer programs. I hate working on software that was written to be read by an audience with perfect recall, because, as a human, I just don't have that. Give me code that assumes I have the memory of a goldfish, and can't keep track of anything that isn't right in front of my face. I'm pretty sure that's what half of Dijkstra's papers were trying to say, weren't they?
- nybblesio 8y agoAgreed and Knuth's Literate Programming. Our industry is caught in the event horizon of the black hole named, "cargo cults".
- bunderbunder 8y agoThe black hole that gets me is a love of complicated things. It seems like, given a choice between two different things that are equally capable of solving the problem, 9 out of 10 hairless apes will pick the one that has more switches and knobs. I haven't tried literate programming, but one of the things that entices me about it is that my instinct says that it's a vaccine against unnecessary complexity. If you can't express it comprehensibly in both English and code, there's likely an easier way to do it.
- city41 8y agoAt a previous company we interviewed by giving the candidate a choice of a dozen or so problems. All of medium-ish difficulty. Then we together sat at a pairing station and paired on the problem for 2 hours. Candidate can use the internet and anything they want really, as close to real coding as we could make it. Two hours was enough to get into the problem a bit, and get a feel for what they would be like to work with and a feel for how they approach problems. Still not perfect, but by far the best interviewing method I've found.
- chrshawkes 8y agoYou sit next to the guy the whole time? Eat lunch next to him too? Having some stranger over your shoulder is not real coding either imo.
- city41 8y agoWe had pairing stations, so usually sat at 90 degrees. Each person gets their own desk, monitor, keyboard and mouse. Also this company was huge on pairing, so it was also an indicator of what working there would be like.