That makes it even better, the candidate should ask clarifying questions. I've worked with people who, when encountering some amount of ambiguity, either throw their hands up, or make some random assumptions. Ability to communicate effectively to bridge the gaps in understanding is what I'd expect from any candidate, especially more senior ones.
But that doesn’t work. One could ask why server can handle only one request? Why can’t we upgrade (vertically or horizontally) the server? Why the logic needs to live in the client? And a large etc.
It’s not the ability to communicate effectively that’s at play here, it’s your ability to read your interviewer’s thoughts. Sure thing, if you work with stakeholders, you need some of that as well, but you typically can iterate with them as needed, whereas you have a single shot in the interview.
Plenty of times, at the end of the interview, I do have a better mental picture of the problem and can come up with a way better solution, but “hey, 1h has already passed so get the fuck out of here. Next!”
> One could ask why server can handle only one request?
I've tried that approach in a couple of interviews and, no surprise, I did not get those jobs because interviewers really seem to hate it if you dare step outside the little cocoon of leet they've constructed.
Those are bad questions. The task is given, you're asking why do I have these constraints - obviously you have them because they made them. Without the constraints there's no task.
It doesn't matter why you can't fix the server, you can't fix the server. It doesn't matter why it can only handle one request at a time, it can only handle one request at a time. That information doesn't change the solution to the task. Make up whatever you please - maybe it's a third party system so you can't access the code. Now try to come up with some useful questions that actually help you solve the task instead of wasting time asking pointless questions.
No wonder people reject you if this is how you approach interviews. Maybe it would make sense to ask these kinds of questions in a real work scenario, but it does not make sense in an interview where you are given a made up task. Just accept the constraints and solve the problem. You sound like a high school student being intentionally obtuse, like you came into the interview thinking you're too good to be evaluated that way or maybe you just don't have a clue how to solve the actual problem you're given so you try to stall to avoid having to admit that you can't do it.
On the contrary, these are great questions to raise at the start and I'd absolutely rate a candidate better for asking them. Too many of my coworkers solve the wrong problem. They treat the symptoms instead of finding the root cause, and so we end up with a fragile patchwork of dirty hacks that get cargo-culted into other code bases.
That being said, the time spent on these questions should be minimal. It should go something like:
Candidate: It seems like we're solving the wrong problem. Why can't the server handle multiple simultaneous requests from a single client?
Interviewer: Its a 3rd-party server we don't control. (or even just a "because those are the artificial constraints for this puzzle" if the interviewer is feeling particularly lazy)
Candidate: Ah okay. <proceeds to work on the problem>
Sure, that's completely reasonable. But getting hung up on them for an hour is ridiculous.
I also think they're unnecessary in the first place. I wouldn't hold it against anyone in a scenario like you described but I also wouldn't expect it. Solving the task as it's posed is good enough.
I might just mention that my first instinct would be to fix the root of the problem instead of asking about it, I wouldn't expect the interviewer to have spent time world building for their made up task.
Sure, but this isn't a back&forth interview - it's a blog post. The author could have included a section with clarifying questions they expect the candidate to ask, and responses to those questions.
As it stands, we still don't know why the server was broken in this way and why they created a work around in the client instead of fixing the server.
How can you know that? Please don't assume stuff about others just to make a rhetorical point. If you say it's not that common as it's often made out to be, why wouldn't I believe you?
Though what would also help if you had an explanation for why we tend to hear these stories mostly from the US and not from other countries.
I see plenty of stories from Europe, and they too complain about work, but never about having to work 60-80 hours. Even if it's rare in the US, it still seems more common than in Europe. Similarly, I hear stories about working 3 jobs in the US which I don't hear from Europe. I do hear people complain about managers, pay, or office politics in Europe.
yes pbly more common that europe . even i worked two jobs at one point to double my income to like 700k/yr but it was very hard to sustain that beyond 1 yr. i know many ppl who've done it for years.
How much content you consume comes from the US vs other countries? The US has a full cultural supremacy in the west. That's why you speak english and read YC.
Sure, you are right. Still it seems that the candidate did "test new technologies to evaluate quality". Don't take it too seriously. No one likes cheaters.
reply