After looking back at my system design interview @ Square, I should've stuck with my guns. At that time I recently finished reading "Designing data intensive applications" and applied it to this interview. But these two interviewers kept hinting something was wrong. However, in fact I was right along. Looked them up on LinkedIn and they both just have 3-4 YOE. I also had an interviewer disagreeably questioned why I said "A function should always return something." They obviously didn't read "Clean Code". This is one of those instances where interviewers were wrong. Anyone had similar experiences? TC: 190K
Don’t be that interviewee
Don't be what?
Interviewers are often wrong. I’ve even had an interviewer give me a problem he didn’t even know the answer to.
Yep, happens all the time! On the other hand their limited experience doesn't mean they weren't experts on that problem.
Regardless of experience, whoever demands certain answer is admitting he is dumb and harmful to the company. In a way, interviewees are well positioned to evaluate interviewers ironically. Based on how the interviewer interacts with the interviewee and what questions does the interviewer ask, it is easy to find the true character. Interviewees evaluation should be counted towards yearly review for the interviewer.
Good interviewer is more important than good candidate for the candidate to get hired. If the candidate is bad they might still get hired, if the interviewer is bad, even the best candidates can get rejected.
Agreed
Always stick to your guns. Interviews are when to shine. No second guessing.
They are not going to go find out that you're right after the fact and then be like "oh he was right let's hire". They're going to see you as argumentative and difficult to work with -- even if it is really they who are difficult. Aim for convergence, not proving that you're right, just like you hopefully would in a real situation. Explain why hypothetically if it's one way, you'd do A, and another way, you'd do B, then move on.
I, too, would be highly dubious if you suggested that "A function should always return something." That sounds like an unnecessary absolute opinion and huge red flag.
So if you have a code base filled with both. Code that modified your objects and return a new object. You wouldn't pull your hair out?
OP, I don't mean to be disrespectful, but you sound like a pompous ass. Don't treat your opinions like facts, even if you have substantial basis for them. I'd you do, people will think you are hard to work with and won't be willing to change your mind. Try to come off like you have some humility and a desire to learn. For example, say you feel like it's easier to understand functions that return something (I disagree BTW), and be ready to give an example - but concede that there are exceptions. And absolutely don't denigrate your interviewers due to their YOE. Just because they are younger/less experienced doesn't mean they are wrong.
Thanks for putting me in a bucket I don't belong. I don't do any of the things you just noted. These are mainly observations.
What was the design question?
Why am I reading guts as guns?
Because Murica!