5 ms·

This article is full of opinions, and brings no facts to the table. The author does not mention his experience interviewing or hiring people, and the whole piec

This article is full of opinions, and brings no facts to the table. The author does not mention his experience interviewing or hiring people, and the whole piece reads more like a rant. > When an accountant is in an interview, they're not asked to multiply on-the-spot in their head what 485 x 761 equals because "you have to be good at math to be an accountant" This is an ignorant statement. Accountats don't have to multiply things in their head day to day. Yet developers do need to code, day to day. I'm a hiring manager and the reason people code on interviews is - well, after joining a company, the first few months they _will_ spend a good chunk of their time coding. And the companies I worked at, who dropped the coding interview always regretted it, through mishires. People who could code, but were not very good at it. E.g. their code was sloppy, incorrect and they needed considerable mentoring and coaching to write code that worked. As senior developers. The other reason is to even the odds. 70% of people I've seen hired did not have public Github profiles or code they could show. The people who complain about "why can't they just look at my portfolio" and (potentially rightfully) conclude that they're amazing developers don't realize that this approach would result in more bias for hiring this group of people. Good luck maintaining a fair hiring bar this way or hire diverse candidates. This is why the coding test exists in most places. It's to test for something that you're expected to do from day one and to even the bar that people need to jump through, for everyone. I'd love to hear what OP suggests to replace the coding tests with - a chat about past projects, then make an offer? And what do you do with the people who don't have these things to show?

sparsely 6y ago
Recruitment for accountants etc often includes a technical skills component, I don't know why he thinks it doesn't.
- peschu 6y ago
  I used to work as a finance controller and I really never had to show a technical skill in an interview... And never saw it/heard from colleagues in finance, maybe in international accounting(which is more rule/law based) they ask if you know some stuff about this and that but nothing serious...
  - x3n0ph3n3 6y ago
    CPAs go through a test more rigorous than the bar!
Fire-Dragon-DoL 6y ago
To be fair, a coding interview would address the "can he code at all" question, but not what you mentioned: sloppiness, incorrect coding and needing mentoring
- sbergot 6y ago
  I usually try to detect things like: "do you know lists and dictionaries?". Also very basic abstraction design and basic communication skills. This works well with juniors because we mostly code business logic. It does not work at all when trying to recruit a senior. I am still clueless about that. I have at least two recent cases in mind of a senior hire that lead to catastrophic results. People that new how to present well at a superficial level but did really poorly once they had non trivial stuff to do.
  - peschu 6y ago
    general developer: I don't know why people want to find out if a person can code? ... I assume that a person can code ...(if not you will see very soon) I mean it's not about writing "hello world". If the person is not dumb, you won't find out in an interview if someone can really code. (repos are much better for that, but can be deceiving) "We have a 3 month probation period and if something is really not true it will have consequences. I'm crystal clear about that." I mean we are all humans, but there is also a contract with money involved. I have to look out for the company and it has to be fair for all the other team mates/colleagues too. If you hire some "faker", without consequences it will destroy the whole team balance. (Additionally there is a "meet the team" to address the consent process). From my experience, technical people have a low tolerance for people which can only talk...(in a technical team). So it does not mean you are safe if you can make it through the inverviews with tricks. (it may seem a bit hard, but I don't like the general acceptance of "lying" or superbeautify ^^ in the application process) And then I talk about what we are working on and how we are structured. So the interviewee also gets an impression what the day to day work will look like. What I really want to see, is the ability to solve problems. Because this is our real job. We are solving problems(with code). So I ask questions you can not solve in 5 minutes, but you see how someone approaches a problem. Is the person collecting intel about conditions and constraints or is he/she immediatly starting to code etc. ... For that I generally take real problems we had and we already found a solution. And sure I tell them, that it is not possible to find a solution now, because many interviewees are "conditioned" (or used to) to give you immediate solutions. Else they would panic or getting frustrated. In general ask a question: Why should I want to barbecue(or embarass) a possible colleague? You also have to take into account, that there are people which don't know everything yet from the specifics you need. But in the right environment with support of colleagues, they become really great. It's more about the mindset & willingness to learn and also the support of the team members. The above is more for a general developer. For an expert with 7y+ (whatever..) experience in a specific topic. I would really ask very specific questions and maybe a "homework". Because I hire an expert for specific experience in a topic. Also the risk of losing money & time is much higher. Because it's experts work...it's hard to judge if the person is not capable or if it really just needs some extra time.. ;-) You won't believe how many people have a lot of years of experience and made only basic stuff during that time. So on paper they should be an expert, but in reality they are not.
nsainsbury 6y ago
The article is a follow-up to a previous post which I linked to in the leading sentence. > The author does not mention his experience interviewing or hiring people From the previous article: "I've been a software developer now for around 15 years. In that time, I've been a day-to-day developer, run my own successful software business, was co-founder at a VC funded startup, and I've had to hire and manage developers." > I'd love to hear what OP suggests to replace the coding tests with - a chat about past projects, then make an offer? From the article: "Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?"
- saagarjha 6y ago
  I know a lot of really smart people who would score somewhat poorly on those.
- gherkinnn 6y ago
  > "Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?" I have no Github, portfolio, nor education. My previous companies have a bad engineering culture. So they’ll give me good references, since they don’t know any better. I have trouble writing a fizz buzz and yet that system could have me hired.
seanmcdirmid 6y ago
The coding tests in many places no longer test coding. They test algorithms, dynamic programming, or how to deal with ambiguity for an incredibly under specified problem. They are useful in weeding out 80% of the candidates who are clueless, but they don’t provide much reliable distinguishing signal for the 20% that remain. The coding interview isn’t going to tell you the difference between a junior or senior dev. Heck, given that universities prep kids these days for google style leetcode interviews while a senior dev lacks the time for full time prep, junior devs are likely to do better on it.
- zimpenfish 6y ago
  > They test algorithms, dynamic programming, or how to deal with ambiguity for an incredibly under specified problem. I've been doing this for 25 years now and I've never had to implement an algorithm[1] from scratch or do any dynamic programming. I'm not entirely sure I'd consider myself "clueless" because of that. [1] In the traditional computing sense of the word
  - leethargo 6y ago
    I've been implementing Dynamic Programming, from scratch, just yesterday. But it wasn't for work either.
- danpalmer 6y ago
  > Heck, given that universities prep kids these days for google style leetcode interviews while a senior dev lacks the time for full time prep, junior devs are likely to do better on it. This depends on what the exercise tests. For datastructures and algorithms, yes maybe. We use a test where the most advanced data structures you will likely use are dictionaries and sets, and even those aren't necessary. The main thing the exercise tests is how do you structure a chunk of non-trivial business logic such that other engineers can understand it and reliably contribute to it. We assess this through code review, looking at the architecture and abstractions used.
zimpenfish 6y ago
> The author does not mention his experience interviewing or hiring people "Most recently I was the CTO of RateIt where I probably interviewed over 100 developers."
austincheney 6y ago
I fully agree. Here is my experience hiring from a pool of candidates: https://news.ycombinator.com/item?id=22740897 https://news.ycombinator.com/item?id=22740897
denormalfloat 6y ago
>I'd love to hear what OP suggests to replace the coding tests with. Making it easier to fire mishires would probably cover it.
- thayne 6y ago
  That introduces new problems. Hiring someone only to realize they are a bad fit, and then firing them is bad for both the employer and employee. Bad for the employer because they wated resources on on-boarding and compensating the employeed. Bad for the employee, because of they spent time working for a company that fired them instead of looking for a different job they could keep, and may have made other sacrifices for the job, such as relocating.

sparsely 6y ago

Recruitment for accountants etc often includes a technical skills component, I don't know why he thinks it doesn't.

peschu 6y ago
I used to work as a finance controller and I really never had to show a technical skill in an interview... And never saw it/heard from colleagues in finance, maybe in international accounting(which is more rule/law based) they ask if you know some stuff about this and that but nothing serious...
- x3n0ph3n3 6y ago
  CPAs go through a test more rigorous than the bar!

Fire-Dragon-DoL 6y ago

To be fair, a coding interview would address the "can he code at all" question, but not what you mentioned: sloppiness, incorrect coding and needing mentoring

sbergot 6y ago
I usually try to detect things like: "do you know lists and dictionaries?". Also very basic abstraction design and basic communication skills. This works well with juniors because we mostly code business logic. It does not work at all when trying to recruit a senior. I am still clueless about that. I have at least two recent cases in mind of a senior hire that lead to catastrophic results. People that new how to present well at a superficial level but did really poorly once they had non trivial stuff to do.
- peschu 6y ago
  general developer: I don't know why people want to find out if a person can code? ... I assume that a person can code ...(if not you will see very soon) I mean it's not about writing "hello world". If the person is not dumb, you won't find out in an interview if someone can really code. (repos are much better for that, but can be deceiving) "We have a 3 month probation period and if something is really not true it will have consequences. I'm crystal clear about that." I mean we are all humans, but there is also a contract with money involved. I have to look out for the company and it has to be fair for all the other team mates/colleagues too. If you hire some "faker", without consequences it will destroy the whole team balance. (Additionally there is a "meet the team" to address the consent process). From my experience, technical people have a low tolerance for people which can only talk...(in a technical team). So it does not mean you are safe if you can make it through the inverviews with tricks. (it may seem a bit hard, but I don't like the general acceptance of "lying" or superbeautify ^^ in the application process) And then I talk about what we are working on and how we are structured. So the interviewee also gets an impression what the day to day work will look like. What I really want to see, is the ability to solve problems. Because this is our real job. We are solving problems(with code). So I ask questions you can not solve in 5 minutes, but you see how someone approaches a problem. Is the person collecting intel about conditions and constraints or is he/she immediatly starting to code etc. ... For that I generally take real problems we had and we already found a solution. And sure I tell them, that it is not possible to find a solution now, because many interviewees are "conditioned" (or used to) to give you immediate solutions. Else they would panic or getting frustrated. In general ask a question: Why should I want to barbecue(or embarass) a possible colleague? You also have to take into account, that there are people which don't know everything yet from the specifics you need. But in the right environment with support of colleagues, they become really great. It's more about the mindset & willingness to learn and also the support of the team members. The above is more for a general developer. For an expert with 7y+ (whatever..) experience in a specific topic. I would really ask very specific questions and maybe a "homework". Because I hire an expert for specific experience in a topic. Also the risk of losing money & time is much higher. Because it's experts work...it's hard to judge if the person is not capable or if it really just needs some extra time.. ;-) You won't believe how many people have a lot of years of experience and made only basic stuff during that time. So on paper they should be an expert, but in reality they are not.

nsainsbury 6y ago

The article is a follow-up to a previous post which I linked to in the leading sentence. > The author does not mention his experience interviewing or hiring people From the previous article: "I've been a software developer now for around 15 years. In that time, I've been a day-to-day developer, run my own successful software business, was co-founder at a VC funded startup, and I've had to hire and manage developers." > I'd love to hear what OP suggests to replace the coding tests with - a chat about past projects, then make an offer? From the article: "Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?"

saagarjha 6y ago
I know a lot of really smart people who would score somewhat poorly on those.
gherkinnn 6y ago
> "Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?" I have no Github, portfolio, nor education. My previous companies have a bad engineering culture. So they’ll give me good references, since they don’t know any better. I have trouble writing a fizz buzz and yet that system could have me hired.

seanmcdirmid 6y ago

The coding tests in many places no longer test coding. They test algorithms, dynamic programming, or how to deal with ambiguity for an incredibly under specified problem. They are useful in weeding out 80% of the candidates who are clueless, but they don’t provide much reliable distinguishing signal for the 20% that remain. The coding interview isn’t going to tell you the difference between a junior or senior dev. Heck, given that universities prep kids these days for google style leetcode interviews while a senior dev lacks the time for full time prep, junior devs are likely to do better on it.

zimpenfish 6y ago
> They test algorithms, dynamic programming, or how to deal with ambiguity for an incredibly under specified problem. I've been doing this for 25 years now and I've never had to implement an algorithm[1] from scratch or do any dynamic programming. I'm not entirely sure I'd consider myself "clueless" because of that. [1] In the traditional computing sense of the word
- leethargo 6y ago
  I've been implementing Dynamic Programming, from scratch, just yesterday. But it wasn't for work either.
danpalmer 6y ago
> Heck, given that universities prep kids these days for google style leetcode interviews while a senior dev lacks the time for full time prep, junior devs are likely to do better on it. This depends on what the exercise tests. For datastructures and algorithms, yes maybe. We use a test where the most advanced data structures you will likely use are dictionaries and sets, and even those aren't necessary. The main thing the exercise tests is how do you structure a chunk of non-trivial business logic such that other engineers can understand it and reliably contribute to it. We assess this through code review, looking at the architecture and abstractions used.

zimpenfish 6y ago

> The author does not mention his experience interviewing or hiring people "Most recently I was the CTO of RateIt where I probably interviewed over 100 developers."

austincheney 6y ago

I fully agree. Here is my experience hiring from a pool of candidates: https://news.ycombinator.com/item?id=22740897 https://news.ycombinator.com/item?id=22740897

denormalfloat 6y ago

>I'd love to hear what OP suggests to replace the coding tests with. Making it easier to fire mishires would probably cover it.

thayne 6y ago
That introduces new problems. Hiring someone only to realize they are a bad fit, and then firing them is bad for both the employer and employee. Bad for the employer because they wated resources on on-boarding and compensating the employeed. Bad for the employee, because of they spent time working for a company that fired them instead of looking for a different job they could keep, and may have made other sacrifices for the job, such as relocating.