Hacker News new | past | comments | ask | show | jobs | submit login
Routing the Technical Interview (hupel.info)
117 points by zdw on March 13, 2021 | hide | past | favorite | 55 comments

It seems like most of the commenters have not heard of Aphyr's technical interview series.


Specifically, "Hexing the Technical Interview" has been a favorite of mine for a long while. The writing alone is a lot of fun, and the contents are appropriately horrifying.

What is more worrying, they didn't even click on the acknowledgement link at the bottom of the story.

Though the prose is not at the level of Aphyr, the Cthulhu abominations in it are still admirably terrifying.

This doesn't quite have the magical soul of Aphyr's ones, unfortunately. https://aphyr.com/tags/Interviews

It started off original enough I felt. It had an idea of its own, but very quickly just ended up copying the style, without really hitting home.

Still, I can't fault the author for giving it practice, and it is amusing enough to read.

It's like one of those "shooting your foot off in programming language" joke setups. Infinitely extensible for any roundabout way to solve FizzBuzz as possible. The ones imitating the originals' style might not be as good, but they're certainly welcome for capturing more types of unwieldy solutions.


Alternatively, for a more tech interview specific, "how to measure the height of a building with a barometer?", fifth page from the end of this document:


Not quite Aphyr but I found it witty and funny nonetheless. It was a fun read.

This story would make a great culture test! "Would you hire this candidate?"

You only want to work with team leads who agree with your answer, whatever that might be.

Personally, I love working with folks who enjoy playing with technology, so I'm a Hell Yes. I don't see a lot of risk that this candidate would actually try to ship that regex to production.

I've worked with a few folks who are very talented, but only motivated by learning and working with new technologies. Even if they are enjoyable to work with in the short-term, they'll lose steam and saddle the team with doing the last mile and maintenance work. It may be okay to have one or two of these folks depending on team composition and sentiment, but generally I steer away from them.

I think you nailed it that it's a team composition question. Too many folks like that is a problem, just like too many folks who hate the pain of bleeding edge/messy/unstructured work is a problem.

I would be a "hell no", because I know people like that are infuriating to work with if you're trying to get shit done. I love programming and discussing programming trivia and etc, but on a team you also need your coworkers to work with you towards a common goal in a rational manner, keeping in mind performance, maintainability, stability, team knowledge, time constraints, customer expectations, etc. These are not skills this hypothetical candidate displayed.

Missed an opportunity to call it "Governing the Technical Interview"


> From Middle English governen, governe, from Anglo-Norman and Old French governer, guverner, from Latin gubernō, from Ancient Greek κυβερνάω (kubernáō, “I steer, drive, govern”)

"The interviewer couldn’t help but notice her name, Nephele. It sounds Greek. But he didn’t ask, not wanting to get off on the wrong foot with the promising candidate. He made a mental note to look up the name afterwards."

Sad, I'm so guilty of doing exactly this - right away. I love etymology / genealogy, and am always curious.

Its in no way negative, its literally just my curiosity taking over. Sometimes I hate how ridiculous we've become.

One of the best practices I’ve picked up in interviewing is to ask the candidate their name at the beginning of the interview and then use it a few times during the interview. Usually this is is done with a quick “Before we get started, I want to make sure I’m respectful of you. Is there a preferred name that you’d like me to call you?” While it doesn’t get at the etymology of the name, at least it ensures that you’ve got the pronunciation correct.

I’ve seen some people be at an employer for a couple of years with everyone mispronouncing their name because they didn’t want to correct people.

Sure, I have this curiosity, too. But in the context of being an interviewer, it's not about me. My job is to fairly evaluate someone who's just trying to figure out if this is where they'll get their living from.

This industry is so screwy, sometimes.

I am doing a lot of technical interviews, and it is very hard to find a good way to evaluate candidates. My current thinking is to ask a simple question which serves as a jumping off point to a bigger discussion touching on broader topics. I want to be fair to candidates and I certainly don't want the interview to be a trivia contest, but at some point I need to see if the engineer has a general grasp on how software works in a larger system.

Yes; this can work well but its a little noisy as a signal. (There's plenty of room with this sort of assessment for personal bias based to creep in based on whether or not you like the person).

My recommendation is to make a list of attributes you want in a good hire. (My list is something like: coding, debugging, communication skills, CS fundamentals, systems architecture, domain knowledge for the job, ...). Then spend 20 minutes with each of these areas brainstorming simple ways you could assess that skill in 20 minutes or so. (They're all assessable, but you need to get creative). Then after you've done that, design an interview from your notes.

If you've got 1-2 hours for the interview, you'll end up with something much better than just having a chat. (Though on the flip side, if you've only got 10 minutes for an interview, a question like you suggest can be great.)

Totally agree. This is the basic approach I advocate for (https://m.huffpost.com/us/entry/us_7973484).

I'd further argue that one of the best bets is to get someone to tell you how they have applied a skill in the past, rather than to try to figure out how you can get them to perform a facsimile of the skill in 20 minutes.

I had one of the better interview experiences of my career a few weeks ago---the interviewer pasted a bunch of code in my editor and said, "Tell me why this code sucks."

(it had credentials in the source code, was mixing different concerns all over the place).

I don't know, I was quite a fan.

We’ve entered dating territory. I have to date you. I need to match you.

Yeah, I’ll just focus on Leetcode and focus on the big companies.

I’m not dating you bro, it’s just business. In other words, apprenticeship is dead (for awhile). We will not cater to you.

I wrote a regex engine, had to create a huge autogenerated test suite to flush out all the corner cases. The typical matching rules are fiendishly difficult—this is a nice illustration of how much deep magic there is in our quotidian stacks. I am looking forward to digging into the two complicated patterns to understand how they work.

What is left to do with the Technical Interview?

I have yet to see anything more horrifyingly beautiful (or, beautifully horrifying) like this: μkanren in lisp in prolog ?!!


"Nephele was a nymph moulded out of clouds by Zeus in the shape of the goddess Hera."

/facepalm That's hilarious

Kubernetes is an intentional mistranscription of κυβερνήτης (cybernetes), "helmsman". One assumes the spelling was chosen in an attempt to avoid the word "cybernetics".

This is presumably why Nephele is confused when the interviewer interprets her self-reference "helmswoman" as a metaphor.

the article is so good it just doesn't swoosh over, it beams little brains directly into the mothership

Terrible - which I assume was the point.

The interviewer is clearly trying to do the right thing (own laptop, well known problem, your choice of tech) and the candidate is clearly talented, but the result is an unmitigated disaster.

Obviously the interviewer should have provided more direction on the expected solution and the candidate should have focused on the simplest solution not the most unusual.

But - I think these technical interviews are a lot more about "did the candidate approach the problem the same way you would?" rather than "did the candidate solve the problem?" than we would like to admit. (Again, probably the point of the tale)

I think the point of the name Nephele (from Greek mythology) is that the candidate was sent to test the interviewer.

> Obviously the interviewer should have provided more direction on the expected solution and the candidate should have focused on the simplest solution not the most unusual.

The quote "The company does not need thinkers, they need doers. Mathematicians just examine made-up problems. But at this company, the engineers build real products for real people." from the interviewer suggests that the interviewer only wants to hire a devops person with a standard bag of tricks. The candidate has a bag of tricks in the relevant domain, but what a bag of tricks.

> these technical interviews are a lot more about "did the candidate approach the problem the same way you would?"

honest question, I can only evaluate the correctness of a thing if I am familiar with the tech the candidate used to answer the question. Is this being unfair? Should I instead use the technical interview as a time to do as much information gathering as possible then take it back to the wider technical team for evaluation (provided I am not able to understand the technical answer myself).

I think turn this on its head - You're not trying to evaluate the correctness of the thing, you're trying to evaluate the value add of the candidate.

So instead of you trying to judge the value of the implementation based on some undefinable "technical correctness" have a discussion about the what the candidate has done/built.

In this case - so many opportunities for great discussion around the tradeoffs of this approach:

- What sort of load does it handle?

- How portable is it?

- What does developer setup for this environment look like, and what tools might you need to introduce the team to for them to be productive?

- What might you do instead of this if we had requirement X, or challenge Y (ex: Network latency, computations/second, real time processing requirements, tooling/language constraints, etc)?

- What are the scaling costs?

- How do you put tests in place?

- Etc.

And then you expect to receive believable answers, and interesting conversation. Because at least in this case, it's pretty trivial to determine that the solution either does or does not work for at least a small subset of fizzbuzz.

It can be really insightful to step back from the expectation that an interview is always "Interviewer is more experienced than interviewee" and instead just try to get an understanding of what working/talking with that person is like.

For context - I've done about 150 software dev interviews over the last two years (principle/senior to junior/intern)

I wouldn't call it unfair, but if you're giving the candidate the option to solve a problem in their language of choice, you may run into this. You can either constrain the problem (we work with languages X, Y Z, so pick either of those) or still give them the option but use it in another way.

For example, I work in front-end but I do most interviews across front-end, back-end, devops, always together with someone who's familiar with the domain or the specific stack we're recruiting for. In that case I'm there to test more on softer skills, but also its a good test to see if a candidate can discuss their domain with someone who isn't familiar with it.

If the candidate is using a tech you’re unfamiliar with why are you interviewing them?

In general* you want people who claim familiarity with the tech they will be using in the job. And if that is the case but you aren’t familiar with that tech (you work on a different part of the stack, say) then you shouldn’t be wasting their or your time having them code something up but instead you should be asking them about the parts which are the reason for you to be one of the interviewers.

* yes there are several exceptions to this but they are exceptions.

> If the candidate is using a tech you’re unfamiliar with why are you interviewing them?

did you read the article? Did you see the comment I was replying to? The gist is that a candidate may know other things that I don't and still successfully answers the technical question. Just because it wasn't using the tech I would have used to solve the problem doesn't mean they're unqualified. Not saying that's what you're saying, I'm just repeating explicitly what I only implied earlier.

It read to me like a breakdown in communication. It wasn't made clear what the interviewer was going to get out of having the candidate solve fizzbuzz. The candidate demonstrated that they understood the question well enough. But it seems they wanted to demonstrate the technologies they were familiar with, rather than give a simple answer.

From the interviewer's inner monologue it seems clear he wanted to prove the candidate had the most basic of skills for the job. It may not have been in the candidates mind that she was being asked such a simple question.

The interviewer identified ego and arrogance very quickly, that’s why the interview ended in his mind early.

On a sufficiently relevant problem with reasonable difficulty and depth, I think these human elements would disappear as the problem set requires too much concentration.

The interviewer wanted to end it because the question he asked was ‘Are you too good for this?’, and the interviewer replied ‘Yes’.

Which oddly, is an honest answer. I feel sad, if the candidate did the fizzbuzz as asked, they wouldn’t stand out on any level compared to all the other people that did fizzbuzz as asked. God knows what the other evaluation criteria is. Clearly the resume and a background check is not enough, because they still fizzbuzzed her.

Historically fizzbuzz was meant as a sanity check. Can this dev code a simple for loop with some conditionals in it? It was made up because some dev realized that too many poor candidates were making it to late stages of his hiring process. It’s not meant to make candidates stand out, it’s meant to be a practical filter. My personal experience as a dev is that my weakest teamates would visibly deflate anytime a work problem came up that required a simple for loop, so it’s not a terrible bar to filter on.


I mean, we are saying that job experience doesn’t mean anything based on anecdotes. The power of the narrative is intense.

Some of you dealt with candidates that can’t make it through a for loop, okay. This one ghost story dictated the entire direction of hiring.

We are superstitious at this point.

> she opened VS Code

Until this point I had been expecting that she was an Emacs user and would use an arcane series of shortcuts to scaffold the entire YAML file...

1. What is fullstack mean in devops world?

2. Didn’t her resume give enough information about her background?

This was the most engrossing article I've read in a while!

Seeing the regex made me chuckle.

I really wish someone like Joma Tech would turn this into a video. Hilarious.

I hope she didn't get the job. She over engineered a simple problem into something hard to understand and maintain.

She got the job, and she's been leading the team in scaling for the last 3 years in anticipation of getting their first customer.

If you are asked a stupid question it is reasonable to give a stupid answer

This seems to be a case of "there is no such thing as a stupid question". That does not rule out stupid people asking questions, though.

I’m trying to find out who the hero of this story is.

> hard to understand

The "normal" approach is to define a function which takes some kind of input and exhibits side effects but doesn't return output.

The approach here is to define a webserver which takes input in the form of a URL path and delivers output in the form of an HTTP response body. The differences are:

- the input is considered to be a string rather than an integer

- the output is returned rather than swallowed

But I don't really see that one is harder to understand than the other.

One is harder to understand than the other because it requires knowledge of YAML, Kubernetes, Nginx, httpbin, REST, and extremely complex regular expressions. It also has many dependencies.

The problem can and should be solved in a handful of lines of code at most, requiring knowledge of nothing more complex than the modulus operator and simple Boolean logic.

If this wasn't a story I would completely agree with you, but lets step back a bit:

- You're hiring for a DevOps position - You use kubernetes to orchestrate your system

The test you do is FizzBuzz (? because that'll help you when your cluster is on fire). Along comes someone that seems to be way way better versed in kubernetes than anyone alive.

They use exactly the tools they'll be using day in and day out for their devops role. Hell, they implement FizzBuzz AS A SERVICE with kubernetes alone. And you pass it along.

Now ofc, in a real world situation you wouldn't want a person that when asked to implement a regex spins up a cluster and you do mention you have "Go" on your stack, so the easiest way would probably be to do a Go program, the thing still remains that for what it seems they were hiring, this person would be an amazing hire? You also say, "use any language", so the person could simply have thought - "well, this is for a devops position using kubernetes, I'm going to show you how much I understand this to the point your brain will melt"

That's why I think the story is good, it can be looked through quite different angles and it does pose some questions regarding the problems we use to proxy knowledge in a given domain/tool and also how we can access in a valid way someone's knowledge within a domain/tool when, and if, we ourselves lack considerable knowledge in that domain/tool. Maybe the person you end up hiring does the normal FizzBuzz in go and in all other areas is a better "hire", or culture fit, but when Kubernetes is burning they might not know how to put off the fire.

> One is harder to understand than the other because it requires knowledge of YAML, Kubernetes, Nginx, httpbin, REST, and extremely complex regular expressions.

I don't really think this is right. Saying that understanding the presented solution requires knowledge of YAML, Kubernetes, and httpbin is like saying that understanding a solution in C with printf requires knowledge of file descriptors and terminal control codes. That's stuff the solution is built on, but you don't include it in your understanding of the solution.

Ask your interview candidate how printf works, and odds are they'll be stumped. But if we don't require that in order to understand the printf solution, why do we need to understand how the primitives of the Kubernetes solution work in order to understand that solution?

I hope she did, it’s a contrived problem and thus a contrived solution is okay. Sure, it’s clever but you have to give some credit for having the “ovaries” to go with it.

Technical types should rarely, if ever, try to write fiction, this is a prime example. You could forgive the old masters in SF because the ideas were great and they have lots of practice after all so the prose was mediocre but tolerable.

So much judgement. Just like with programming, The way to write good fiction is to first write a lot of bad fiction. Its not a matter of being a 'technical type'. Its practice.

Andy Weir (author of The Martian) is a 'technical type' and The Martian was fantastic because of his nerdy mind. His book drops with his love of STEM and all the research he put into it.

The world needs more fiction by programmers; not less.

The Martian is pop-fiction pablum, it does not stand up even in science-fiction, a genre notorious for its lack of literary quality. He made the big $$$ so good for him. Pablo Coelho, Dan Brown and Stephanie Meyer did the same though.

You must be tough in a code review.

Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact