alt Hacker NewsThis 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.
Replies
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.
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
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.