Hacker News Reader

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.

> 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

I've been implementing Dynamic Programming, from scratch, just yesterday. But it wasn't for work either.

> 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.

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?"

I know a lot of really smart people who would score somewhat poorly on those.

> "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.

> 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."

>I'd love to hear what OP suggests to replace the coding tests with.

Making it easier to fire mishires would probably cover it.

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.

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

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.

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.

In my extremely limited experience in hiring (very few people), I made multiple mistakes. One of the thing I discovered (we were hiring a junior and both of us gave approval) was that you can find a person who can solve problems but can't actually code (there were a lot of red flags that we ignored on purpose I guess).

It isn't until I read your answer that I realized this: we were both convinced because the guy was smart, clearly, however he didn't know enough of the technology we were using to develop anything meaningful with it. While when hiring a senior developer, it's possible that they can pick-up a new language or framework very fast, this is highly unlikely with a junior (this is not something I have in numbers, just thought).

The real side of the problem is that is very hard to figure out if someone will be good with everything that's not "oh, you can code". It's not well defined in the industry, so there is no objective methodology to evaluate the skills of a person. As a developer, you can usually recognize if someone can code, but determining if they are sloppy, care for design, that's a totally different thing: you need to work with them to figure that out, this is probably why an interview is not enough.

I fully agree. Here is my experience hiring from a pool of candidates:

https://news.ycombinator.com/item?id=22740897

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

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...

CPAs go through a test more rigorous than the bar!