3 ms·
I think the "fake product" interview is a great format, but it can be done poorly if the setup is unrealistic. I've been on the receiving end of a couple of ver
by dkarl 3y ago
I think the "fake product" interview is a great format, but it can be done poorly if the setup is unrealistic. I've been on the receiving end of a couple of very bad attempts.
In one, which I have described here before, an interviewer asked me to design a system for selling concert tickets. After half an hour of confused back and forth, it emerged that they wanted a network service that replied to requests with unpredictable random integers, which did not repeat, unless the service rebooted and then it was okay if there was an accidental repeat. Needless to say, I started with a lot of assumptions based on the idea of selling concert tickets, and I don't think it reflected poorly on me that it took so long to figure out that the real problem they were judging me by was so radically different from the one they asked me to solve.
I had another interview recently which had a similar wrinkle. The interviewer asked for a system to solve a very particular problem, which because of the particulars of the problem would involve receiving very small amounts of data from systems in the field. The interviewer asked multiple times about the cost of data ingress and data storage, and each time I deflected them, saying that it wasn't significant compared to other costs in the system. I was so focused on solving the problem as stated that it didn't dawn on me until later that the interviewer likely had a different problem in mind in which the data was much bigger, and they were evaluating whether I could be sensitive to those costs and design an economical system.
Interviews like these are very frustrating, and I don't think they will lead to great hires. You will end up hiring people who solve the problem you have in mind even though you told them to solve a different problem. These programmers will have the same biases and preoccupations as you, which might make them easy to incorporate into your team, but they will probably have the same blind spots as well, which means your team will be less prepared to solve new problems in the future.
- ascar 3y agoTo be fair, I would say if your task is to design a system it's your job to find out what the person actually wants and not run with assumptions you made based on a bad description. The reality is that you will usually start with a bad description. So I'm not sure if these misunderstandings actually reflect that badly on the interviewer/the question.
- dkarl 3y agoI think if they were testing my ability to work through misunderstandings in requirements, they would have been decently impressed that I got from "system for selling concert tickets" to "system for giving out random integers" in half an hour. But they weren't impressed, they were irritated. Edit: Also I don't think a normal product requirements discovery process involves figuring out that you're actually being asked to solve a different problem in a vastly different domain. You shouldn't ask someone to build Netflix while thinking "let's see how long it takes them to realize I meant Twitter."