Interesting Links: Nov 20, 2016

What is this?

A collection of links from around the web that I found over the past week and are interesting enough to share.

Here goes…

Links

Books

Recently Finished

  • The Charisma Myth by Olivia Fox Cabane
  • Ego is the Enemy by Ryan Holiday
  • Algorithms to Live By by Brian Christian and Tom Griffith

Up Next

  • The Art and Science of Lifting by Greg Nuckols and Omar Isuf
  • Pebbles of Perception by Laurence Enderson
  • The Daily Stoic by Ryan Holiday
  • New World Ronin by Victor Pride
  • The Inevitable by Kevin Kelly

Always Follow Up!

Short post, but an important one:

During last year’s recruiting season, everyone told me the same thing:

If you don’t hear back, they are rejecting you.

Somehow, I never questioned that until now.

Yesterday I spent about an hour looking up every company I applied to this year and following up with them:

[Recruiter’s Name],

Just following up as I never heard back after I (applied/completed coding challenge/whatever)—am I still being considered for this position?

Thank you!

Best,
Charlie

The result? Five replies, three confirmations of rejection, two interviews in the next week.

Not bad. The lesson: ALWAYS follow up!

How I Found a Bug in HackerRank

For those not in the tech space, or for those who are but haven’t had to interview recently, one of the most recent trends in recruiting is to send candidates a coding challenge. The idea is to screen out those who can’t actually write code (apparently surprisingly common, see https://blog.codinghorror.com/why-cant-programmers-program/) so that you don’t have your engineers interviewing someone who is clearly not qualified.

There are a few companies that have developed platforms that make it easier for companies to do this and by far the most popular is HackerRank. They give you a problem description at the top, a text editor to write and run code in below that and then an input to test on as well as the expected output for it.

After you write code that is able to solve the known input, the server then runs the code on inputs that you are not supposed to be able to see. This is to give companies a gauge on how well you are able to write code that is able to deal with edge cases that are not given to you.

HackerRank lets you see how many hidden test cases there are as well as how many hidden test cases that you have passed. This leads to many frustrating moments when you have written code that gives the correct output on every test case except for one.


About a week ago, [company name omitted], one of the largest and most well known tech companies, sent me one of these and I faced this exact situation. After working on the last problem for a bit, I had a solution that worked for eight out of nine test cases. Sigh.

I read the problem description again and identified four areas in which there could possibly be an edge case with one of them requiring a rewrite of the main data structure that I had used.

Being lazy, I obviously did not want to do this. I really wanted to know what hidden input I was failing on so that I didn’t have to add code for all four of these edge cases when they were just testing for one.

I got up to get another cup of coffee and when I was walking back to my desk, I had a really stupid thought: “Since I know what the edge cases look like, can I just raise a runtime error if I see them?”

I really didn’t expect this to work, but added the two lines of code to test it: screenshot-from-2016-11-02-20-07-27

then I scrolled down and I pressed the submit button:

screenshot-from-2016-11-02-20-06-42

Bingo, I knew which edge case the problematic input was and could skip writing the solutions for the other three.

HackerRank does have functionality to mask the error message, so you aren’t able to write a custom exception to dump the exact input, but this is still a massive bug and something that should be addressed urgently. I’ll be sending this to HackerRank and to the company that gave me the challenge.

Thanks for reading!

 Update (2016-11-07)

HackerRank’s CTO, Hari Karunanidhi, reached out to me:

Harishankaran Karunanidhi (HackerRank)
Nov 7, 03:51 MST

Hi Charlie,

Thanks for sharing the feedback. We have a tough job of finding the right balance between having the test secure and also candidate friendly. For example, hiding the type of error would make it really frustrating for a developer to solve a challenge.

In this case, kudos on tracing out the corner case. For example, your idea of “Since I know what the edge cases look like, can I just raise a runtime error if I see them?” is not something all candidates might get during an online assessment.

Once again, thanks for reporting this. But we’ll display the “Runtime Error” to make sure the product is easy for test solvers to solve. We’ll also work towards making better testcases, so that you are forced to take care of all the corner cases.

-Hari.
CTO,
HackerRank.

His reasoning is understandable, but I still feel that they should just mark test cases with errors and incorrect. Still cool that the CTO himself responded.

Hello world!

Finally got around to setting up a personal website!

In the process of writing content for all static pages. The purpose of having this blog is yet to be determined. Main decision to be made is whether or not to keep it to only professional content or to not censor anything. Leaning towards the latter.