In case you’re not familiar with HackerRank, it’s a platform for practicing coding, and, increasingly, it has become a platform for companies to test their engineering candidates. This is why it’s a problem that they’re encouraging people who practice with them or interview using their platform to write bad code.
function Rectangle(a, b) {
}
This is the starting point of a function they ask you to write for their 10 Days of Javascript. Creating a rectangle object is day 4 of those 10 days. Most coders will take this starting point as it is and fill in the space between the brackets. That’s probably what HackerRank expects you to do with their problems: leave the starting point they’ve given you as-is and fill in what’s missing.
If this is all they ever gave you, you could probably work out that a is one side of the rectangle and b is the other side. If you read the problem description, they’ll tell you explicitly that a is the length of the rectangle and b is the width.
Why All the Secrecy?
Batman needs to keep his identity secret. He spends his evenings breaking the law. Even though he’s doing it for good, he could still be arrested. In order to stay on the streets delivering vigilante justice, he can’t let anyone know that he is actually Bruce Wayne.
But, as far as I can tell, a and b don’t need to keep their true identities (the length and width of the rectangle) hidden. In fact, all they’re ever going to do in this function is be the length and width of the rectangle. That means they don’t even need to be a and b.
The names length and width are not reserved by Javascript. So, why not just call a spade a spade? Why can’t the length be length and the width be width?
Yeah, but What's the Harm?
In this HackerRank exercise, you’re going to write a few lines of code at most. Not to mention the only two logical parameters to create a rectangle and its length and width. You’re probably not going to permanently lose track of what a and b are. Even so, there’s still going to be a split second where you don’t know what a and b are.
This might even make you feel cool. Like you’re part of a fun club with a secret code. Muggles look at a and b and throw their hands into the air, but you… you can decipher it in a fraction of a second. It feels like a superpower. And if HackerRank does it like this, it must be right right way… right? !😰
In your career, you’ll never write an application that’s this short and that does so little. Imagine the split second it takes to remember what a and b are in the Rectangle function. Now put that in a context where the meaning of the parameters are not so clear. Maybe you have a function that displays an alert on your page. It takes three parameters: a, b, and c. Any idea what those parameters are? Yeah, me neither.
Now take this new naming issue and blow it up to an application with 10,000 lines of code. Each function has parameters with cryptic single-letter names. Since you learned this is OK, your variables are probably not thoughtfully named either. You’re going to spend most of the time you work on this application just trying to figure out what it does. I pity anyone else who has to pick this app up and work on it. I hope they have plenty of aspirin.
You might think I’ve cherry picked the only example or maybe the worst example of this on HackerRank. You’d be very very wrong. Not every exercise uses this opaque variable and parameter naming, but many do and some are even worse than my first example. Here’s your starting code for another indecipherable exercise:
'use strict';
process.stdin.resume();
process.stdin.setEncoding('utf-8');
let inputString = '';
let currentLine = 0;
process.stdin.on('data', inputStdin => {
inputString += inputStdin;
});
process.stdin.on('end', _ => {
inputString = inputString.replace(/\s*$/, '')
.split('\n')
.map(str => str.replace(/\s*$/, ''));
main();
});
function readLine() {
return inputString[currentLine++];
}
// Complete the minimumBribes function below.
function minimumBribes(q) {
}
function main() {
const t = parseInt(readLine(), 10);
for (let tItr = 0; tItr < t; tItr++) {
const n = parseInt(readLine(), 10);
const q = readLine().split(' ').map(qTemp => parseInt(qTemp, 10));
minimumBribes(q);
}
}
The variable naming in that main function is seriously making my head spin. t? tItr? n? q? qTemp? Why are these practice exercises not more readable?
Hey there. I help people like you start their web development careers. It starts with identifying a goal. Take my free course to get started! 🎉
Code Is For Humans
You may think that code is for computers. It’s not. Code is for humans. If it was exclusively for computers, we’d have no need for a high-level language like Javascript or Python.
Take this to heart as you’re writing your code. Write it to be read by someone other than you. Variable, parameter, and function names should encapsulate as much context as possible to help the reader understand what they’re reading. a is bad. length is good. lengthInInches is even better (if, in fact, you’re expecting the measurement to be in inches). If your code changes, make sure you update your names to reflect what they now represent.
It’s easy to look at HackerRank and, because they’re a huge, well-established, and, if the number of interviews administered through them is any indicator, well-respected site, assume they’re starting you out with good code. Unfortunately, that’s not the case.
If you practice on HackerRank, do yourself a favor and start your exercise by refactoring their terrible meaningless names to something that conveys the meaning and context needed to read the code. When you’re working on projects outside the platform, make sure their bad habits don’t poison your code and give you a reputation as a developer who writes indecipherable code.
By writing your code for the next developer coming behind you, you make it easy not only for other developers to work with you but for your clients to re-hire you and recommend you to other companies who need your help.
Top comments (34)
HackerRank also taught me how to write pretty clever code. Clever, unreadable, one-line code.
Now I'd rather write 3 lines of code and spend half a second reading the function than writing 1 line of code and spending 10 seconds to read what I was doing.
As you say, coding is for humans.
Agreed. Clever code makes you feel smart but doesn't do other the things that code should.
I feel stupid explaining code, so I tend the other direction. If I'm explaining then I feel like I did it badly and it's very embarrassing to me. Funny how we as humans see the same thing, but view it very differently.
I tried hackerrank and after two of those kinds of questions I quit for the simple reason that I didn't want to feel like an idiot. Opaque code is just tiring and IRL I always just ask. It's not worth my time doing it any other way.
Thank you so much for shining a light on this issue. It needs more attention and I thank you for taking the time to call them out on a very bad practice.
I was told early in my career to "code for the next developer after you" but also "imagine the next developer is a very big, angry man who knows where you live". Worked a treat, my naming and commenting is now explicit and verbose!
😆 I love that advice!
One thing I also noticed as someone who has appplied to hundreds of jobs. 100% of the companies that have used Hackerrank on me never even followed up about the solution. If Hackerrank was the first step. You'd expect to discuss some of your implementation and maybe extend functionalities just to confirm you actually wrote the code. Never has this happen.NEVER. I mean not just once. They usually just move you to the next stage and pretend there was never an Hackerrank test.
It means employers just used this to judge if you can write any code at all. The problem is I could have employed anyone to write the code.Why don't you just take a cursory look at my github. That gives more info than Hackerrank.
There is literarily no Haackerrank problem you can't google if you search enough. Except few ones that are custom made by companies. It is a waste of everybodys time.
This 100%! If my resume, cover letter, portfolio, projects, github, linkedin, etc. aren't enough then what are we even doing?
The hiring process really needs to take a step back and reevaluate itself. What's worse is the fact that it's a well known issue and nobody does anything...
The best part is that if you google you can find the tests of the company/job you apply for. They don't even bother to iterate the questions.
I agree for the most part. I'm a huge advocate for responsible coding. Shoot, a huge part of Dead Simple Python is dedicated to it. More on coding challenges and good practice in a moment...
With that said, I think there is an exception for competitive code golfing (which I usually do over on Codingame instead of HackerRank), which I've found to be beneficial in a different way:
The goal of making the code as compact as possible forces me to understand the underlying processes and alternative ways of doing things. Brute-force seldom wins in length-based code golfing.
The same processes you should follow to make your code smaller in length-based code golfing are the same processes you would use in real world refactoring, although the outcomes are different. You always start by writing a simple, straightforward solution and verifying it works, and then you begin rewriting it piece-by-piece until it's a small as possible.
Time-restricted code golfing hones your ability to distill human thought (the prompt) into computer logic quickly and efficiently. In practice, this has helped me write better code in real world scenarios; it takes me less time to work out the logic, so I have more time to pay attention to matters of design and good practice. (After all, don't we usually skip good practice because of time?)
These unique benefits justify terrible variable naming practices in that specific context, so long as one remembers to use good names elsewhere.
None of that is to invalidate your concerns, of course. One should be aware of the profound differences between code golfing and real-world coding, and HackerRank doesn't always make that difference clear. Given its lack of time constraints, and the fact it isn't formal length-based code golfing (as far as I know), there's no reason why you shouldn't apply good practice to your code there! I literally always delete HackerRank's default code.
Personally, I do prefer Codingame, as it has proper multiplayer code golfing which is separate from the standard coding challenges. Their default code is almost always better, too.
This is the part I hate the most. The problem description is so academic and pointlessly long. I have no CS background and find this off putting.
Totally agree. I have a CS (actually msc) background and after 14 years working for an international company I wanted to move along and find a new job (yes, I am not the typical jobhopper). To my greatest surprise most of the companies here asked for HackerRank tests. I started working on hacker rank exercises and eventually passed them. However, it was like practicing for an exam, and totally removed from real-life problems. Now, either every company needs to solve complex algorithmic problems on a daily basics (which I am pretty sure they don't) or this is some kind of quick test just because it seems easy for the recruiters. The code I had to write in hacker rank was ugly and would never pass any of my own code review for sure.
As a former competitive programmer, I can't completely agree with the premise of the article for a simple reason:
Hackerrank and similar websites are NOT teaching you code.
The purpose of those websites is to test for and practice algorithms and algorithmic thinking and, last time I checked, the code editor there allows you to delete everything entirely and write your own.
Their premise is that if the core of the problem is to test your knowledge of say... Dijkstra, the way you'll parse your input files and read input and write output are a distraction with respect to knowing whether you can or not write a Dijkstra based solution.
Some websites choose to let you upload your code entirely or others give you these placeholders. I'd dare say that competitive programmers would be smart enough to never take that code as production-ready at face value.
Also as a sidenote, I never, ever needed to read/parse files in a professional setting in any non-trivial way besides reading the file as a list of lines.
Here's the problem with that: junior developers are using HackerRank to practice because they're being sent there by recruiters and companies to complete coding problems as part of job interviews. If that's the site that gets them the job, it seems natural to practice there as well.
It's easy for you and I to look at this with a more robust perspective and say, "Well, of course this isn't the code you're supposed to write in production," but that's not made clear to a new developer. They don't have the tools yet to be critical of the efficacy of this code in other contexts. Competitive coders will have those tools, but HackerRank does nothing to keep out those who are not competitive coders and it doesn't make it clear that the platform is only intended for them or even just that the code is not production-quality.
If I were inexperienced, interviewing for a job and they sent me to test for the job on HackerRank, I would assume the code used on HackerRank reflects the code they will want me to write on the job. Why would they want to test whether or not I can write code they won't accept from me if I'm an employee?
So, HackerRank may not claim to teach people to code, but they are teaching people to code, for better or for worse (in my opinion, for worse).
Thanks for reading and sharing your perspective, Bruno.
Wow, thank you so much for your reply! :) (I assume you're also far more experienced than me, so this is a great perspective)
I agree with what you say indeed, junior devs or people just "going at it for the job", even if they're good at algorithms, can definitely pick up very bad habits from that scaffolding code that lies there.
Unfortunately competitive programming is literally a competition so writing unsafe, sluggish but blazingly fast I/O routines and taking some dubious shortcuts it's the norm there (top competitors using C/C++ would have hundreds of lines amongst macros and custom I/O routines just to shave off ms on reading and processing input) and unfortunately some junior devs can definitely approach those platforms completely misguided and start their career with the left foot there... Ultimately experience and long exposure to production code will fix all of these quirks but I agree it's a big problem with more and more companies "outsourcing" code challenges on these platforms nowadays. Thanks a lot for your reply
Thank you for this post. I'm 3 months into a Python Bootcamp and started doing a basic Python path there. The code they suggest in their basic arithmetic tasks is really weird and questions all I've learned so far. It's good to hear that I'm not the only confused person around.
I say the best code is "dumb code".
Code that is so blatantly obvious, so simple, and so boring to read that you don't need comments. I'm not saying this is always possible, but it should always be the goal.
I use sometimes hackerrank but never thought about this. In everyday code, I am trying to be explicit and least ambiguous software as though as if I was woken up at 12 at night and had to debug it. But I noticed that comes with experience I think and after eating
a fewhumble pies myself and writing crap code :).Yep this seems right; HackerRank is closer to TopCoder, the goal is to pass the test and whatever other criteria there is. For HackerRank it's to pass the test and prove you can code to the interviewers. For TopCoder it's to pass the test and make the code as performant as possible.
I'm hoping that no one is really using either of those as a model for production code though!
I'm afraid people are taking those exercise starting points as models for how they should code because they don't know to be critical of them. Hope this post can reach at least a few of them.
Thanks for reading, Rudolf.
Hacker rank taught me that when you are given a question and you write code to solve the question your code still sucks because you don't sort your data to pass the tests even thought they don't ask you to sort the data in the question.
"Code is for humans." That is the strongest, and in my opinion, most important, point made in this article.
All code we write is made to be extended and improved by the people around us who, in many ways, would have a more clever way of extending and improving it. I am 100% guilty of rewriting functions myself if I can do it more quickly than I can understand what the previous developer was trying to. Not a great practice, I admit. But many times, an END PRODUCT is required that does certain things, to certain specifications, for a certain price, by a certain date. How clever the current codebase was is totally meaningless if it can be rewritten faster than extended. Don't let good code die when you leave. Variable, parameter, argument, function, class, and module names COUNT!! I want to work with the code I've been given. But I want to not have to explain delays to executive managment more. Just saying...😁😁🤪🤪
I agree I'm the way that anyone writing about software development should be guiding others to be the kind of person that adds finesse to a team, not the one bringing speed bumps to the team. Help others create positive software engineer habits!
This is so true!! I remember joining my first job and being surprised when micro optimisations, clever tricks that save lines and obscure logic that you think is super cool are not applauded, and rather discouraged.
Being in college, hackerrank and countless other similar platforms taught me to value the wrong things and continue to do so. Smh
Rant over.
Doing some of the Javascript challenges, the instructions are so terrible. I cannot even follow what they want me to do, it's like they need to be re-written. They want me to print out my result, or assign a member variable and the debugging experience is trash.