[lubujackson]

This question, and many "but make it a bit more challenging!" comments always strike me as CS101 navelgazing type questions. The best part of this question is that it is simple and can be used to swing into deeper concerns but it is still at odds with actual job responsibilities - even more so with LLMs in the mix.

Maybe this is because I have only worked at startups, but I am much more interested in if someone can read and understand code, where they feel logic is brittle, overly complex or badly designed. If they understand, even conceptually, how adding an optional field to an endpoint may be fine but removing one needs to be phased out or considered for active users. If they consider downstream risks, if they understand business goals and how to communicate limitations or opportunities.

Instead, every single tech interview seems to focus on how well you paid attention in your CS seminar which might be a reasonable screen for junior employees but is awfully irrelevant for anyone >3 years in the industry.

There are far too many corners of logic for everyone to know. Maybe someone has never dealt with data streams, or even forgets what a median is. You want to know if they are sharp with statistics? Great for some roles, wholly irrelevant for many others.

Engineers need to communicate, read and understand logic and how things connect. And the golden skill: willing and able to learn something new.

[strken]

Hiring funnels at big companies are funny because they're all about stacking filters together in a way that optimises some random grab bag of metrics in the candidates who make it through.

One of those metrics is "number of people hired who literally can't write code". You'd be able to give these candidates a full description of what the median is and they still wouldn't be able to finish this question, and you're not going to get too many false positives, so you add it to your rotation as the first question and have an enthusiastic mid-level engineer do it as the first half-hour round of an interview.

Then you design a few more rounds to test for the positive things you want, like pair refactoring, architecture, lunch with the team, or whatever floats your boat. That way your senior engineers don't need to interview people who can't write code and you stand a lower chance of accidentally hiring some of them.

[Traster]

I think there's two elements to this. First - all the things you list are important too, and we'll get to that. But there's no point in getting to those things if the candidate can't write 5 lines of python and has no idea how the language operates.

Second, hiring at startups is massively different to hiring at big companies. At big companies you have a website and a linkedin and a recruiter and external recruiters and they're all funnelling CVs to you dozens at a time. You're glancing over a CV and if it looks roughly right you'll do a phone screen. People lie on their CVs. So you need a few questions like this just drop the 90% of candidates who have literally no chance at getting the job. Keep in mind, the external recruiters will interview the candidates you reject, find out your interview questions, find the answers and tip off future candidates.

We're also hiring for a different set of skills. At a start up everyone is doing everything. Does it matter how well you can talk to customers? Maybe! That could be useful. In a large company if you ever talk to a customer as an engineer you will have been at the company for years, you'll have a Sales guy, Technical Sales guy, an Account Manager, your manager, and maybe a Project Manager all in the room if you ever get to see a customer.

[kccqzy]

> There are far too many corners of logic for everyone to know. Maybe someone has never dealt with data streams, or even forgets what a median is.

Bad interviewers expect candidates to know things. I don’t. It’s okay for a candidate to have never worked on data streams or to forget what a median is. I simply provide the definition and continue. I care about the quality and effectiveness of thinking. If the candidate can be given a definition and then immediately turn that into code, that already shows that they are good at logical reasoning. It’s basically the same kind of thinking required when there is an urgent request at a startup and an engineer is pulled in to come up with a solution quickly; all the business logic will be new and you want someone who can learn quickly, internalize quickly, and produce results based on these learnings quickly. Therefore in my opinion asking these interview questions are actually a good indicator of how they will perform in a hectic startup environment.

[gedy]

No no, see those are all softball questions, and the only way to prove they are not coasting fakers or liars is to quiz them like this. /s