Hacker News Reader

Comment by ravenstine | Hacker News Reader

I find it astonishing how I often I've been asked about binary trees and binary search trees in web developer interviews. In all my time, I've come across some circumstances where some concepts like state machines were helpful, but have yet to run into a time where I needed to understand or write a binary tree. At first I felt ashamed, but over time the feeling flipped and I felt bad for the interviewer asking such a non-applicable question as for them to look rather foolish. It's like asking a biologist to describe the Dirac equation.

Fortunately I've yet to run into this once I spent enough time as a mid-level developer and became senior. If it's any ray of hope for younger developers out there, you will get to a point where you basically bypass all that crap and interviews can be more like a friendly chat between peers.

View on HN

This has not been my experience (lately). That’s how it used to be, when I was younger (and probably rated it), but every query I made in the last five years, the very first thing was a test.

In a couple of instances, it was a sensible, applicable “take-home” test, but usually, it was a schoolboy binary tree test.

I interview very well (on account of over 30 years of relevant ship experience, and I’m actually a fairly decent chap), but it has never gotten to that point.

BTW: if it isn’t already obvious, I’m quite senior, and have been architecting, as well as writing, software, since my very first project, in 1987.

I was quite willing to work for a lot less than many folks much less qualified, on account of having my retirement set, and was looking for interesting and engaging work, more than money; but it never got that far.

I won’t waste time practicing LeetCode. I don’t think it would make any difference, simply putting off the inevitable rejection. It’s not something that helps me to write better shipping code.

I recently had a lovely “take home” test, that I was supposed to finish in 2-3 hours.

If I could just build them a feedback system for their employees. Including backend, frontend (as a SPA please), and tests.

Of, of course they didn’t expect me to actually finish, 5 API’s and 3 implemented front-end pages would be ok (and tests, of course). Also, could I maybe make it look nice?

I dunno, for some reason I saw it as a challenge and actually tried. But after 3 hours I was forced to concede that even using a full framework and CRUD generation for most of the app the idea that you could finish was ludicrous.

I spent an extra 30m writing up a review of the process and attached that as a ‘cover letter’.

Unsurprisingly I didn’t get the job, but I guess I consider it a bullet dodged now.

I have a take home test right now, that I should supposedly be able to finish in 2 hours.

Just setting up technologies that I have never used on my local machine and trying to understand them has taken me several hours.

It seems unlikely I will submit anything.

Do they actually expect someone to pass this? I am honestly curious what the hire rate is at a place like this.

They expect you to take 2 days on it. Ie cheat. I refuse take homes on principle at this point, as I know I’ll be working with a bunch of cheaters if I do get the job.

I had one take home at some point where the interviewers didn’t believe I actually did implement their thing in 6 hours. Everyone else took two days :/

So you’re given 2-3 hours, but expected to take 2 days?

If my experience from the other side is transferrable then no, they do not expect it to take 2 days. They actually mean what they are saying.

Unfortunately they are developers. They underestimate how long it will take. They didn't actually try it themselves. They might even have modeled it after a piece of software they did build in-house and thus underestimate even more.

I had to advocate very strongly on cutting scope from our take home test and multiple times argue against 'extensions' of the ask.

I like take home. It's a great way to talk about their code. Have them explain choices. Pros and cons. And yes tests please. What I look for is not complete test coverage or having 27 classes that all have pseudo tests. Have one class with _good_ tests. Show that you understand what is important to test and how to do that. If you know how to do that, I can hire you to repeat it for a salary.

My own last take home I sent in didn't even run because the implementation assumed various external services that I didn't bother implementing or mocking out enough to make it all run. I put lots of comments explaining various choices and what I'd expect those external services to do though. Was a great topic started about code comments and which ones I would leave in actual code and such.

The problem being of course, that from the applicant side you don’t know if they mean it or not.

So you’ll be competing with people that implement the whole thing regardless.

Now I’d like to think that interviewers are entirely impervious to that, but realistically, it’ll hurt the chances of those that do it only halfway.

Try it. I can tell you from the other side that if you know your stuff your evening (2-3 hours) output will be way better than many that take 2 days.

If you don't try you've already lost.

I share the same experiences. Only around half of your (temporal) experience and every conversation with a recruiter ends the same way: "When can we schedule you for a technical screening? You'll probably want some time to brush up on leetcode as well".

My experience doesn't matter. The fact that I've now worked at (and currently work at) 3 of the big tech firms, doesn't matter (to be fair, I only got jobs at these places back when I was willing to grind out leetcode and memorize as many problems as I could - a task which I refuse to do today). The fact that I have a history of leading teams, areas, and spend at least 50% of my time also "writing code" for high performance, high reliability, global services, --and-- can speak in depth regarding my accomplishments, design decisions, technical decisions, collaboration, etc. doesn't matter.

The only thing that matters is: Can I pretend like I've never seen this toy leetcode problem before during an interview, and magically come up with a perfect solution in 30 minutes or less. (and if I haven't happened to memorize it, and dare legitimately appear to struggle, well... game over).

Leetcode and equivalent seems to come out of an intersection of a technical interviewer's "I don't want to take the time to interview you" and HR's "I don't know how to interview you."

Everyone knows that something very serious must be done at an interview. Nobody cares about it enough to actually put in the time or trust for a bespoke solution.

Consequently, you end up with everyone sub'ing algorithms in for due diligence, then because they made that choice, defending the choice and pretending like it's meaningful.

Hiring is hard. Hiring technical, non-standardized talent is even harder.

> I was quite willing to work for a lot less than many folks much less qualified, on account of having my retirement set, and was looking for interesting and engaging work, more than money; but it never got that far.

Did you think to work with blockchain? It has a lot of engaging problems, and you can start even without getting hired. It ranges from helping out DAOs in open-source and getting paid in tokens; to starting off your own small project and building a community.

As for the jobs, the compensations has been through the roof lately – the field doesn't get new developers nearly at the rate needed

It looks interesting, but it's not really what I like doing.

I enjoy working on stuff that people use. Things that the user interacts with directly; like UIs and devices.

I did a bunch of work with Bluetooth, OBD, and ONVIF (surveillance), but I'm working on what is sort of a "social media" app, now. I wrote the backend for one of the servers we use, and was the original author of another of the servers. These were big projects.

The interesting part, however, is the iOS app that I'm developing. Trying out different ways of presenting to the user, and interacting with the user, is a lot of fun.

> It ranges from helping out DAOs in open-source ...

Do you know of any good articles or guides about getting started with this for complete beginners to blockchain?

I am an extremely accomplished engineer: 40 years developing professionally, over 40 published consumer software titles, I've written from C/C++ the entire critical path pipeline for multiple animation studios... yet in a recent job interview the moron interviewer says to me mid way through "sounds like you're tech light, do you even write code?" (cue a record scratching) After questioning, this person has no idea my describing 40 years of professional coding was writing software - this HIRING MANAGER did not know any of the terminology I used describing being a key player in the transition from optical and video to all digital media productions everywhere. How to describe a successful career when that very success eliminated the reference points for what the career was, now it seems like we made the air itself as the digital media takeover was 100% successful, the young hiring managers have no idea what the world was before we (the developers who lived through the 70's to 2000's) changed everything.

I am sorry you went through that. I can relate.

Today, we have “jargonauts.” These are folks that key on certain terms and acronyms.

I remember, back in the 1990s, hearing everyone gushing about “AJAX,” and wondering what the big deal was (after being laughed at, for not knowing the term). No one would explain what it was.

I looked it up, and go “Oh, they mean HTTPRequestObject!”

Turned out, that I actually already knew a lot more about “AJAX,” than most of the folks gushing about it, and the reason no one would explain it, was that they didn’t actually understand it.

Lot of that, going around…

Sounds like today's "dependency injection", and people writing 5 pages on it.

Except then it turns out what they mean isn't DI, but some other concept related to it and largely taken care of by their framework of choice.

It also sounds fancier than it really is. "Dependency injection" can literally mean just passing some arguments or setting properties on a hash. The target doesn't even need to be a singleton or long-lived. Honestly, I've never found the term particularly useful. The meaning is so amorphous that it could really just be described as a form of decoupling. But it sure was great to say it during interviews early in my career!

Indeed, it is simply passing some dependency as a parameter.

Personally I find DI to make it harder to reason about in a sizeable portion of cases (20ish%) without actually providing a benefit.

So that makes me prefer going for rejection (Passing the result of the dependency instead of the dependency itself) or just keeping it there.

Altough, those approaches depend heavily on the rest of the codebase. (FP makes rejection relatively easy for example)

DI makes testing nice. People approximate it with hacks, but you need DI for truly good unit tests.

Really depends on the whole structure. If it is mainly FP, dependency rejection usually is actually the easiest to test with

I dunno how you can combine dependency injection (as I imagined it in the original comment) with FP in the first place.

Without classes what would you be injecting? Other functions? That’s still something that happens all the time in FP.

I was thinking sideeffectful functions. Such as DB accesses.

> dependency rejection

That’s secretly the most powerful design strategy.

It objectively isn't, as there are certain things you can't do with it.

Altough, for usability it is IMO definitely the best.

> setting properties on a hash

Nowadays it's called a dict.

The term AJAX was coined in 2005 by https://web.archive.org/web/20150910072359/http://adaptivepa.... People had been talking about the idea for a few years at that point, but not with that name.

Might be right. I would be surprised, though. I do remember that it was a "brand new" buzzword.

Not worth fighting over. Time is flying, and even the early 2000s was a couple of decades ago.

Did you really hear anyone talk about AJAX in the '90s? Looks like there was some work done on XHR in '99, but it seemed to roll out across browsers in the early '00s and seemed peak hype when I started my career in the mid '00s, after the Web 2.0 conf in '04.

AJAX was a catch-all term meaning “the page does things without reloading the whole page” if I remember correctly - or that’s how people were using it.

It may have been the early 2000s, but it was very early on. It "came to a head," on a trip to San Francisco, on one particular project (I am not at liberty to discuss). It would not have been beyond about 2002. I think it was pre 9/11, but my memory of that time is a bit fuzzy. I did a lot of traveling.

I'm pretty sure that HTTPRequest debuted in IE 5 or 6.

The way I remember it is it became widely known once gmail and google maps shocked everyone with its effective use. So that's quite a bit later than 2002. But it's likely that it is just when I noticed, being pretty far removed from web development at the time.

AFAICR, it started in the mid-to-late 90s, although as with all things web in that period, was a non-standard cobbling together of feature and functionality using whatever technologies were available, while browsers themselves lurched in the dark and added features.

It's more akin to saying "We want to do this thing that's never been done on the web before, and no one ever thought to do. How do we assemble it out of this box of scraps that HTML and browsers currently give us?"

Consequently, there was probably proto-AJAX with ActiveX, the early js landscape, and iframes. But it would have certainly depended on where you worked.

Critically, internet connections were much slower (in latency and bandwidth), so partial page loads were more of an advantage.

Just to set the record straight, the skeptics were correct. I was off by 5 years.

I asked someone that was on that trip with me, and it was late 2007.

You know how it is, with us doddering old geezers; we forget stuff...

As a game engineer I can relate. Many of these deep technical areas are completely unknown to people outside of gaming / modeling / animation / graphics, and even then you are way outside my expertise with optical/pre-digital work. It is a great point that interviewers focused on typescript or redux (just to mention stuff worth knowing but that seem far from C++ graphics coding) won’t get the nuance of your technical contributions. It then becomes a storytelling challenge, which is a different interviewing skill entirely.

I was on the OS teams of the 3D0 and the first PlayStation, 2/3rds of my published software are console games. My games stint was the EA Spouse era.

EA Spouse... that takes me back to the time when I decided to let my dream of becoming a game developer remain a dream.

As someone with a similar time in harness in industries that rhyme with that, I feel your pain.

While I'd prefer to work, not needing the money implies the ability to avoid the interview process. It's a funny thing being in an industry where people retire not because they can't do the work at a professional level, but because getting a job is such a PITA.

> It's a funny thing being in an industry where people retire not because they can't do the work at a professional level, but because getting a job is such a PITA.

I feel that this is a desired result. I am pretty convinced that folks like to have an "ideal culture" at their workplaces. I hear the term "cultural fit" so often, that I guess it means something that I'm missing.

https://www.youtube.com/watch?v=G2y8Sx4B2Sk

I've had to use a binary tree couple of times. And when I did, I recognized the problem as a binary tree problem, and I read up on binary trees, and then used them. For about a month after, I'd have been able to do a lot of tree operations on the spot. Then the the material gradually faded from short term front loaded memory, and my long term memory stored the relevant awareness of the problem so I'd identify it should I have to look it up again.

I was asked to sub for a PSE interview on short notice, so I did my usual fizzbuzz routine. Even that felt kinda goofy asking this excellent senior guy so I asked it with a bit of apologetic tone. The guy smiled with a twinkle in his eye and solved it the best way I've ever had anyone do it. We chatted about SRE topics the rest of the interview. Sadly he didn't end up accepting but I appreciated the good humor.

I once had an interviewer wax poetic about fizzbuzz, the multitude of ways to solve it, and what he considered to be the most elegant of answers after I gave him a solution. I was sitting there thinking "I think you've missed the forest for the trees here buddy" but just smiled and nodded.

The whole situation is quite pathetic.

Ok now you gotta spill the beans, what was so entertaining about the fizzbuzz solution?

It was not literally the fizzbuzz problem, just a relatively simple problem I use for interviews. He solved it quickly, with good taste, and described some faster alternate approaches that I didn't hear from anyone up to that point.

Sorry it's a boring answer :-)

You make me want to come up with a working algorithm that actually hints at the Kafkaesque futility of algorithm interview questions.

> but have yet to run into a time where I needed to understand or write a binary tree.

I ran a UI team for 3 years, we built a UI framework, then the UI and apps on top of it.

We lived trees and tree traversals. Understanding trees was essential to everything we did.

Do I ask people to balance trees? No, but I do care if people can understand traversals, and also how to manipulate and design tree structures to solve business problems. Being able to design the right data structure to solve a problem is an important skill, and trees are one of our fields fundamental data structures.

Not surprised, but not everyone writes frameworks. I write end-user apps. There's a lot of us, out there.

I have written quite a few frameworks, SDKs and APIs; both server-based and host-based, and never had to deal with this stuff. If I had, I would have done what I always do, when I get to that point: Learn what I need to learn.

I have been learning new stuff, my entire career. I don't know how to do almost every project I take on. I even wrote about it, here: https://littlegreenviper.com/miscellany/thats-not-what-ships...

One of my favorite questions to ask is how to find the first cousin of a node in a binary tree.

A lot of people try to start at root, enumerate the level of nodes for the entire tree, and then return non-sibling nodes at the same level as the node we want to find the first cousin of.

Which works, but it is O(n) and a lot of work. People who know about parent pointers in trees just walk up a couple levels and then down a couple of levels.

I consider it a fair question because, it has no gotchas, it is just understanding how to efficiently walk around one of the most commonly encountered data structures.

My other go to question is provided a library function that can schedule a callback to run anytime in the next 2147483ms, write a wrapper that can schedule a callback at any arbitrary time in the future. For advanced candidates I provide a library of date/time functions and they have to take in a date/time and using the provided limited functionality scheduling callback, call the passed in function at the proper date/time.

This is a very simple problem, and one that I've encountered in real life[0].

It is a trivial, but again real life problem of building functionality on top of a limited platform API. I have seen this question trip up countless candidates, who try to seriously over model the solution. I have no idea why a class with 1 function and a couple int64 variables counting down time seems so hard!

(Old school C programmers tend to get it right away)

[0] Windows timer APIs like their 100 nanosecond parameters, though now days they all have modern 64 bit FILETIME variants that side step this entire issue.

Oh no, there’s no bypassing the crap anymore with companies you don’t know personally.

Reply on news.ycombinator.com