Live data from Hacker News

Why HackerRank and other coding tests are ageist

news.efinancialcareers.com

71–80 of 98 posts

Re: Why HackerRank and other coding tests are ageist

#71

Earlier quoted context omitted.

doctors Because the healthcare job market is such a success! Remember those accusations against tech companies for colluding to depress wages? Now imagine the same, but with State immunity! The anti-trust class-action lawsuit Jung v. AAMC alleged collusion to prevent American trainee doctors from negotiating for better working conditions. The working conditions of medical residents often involved 80- to 100-hour work…

I never said "let's make software licensure exactly like healthcare licensure". There are parts of healthcare licensure we could also criticize, but that's not my point. If you'd like to discuss specific parts of softwares licensure, I'm more than willing, but don't engage in faulty reasoning.

You don't get to decide how it'll shape up; public choice and markets don't work like that. The decision to mandate licensure unleashes forces that very often lead to the kinds of problems that I described above.

Unless you have a very good reason why it won't in this case, you're just playing with fire.

Re: Why HackerRank and other coding tests are ageist

#72
post #20

Earlier quoted context omitted.

If you're a successful working programmer you shouldn't need to study to pass your next interview only to forget it all again after a couple more years on the job. That is why these tests are bogus. If they measured useful skills they wouldn't require any study. I've been working with a lot of graph algorithms lately. I've already forgotten several I learned a couple months ago. That is OK. The more interesting quest…

> If they measured useful skills they wouldn't require any study. I would be careful with this kind of statements. It can also show that most programming jobs don't actually require a sophisticated level of knowledge.

One programming job may require a completely different skillset than another.

Going over the Hackerrank algorithms, how many times do you do things like fancy bit manipulation or game theory algorithms for building a simple CRUD web app? There are certainly programming jobs where bit manipulation is common (systems level / embedded code is one I can think of) but from my experience it's pretty rare to XOR bits in Javascript land.

Same with things like data structures. Again: in the world of C / C++, certainly you'd use trees / linked lists / etc. I do think is good to know about these concepts regardless so that this type of thing is more than just vague black box magic, but in Javascript CRUD web app land all of that stuff is mostly "behind the curtain", so it isn't the most necessary skill to have.

Hackerrank in fact seems really poorly suited to web development positions. No tests on CSS, HTML, design patterns (yer model-view-* patterns, dependency injection, responsive web design, etc etc.), data transmission structures (eg JSON and XML), browser structure (eg the DOM), dynamic communication (eg Ajax/XHR, Websockets), etc.

Heck, Hackerrank may show that you can write some SQL, but ironically for something with "hacker" in it's name, it can't show that you know about how to mitigate the common "web hack" tricks (eg SQL injection, XSS vulnerabilities, URL fuzzing), something I would think would actually be way more relevant for any public CRUD web app.

Re: Why HackerRank and other coding tests are ageist

#73
post #55
post #25

Earlier quoted context omitted.

> There are so many programming languages, frameworks out there that are constantly evolving and companies have different demands. An idea that I have thought of is to standardize on some programming language/frameworks/demands that are known to be supported for a very long time (15 years?). If you need something from this buffet, you are fine and have the advantages that this provides. If you have special demands, y…

I would love to see some sort of standardisation and rationalisation within software engineering. It's so fragmented and ego driven. Every framework is better than the last, my programming language is better than yours. Thought is rarely given to longevity. I'd much rather work with a more dated ecosystem that I know will be around of true next 20 years than the continual paradigm shifts we endure just now. I'm exhau…

There are many jobs like that; it's not hard to some Java shop maintaining some CRUD software for over a decade, with no signs of switching. Hell, a colleague of mine just got a decent offer to develop in Informix 4GL.

Re: Why HackerRank and other coding tests are ageist

#74

"For experienced programmers like Adler, the new tests aren’t insurmountable – all that’s required is an injection of time to learn the new Hackerrank tricks." Well, yeah. I do that too and I've been out of university for 5 years. You have to prepare for interviews, and to resharpen your skills when you're changing jobs, it's the same whether you're 28 or 48. I understand finding time is harder when you have a family…

If you're a successful working programmer you shouldn't need to study to pass your next interview only to forget it all again after a couple more years on the job. That is why these tests are bogus. If they measured useful skills they wouldn't require any study. I've been working with a lot of graph algorithms lately. I've already forgotten several I learned a couple months ago. That is OK. The more interesting quest…

Yes, you should not have to do that.

But place yourself on the other side of the fence : you just opened a new positions, there is a hundred of applicants and you have limited time to interview them all.

If you do spend 1 hour with each one of them, you have spent at least 200 hours on this task, not accounting for the back and forth to find a right schedule and all, probably spread over several months since most people are only available for interview from 17h to 20h or 12h to 14h.

Let's say you have 5 people dedicated to this, obviously technical ones for this kind of task, interviewing everyday for 4 hours (2h interview + 2h of debrief/internal discussion), that's still a whole month of interviews, everyday, for 5 people who are not HR and probably have better things to do, for one not that long interview for one position.

It's simply not efficient, and smaller structure can not handle that.

Alternatively, you can filter out 50% easily by making them take a programming test, with overall few false negative. There's a non negligible portion of false positive as well, but now from 100 applicants you have 50, so interviews are much easier to manage, you have more time to do it and the overall quality of interviewee is much higher.

So yes, in an ideal world, everyone would know the exact level of everyone just by looking at a CV and people would not need to prove anything by a test, but that's not how it is for now.

If you have a better solution, I'm sure a lot of people would be keen to hear it because recruiting is very costly and arguably one of the most sensitive part to build a company.

There are solutions like referals and such which works very well when they do, but when you have a lot of positions to fill it's hard to find enough people.

Re: Why HackerRank and other coding tests are ageist

#75

Earlier quoted context omitted.

Credentialing. Seriously. Have a Bar Association for developers. When anyone can do a few weeks of Googling and claim to be a software developer, you're going to get mostly crap candidates. Offload that process to a formal body, like lawyers, doctors, and engineers do. You can hire unlicensed developers, but you do so at your own risk. Then once you're talking to someone licensed in an interview, you can focus on jus…

There is powerful opposition in our line of work to this type of thing, particularly the standardized tests. I don't fully understand it because I think that certification exams, etc. have clear, if limited value. I think it stems from an intrinsic starting point among many developers that programming is a true meritocracy and that all hiring questions can be settled with a judicious study of what the person is truly…

I don't know from where it stems for the majority of opponents. For me, it stems from a complete lack of faith that the system would be well designed and even relatively free from corruption, and therefore that it would not make things much worse, while not actually solving the problem it's supposed to solve.

Certification exams already exist, and employers are free to require them to avoid the "crap candidates". Other problems, like security flaws affecting the users, can be better solved by imposing real penalties on companies.

Re: Why HackerRank and other coding tests are ageist

#76
post #42

Earlier quoted context omitted.

Bigger software companies also typically require "experienced" candidates (read: not new grads) to pass a systems design interview, which is very subjective and typically fairly difficult. This essentially makes the bar for new grads lower. The argument is that this is because they expect experienced developers to be able to enter at a higher level, but the cynical side of me thinks that it's because they really pref…

You can be a new grad and have experience. I made a point to do work in college that was appropriate for my work field when I graduated. Appropriate summer and part time jobs helped quite a bit as well. Having a bunch of appropriate jobs and projects under your belt (especially a few apps in app stores and code up on github) goes a very long way.

Sure, I wasn't arguing that they're mutually exclusive. I was referring to the way that e.g. Google would refer to "experienced" or "industry" candidates.

Re: Why HackerRank and other coding tests are ageist

#77
Hackerrank is a really good tool to separate the incapable from the capable, but not a very good one to separate the good from the best (or even the average from the good).

It's impressive the number of supposedly senior candidates that can't follow simple instructions from the platform or write a couple of lines of code in their language of choice to sort the words in a string or something similar.

I fully agree that multiple complex algorithm or puzzle questions are bad - require a longer time investiment that most candidates should be willing to devote to such process, are distanced to the reality of most programming tasks and favor those who enjoy and practice programming puzzles.

Re: Why HackerRank and other coding tests are ageist

#78
post #69
post #43

Earlier quoted context omitted.

> similar tests aren’t necessarily relevant to the work actually done in finance technology roles IMO, what's relevant for a role is the skill set most people currently doing that role have and that's not always a good thing. I've been the first shouting on top of a roof that we shouldn't ask people to know stupid little algorithm trivias to get a job. But the narative for that quickly devolved to "data structures an…

Testing foundation is great but that is not at all what the current interviewing system does. It hides foundation in trick questions that require you to have a moment of insight that fires off a light bulb that you can then use your foundation to solve. For example why cant they just ask. Ok givin an array find all the pairs of the array. Great now whats the big O of that. Great... Instead they ask some trick questio…

I totally agree. My point wasn't that the interviewing system was great. Just that the problem with it isn't what it's trying to test, but how.

I have issues with people who dismiss the problem space entirely. "I don't need to know CS fundamentals to do my job". To which I say: you do. You're just doing a subpar job because -everyone else- is and that's the standard even though it's suboptimal.

(Note I don't have a CS background myself, and thought this for a long time, until I ended up working in environments that were CS heavy and seeing how "hard problems" were trivialized, so we could spend time solving "real" problems instead)

Re: Why HackerRank and other coding tests are ageist

#79
post #57
post #43

Earlier quoted context omitted.

> similar tests aren’t necessarily relevant to the work actually done in finance technology roles IMO, what's relevant for a role is the skill set most people currently doing that role have and that's not always a good thing. I've been the first shouting on top of a roof that we shouldn't ask people to know stupid little algorithm trivias to get a job. But the narative for that quickly devolved to "data structures an…

I consider it from a problem-solving perspective: I don't need to know the intricate details of dozens of sorting algorithms or data structures. What I need to be able to do is solve the problems that get thrown at me in daily work. So if I get assigned, say, a performance problem I might, after some research, come up with the idea to use a different data structure to solve it. Or something entirely else! Depends on…

> So if I get assigned, say, a performance problem I might, after some research, come up with the idea to use a different data structure to solve it.

Yup. And my feel on that is that (assuming the perf issue is related to a core data structure), that -particular- perf issue shouldn't even have happened in the first place. It should have been obvious given the right background and you could have spent that time doing something less fundamental.

Re: Why HackerRank and other coding tests are ageist

#80
post #43
post #4

> Exactly on point. Also one gripe I have with hackerrank (I did some of the challenges to brush up on some language knowledge), is that a lot of the questions are poorly designed and from obvious amateurs. I still think that neither whiteboarding nor hackerrank selects for good developers. In the end you get people that studied hard to solve a certain class of problem that you'll never need in the real world. It's w…

> similar tests aren’t necessarily relevant to the work actually done in finance technology roles IMO, what's relevant for a role is the skill set most people currently doing that role have and that's not always a good thing. I've been the first shouting on top of a roof that we shouldn't ask people to know stupid little algorithm trivias to get a job. But the narative for that quickly devolved to "data structures an…

I thought about this, I thought about this a lot and I still do. Thing is, this attitude can quickly get you tumbling down the rabbit hole.

So say I'm a Java developer. But surely in order to be a good Java developer I should know the innards of the JVM, right? To do that I now have to also have to know C++ because that's what JVM is implemented in or whatever. But surely I can't know C++ well if I don't know C, right? But then I can't really grasp C well enough if I don't understand how assembly works, right? What about CPU instructions, different architectures, etc?

My opinion is that nobody should even try to drink what seems to be an ever expanding ocean of knowledge in IT. Let the people (in academia or wherever) who work on algorithms work on algorithms, let the people who write frameworks continue writing frameworks and let the rest of us code monkeys to use all those digested tools and technologies to do what we have to do on daily basis. You don't ask a common plumber to describe Bernoulli's principle during an interview, do you?

Post reply on HN