5 ms·

I'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 p

by louthy 10y ago

I'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 ago
I'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 ago
  I 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.
noir_lord 10y ago
https://news.ycombinator.com/item?id=13816370 https://news.ycombinator.com/item?id=13816370 it seems like we arrived at a similar approach. I wonder if there is a cultural component to it, I'm also in the UK. Also interesting field you are in, that is tangential to something I'm contemplating as a future project :).
bsvalley 10y ago
I see that you're located in the UK. In Europe the hiring process is much different than in the San Francisco Bay Area for instance. Here it's crazy, we don't hire software engineers, we hire "developers" instead, which tells you what people are looking for. We love hackathons and we believe developers dream about code all night long. Since people are coming from Asia, India, Eastern Europe, etc. the environment is interesting. People think differently in general about software development. It's all about hacking rather than designing or thinking high level. Being smart here means being able to crack tough algorithm problems. This is a very old school way of thinking, it reminds me google back in 2000-2005.

by louthy 10y ago

brutus1213 10y ago

I'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 ago
I 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.

noir_lord 10y ago

https://news.ycombinator.com/item?id=13816370 https://news.ycombinator.com/item?id=13816370 it seems like we arrived at a similar approach. I wonder if there is a cultural component to it, I'm also in the UK. Also interesting field you are in, that is tangential to something I'm contemplating as a future project :).

bsvalley 10y ago

I see that you're located in the UK. In Europe the hiring process is much different than in the San Francisco Bay Area for instance. Here it's crazy, we don't hire software engineers, we hire "developers" instead, which tells you what people are looking for. We love hackathons and we believe developers dream about code all night long. Since people are coming from Asia, India, Eastern Europe, etc. the environment is interesting. People think differently in general about software development. It's all about hacking rather than designing or thinking high level. Being smart here means being able to crack tough algorithm problems. This is a very old school way of thinking, it reminds me google back in 2000-2005.