Writing

Software, technology, sysadmin war stories, and more. Feed
Saturday, August 15, 2020

Reader feedback: leetcode, HSTS, and more on Unix files

It's time for another round of responses to reader feedback.

...

But I was curious what you think of hackerrank/leetcode screening of potential employees. I think it is an absurd waste of time but it doesn't seem to hurt any of the companies that employ it. Since you worked for one that does (and perhaps still do), I'd like to know your view (if you choose to write a post on it).

I must admit, the fact I worked someplace that used (or uses?) those sites is a little surprising to me. I assume the reader is talking about the pink mustache factory, but I guess there might be others, too. This is because I have never used any of them in the course of getting a job. Granted, I've been doing this computer stuff a while -- far longer than they've existed (or any other web sites for that matter), but it's still never come up in the hiring process for me.

I only have a passing familiarity with those sites. Specifically, I have not looked at either of the two named (hackerrank or leetcode). I *did* look at yet another one (triplebyte?) after one of my friends mentioned having to go through it in their process of escaping said mustache factory.

Triplebyte seemed amusing, so I rigged up a dummy e-mail address and got cracking just to see what it wanted to know. I answered a bunch of questions. It said I was strongest in "pragmatic problem solving" and could improve in "system architecture". I also need to work on my "low-level systems", apparently. Okay then.

What's it like? Well, they ask you a question like this: you're going to build a forum. Pick one of the following: (A) some complete bullshit (B) sounds okay but has a flaw (C) reasonable thing (D) insane thing (E) I don't know.

The "A" answer looked like the kind of word salad I see people spew when they can't bring themselves to say "I don't know". I guess it could totally draw in someone who's lured by big words that seem complicated. (You know, like that generated-by-GPT-3 article that made front page of Hacker News last week.)

I got the impression that there were places where I needed to answer the question "their way", even though I didn't necessarily agree with it. Like, they asked one of those questions where the question itself implies certain things that don't hold water, and so no direct answer is going to work. You can either sigh and answer the way they want, or pull the nerd card and go the other way and take the hit on the points. At this point I honestly don't remember which way I went.

Anyway, I thought it was amusing, but honestly don't know if it would be valuable. I've not seen the "reporting" side of it, and have no idea what someone looking to hire would see about a candidate from it.

I do know that I've done both markerboard coding and laptop coding, and while they both sucked, the laptop version was far worse. There are certain semantic shortcuts you can do when you're being interviewed by another human being using the marker board as your visible storage of state. You can say things like "obviously I check for error here, and return if so, and I'll just mark that with an E in a box, so I don't have to write the if-x-is-null-then-return everywhere". Then you proceed to do exactly that, writing the [E] instead of having to check ALL THE THINGS.

I did that method back in 2006 when interviewing for that creepy place that used to be known for searching the web. It worked fine, and it was a good thing too, since I was doing everything in plain old C to prove that I knew the ins and outs of the data structures involved. I was sweating buckets by the end of that one. It worked, but that experience sucked.

Then, in 2018, I had the "laptop" version of this, and was handed a spec, an input file, and some output files, and left to get cranking on it. I went down the wrong road with my initial design and didn't have enough time to see the problem and twist it around to work. It felt like shit. I realized that I had nothing to lose here, and had nothing at stake. I didn't need the job for any reason, and I felt like crap.

I can only imagine what someone who actually needs the job must feel like when they are given an hour and are expected to write solid code that actually compiles and runs and yields the right result. To make matters worse, you're sitting in a foreign environment and disconnected from your usual situation by being on the laptop's screen/keyboard/trackpad directly instead of using a big display, real keyboard, real mouse, and so on.

I guess there are people who are just fine running on the Mac side of things, using the laptop's native everything, but that's not me. I came up before that existed, and am used to something very different.

Incidentally, this kept gnawing at me, so a couple of days later, I spent some time at home at my usual desk and managed to figure it out. My initial assumption about the internals of how to store the data for the problem had been wrong, and so it followed that ~30 minutes later after slamming it into the computer, the implementation would have been wrong, too. Going about it the right way ("down, not across", ironically enough) yielded better results. My new code gave the expected output.

All said, I think it took me maybe three and a half hours to finish the problem, including the ~hour spent in the on site interview originally.

It makes you wonder about the people who somehow manage to submit something in the hour provided. Exactly what are they doing to accomplish that? It must be full of holes.

It's basically optimizing for people who are good at timed programming contests. I was never good at those.

...

Josh writes:

Have you considered setting up HSTS? I noticed the recent HN post links to your HTTP site. HSTS should improve the security for all your visitors.

I have! Back in 2015, I considered it, and then discarded the notion. My original intent of allowing people to connect even if (for whatever reason) https is not working on their system, at their site, on in their country remains unchanged.

The site has been running on the https side all this time, and so anyone can go there if they want. I'm just not going to force it on them.

https itself can improve security. HSTS closes doors. I'll take the one but not the other.

...

Ryan writes:

Your advice on using renames for atomic writes misses that rename won't work across filesystems and mount points, which I think is important since you're recommending people use mktmp.

This is true, but notice I was sneaky about how I wrote about it: "Create a file adjacent to the target path...". That is, if you are trying to write /a/b/c/foo.bar, you start by creating /a/b/c/foo.bar.(whatever), with the expectation that all of /a/b/c will be a single filesystem. If that precondition is somehow violated on your system, well, I don't even want to know how or why.

For C library purposes, this might mean mkstemp with a template that includes the full path. For other languages, well, find the equivalent. Be aware that they might be doing some kind of TMPDIR thing if you don't give them a directory explicitly somehow. Check out the man page for mktemp(1) to see what I mean.

Incidentally, /tmp is evil. This means /var/tmp is too. Far too much badness comes about because people "just write to /tmp/something". Do yourself a favor and write your stuff to paths that are only controlled by the current user if at all possible.

...

Milosz wrote in recommending a Dan Luu post called "files are fraught with peril". I concur. If you liked the Unix file post from a few days ago, you should go there and look at what else ails people in this space.

I didn't even scratch the surface of "yeah, but is it actually persisted on the disk or whatever" in my post. Actually caring about that opens a massive can of worms.

If you have a strong stomach, go look up O_PONIES. Yeah. Enjoy!