FizzBuzz 2.0: Pragmatic Programming Questions for Software Engineers | Hacker News Reader

FizzBuzz 2.0: Pragmatic Programming Questions for Software Engineers

triplebyte.com

10 pointscompumike4 comments

I think the 5th one is harder because it has a lot of reliance on recognizing a specific syntax for key/value stores, and may rely on realizing that a key/value store can have another key/value store as one of its values. This code couldn't be written recognizably-the-same in at least a couple of the languages I use which have key/value stores, and would be syntactically quite different in some. If you don't recognize the syntax, you have to start thinking about the problem and ruling things in or out, and that's harder. Probably still possible, but it's going to be testing at least some amount of a test-taking skill that isn't always taught.

Yikes. Only 42% going 5/5 from the already rarefied pool of people who would bother to go through the TripleByte quiz is a little scary.

(Article author here.)

I'm not sure to what degree I'd call it "already rarefied", as Triplebyte is a totally open platform that literally anyone with a web browser can join. But as an experienced engineer myself, the 42% number is definitely "a little scary", which is why I thought it was so interesting to be able to share this data.

(Hopefully anyone reading here on HN finds these questions to be quite easy.)

Note:

Even nowadays I find there are large swathes of the Internet I have never ended up in have great difficulty even piercing due to search engine optimization. I actively have to torture some search engines, and get 3-7 pages deep to get passed most of the usual suspects just to get to places I haven't seen before.

Just because it is on the Internet, does not mean it is readily visible to everyone, or that the audience you will attract is actually the audience you want to.

I generally never look at those types of things before an interview. I'll catch up on recent tech usually, but I'm generally good enough at the basics and being able to explain the depths of where I've been previously that that sort of thing doesn't register as a useful application of my time in the long run.

I try to warn businesses away from that sort of buffoonery, because at the end of the day, the "Engineer" part is more important in the long run than the "software" bit, and engineering mentality is a lot easier to pin down in my experience than whether someone is a virtuoso in your current tech stack.

My two cents anyway.

Reply on news.ycombinator.com