4 ms·
I like your first point, though your 2nd and 3rd points tell me you haven't applied for a while :) They've all adopted the google model, small or big companies
by bsvalley 10y ago
I like your first point, though your 2nd and 3rd points tell me you haven't applied for a while :) They've all adopted the google model, small or big companies it doesn't matter. You start with a 45 minute technical phone screen (algorithm/data structures), sometimes a second tech phone screen, an onsite of at least 5 hours with at least 3 to 4 45-minute technical screens (algo/data structures) as if it wasn't enough... let's repeat the same exercise 10 times to make sure you'll fail at least once... Finally, an additional "culture fit" 45 minute chat with a director or VP at the end of the onsite. An additional home assignment is given to you when they have too many candidates to chose from.
So it's not just about skipping companies who ask stupid questions and definitely not about working only one or two evenings on algo stuff. Trust me I've been through this process recently with 15 companies! I worked for a bunch of top companies in the past and I can attest, it is extremely painful. They want robots now and interviewers are lazy and annoying. How naive I was when I carefully selected the only company and job I was interested in at the beginning. Then I went through the process and got smashed in the face. I had to align another 20-30 companies to get at least 10 to 15 tries, then an offer. An offer from choice #15?? That sucks... it's 2017 and things have dramatically changed.
- noir_lord 10y agoThat sounds pretty awful. I've been programming for half my life and I'd fall over on that stuff.
- louthy 10y agoI've been programming 3/4 of my life and I'd fall over on that stuff. I'm a CTO of 12 years and I'd fall over on that stuff. I have a successful open-source project [1] which is all algorithms and data-structures, and I'd fall over on that stuff. At some point interviewers must get it, that these artificial test environments bear no relevance to how we write code in the real world, and putting these false constraints on a candidate just creates stress, and in no way communicates their competence. Luckily for me (as an interviewer) I do get it. And I suspect that's part of the reason why I've not had a developer leave my company in the 12 years we've been running. I do a first interview, which I keep super chilled and chatty, just trying to get the candidate to relax. I'll focus on projects on their CV, asking high-level questions. Again, no stress. Then if they say anything interesting about a part of a project I may drill down a bit more to make sure they understand the subject they're talking about. Which is slightly more stressful, but if they're competent, they'll know. I very rarely go into algorithms and data structures. It'll usually be if I'm concerned about a junior dev not having enough CS knowledge. I then send them an email post interview (if I think I want to see them again for the second interview). The email will have a link to a partially complete project, I ask them to finish it based on a written spec. It shouldn't take more than 45mins - 1hour. The request in the spec is intentionally a bit obscure. I put at the end of the spec that "If you have any questions or problems, please email me. You won't be marked down for this." The obscureness of the test is to see who emails me to ask for help. That for me is a real positive sign. So I'm trying to create a real world test: * A spec to follow * Programming in a comfortable environment * Access to dev resource (Google/Stack Overflow/Their friends) * Access to their boss for advice And to avoid anybody trying to game it and blag their way with code that they didn't write, I quiz them about their decisions in the second interview. It works amazingly well. My dev team is something I'm super proud of. A good team of people who collaborate well and believe in the product. No hierarchy or in-fighting. It's a happy place to be. So I endorse this method :) [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext
- brutus1213 10y agoI've been on both ends recently. It makes no sense. I had one start up invest in 4 phone screens before deciding to pass on me. I was stunned they passed because I aced all of their phone screens (which were not trivial btw). As an interviewer, I have been giving candidates questions slightly above fizbuzz and they keep failing! And this is candidates who have written multiple years of professional programming experience on their resume. I think there are a lot of low quality software devs out there. In an attempt to filter them, people are putting insanely high bars - makes no sense!
- deathanatos 10y ago> these artificial test environments bear no relevance to how we write code in the real world I keep hearing this, and perhaps I'm not part of the problem. But at a prior company I worked for (which was quite good), our go-to phone screen was "implement min()". This screened an absolutely staggering (to us) fraction of the candidates. I don't see how asking someone who claims to have years of experience in engineering write a for loop is stressful, and anything but real world; I write for loops all the time, and I don't consider that the hard or core part of my job. (One of our followup questions, usually on-site, amounted to: "can you write a for loop that involves two pointers?"; too many candidates would give them absolutely terrible names like "i" and "j", and not be able to mentally maintain what they actually meant, or were for.)
- louthy 10y agoI think implementing min is slightly different to remembering the rotation algorithm for an AVL tree (for example). But still, my point wasn't to not test, it was to allow the candidate all of the tools of their trade whilst being tested. 'Air coding' (a phrase I use for white-board/paper/verbal coding) is not a good indicator in my humble opinion.
- merlincorey 10y ago> our go-to phone screen was "implement min()". This screened an absolutely staggering (to us) fraction of the candidates. I like to ask people to "implement reverse()" with similar filter results.
- acheron 10y agoThis is not really true everywhere. I'd be really surprised if I encountered an interview like that. I think it's just a weird California thing, kind of like "thinking In-n-Out is better than Five Guys", or "driving your state into bankruptcy".
- merlincorey 10y agoIn-n-Out is way better than Five Guys. The rest of what you said, we have no quarrel!
- deleted 10y ago[deleted]
- eikenberry 10y agoWhere do you live? I started a new job a year ago and took my time looking. I spent a good 6 months interviewing at probably 20+ places and none of those places had a lame tech interview... None of them. They were small to mid-sized companies all over the country (I was considering remote work as well). So I think you are overstating it a bit.
- GFischer 10y agoI guess it depends on the position, but it's not all of them - I know for a fact that at least a few large SF-based companies haven't adopted the algorithms/data structures bullshit. They do have tech interviews, but it wasn't an "Engineering" position (they were for Technical Consultant/Technology Consultant type roles) so maybe that's why they don't drill you in algorithms (you ARE expected to code though).