I can't reply to the sibling commenters but providing a contrarian opinion. I'm an interviewer and there's no way for me to tell who is just really good vs who has seen the exact question before. Telling the interviewer just gives them information that goes against you so I wouldn't recommend doing this.
I always prefer to say "I've seen a similar problem before, let's see if I can remember how to solve that" or "let's see if the same kind of approach works here".
This is a balanced approach. It's honest: you probably haven't heard the exact question word for word, even if you can't recognize the differences. And it's actually what they're selecting for in the first place. They're not expecting you to invent the concept of a binary tree, or whatever, but to know it exists and how to implement it and to recognize where it might be the right concept to apply.
I've never had any interviewer say "OK forget it, let me give you another question where you'll never have seen something similar".
I was thankfully asked (in the interview, not just assuming I’d been asked the Q before).
Question was: write code to determine if the stack grows up or down. I’d been writing computer games for several years and smashed it (after telling the interviewer that it would be necessarily technically rely on undefined behavior) and the interviewer somewhat dismissively said “you should have told me someone else asked you this question” “What are you talking about? This is just an easy question.”
A good answer would be "no, but when I was working on <game title> which is a game that has to run on many different consoles including <console>, we had an interesting but where <weird stuff happened> and the stack cookie I inserted to test if it's a buffer overflow remained pristine. After a lot of debugging, at the stage where I started suspecting it's a compiler bug and inspecting raw opcodes, I was looking at my debugger and noticed the stack pointer was lower than the stack cookie address and understood this CPU has a stack that grows the other way than I'm used to".
> “you should have told me someone else asked you this question”
At what point do we end up saying "my current employer 'asked' me this question, because it's part of my day to day job..."? At some point you have some experience in certain areas that you just 'know', and it's not some sneaky "oh I crammed leetcode for 3 weeks!" tactic.
Yes, it seems to me that if interviewers are going to be annoyed about this then they should stop using leetcode and/or using generic interview questions.
I got hired from that loop. Same guy challenged my failure to write ifdef include guards on my header file on the whiteboard. My answer of “oh, you’re right; I’ve configured emacs to automatically insert those, so I don’t have to think about it” seemed to more than satisfy him and we ended up being close as colleagues for several years.
It does in this case yes, how would you see it as an advantage? You have to pass X number of algo/data structure, your being honest will only make them find a different question. If you get the different question wrong guess what you are out. It is what it is.
If the hiring process is set to punish honesty, then maybe by being honest you avoid working at places with such a process and consequently with the people who passed it?
Note that I'm not saying that FAANGs are like that (I have no opinion on that).
I am not denying honesty won't hurt, and probably would help you. But again, the interviewer is going to have to get a replacement question...you have a reduced chance of solving it correctly.
I have a question that I've been asking for years that is somewhat domain-specific, but should be answerable by anyone who knows what a set/map are. About 20% of people get past "stage 1" within 5 minutes, usually people with finance/trading experience, and some will say "oh, I implemented something just like this a few years ago." Some people take 30 minutes and do ok, and some never finish. When someone tells me they have had this problem before, I tell them it should be really easy for them then, and we can move on to more interesting things!
For those that DO get past stage one, it is a boss with multiple health bars. We talk about what improvements could be made, then what improvements on THOSE improvements. We keep digging until we are out of ideas. The best candidates are the ones that stump me, or introduce new ideas. I present this problem as a pair problem solving challenge, so there is no one right answer, and has a lot of back and forth.
The whole leetcode approach to interviewing is basically
1. interviewers asking questions that they wouldn't be able to solve
2. interviewees pretending to solve on the spot things they've memorized
3. interviewers pretending to believe them
There is no way for you to tell if someone is really good (as is) vs who has grinded leetcode since the process (which assumes prior preps) a priori discards the first group.
Leetcode grinding is suggested as necessary by everyone, including recruiters (in-house or 3rd party), hiring managers, prospective colleagues. You can see comments from devs at FANGs even in this thread.
I understand that this is a common belief, but I don't agree that it is strictly true; it is contrary to my own experience, both as an applicant and as an interviewer.
Note that we are talking about a particular interview process which uses CP (Competitive Programming). This is common at FAG (Lets exclude Netflix since as I've heard they don't do it) and at companies that copycat the process. Of course, there are many other places that don't do it.
We are? What is "competitive programming", and where did it come into this thread? All I see upstream from your comment is a discussion of Google interviews and large tech company interviews generally. I don't recall anything particularly "competitive" when I interviewed at Google (or Facebook, or Microsoft, or...); they just had me solve problems, as usual.
That's the point, CP != CS (Computer Science). It is a separate discipline/subject with its own trivia knowledge & tricks. CP uses Computer Science the same way as e.g. Physics or Biology use Math. And CP problems are used in those interviews. https://en.wikipedia.org/wiki/Competitive_programming#Benefi...
I guess, it is okay telling your interviewer depending on your comfort level, as most never change the question regardless. That said (and as another commentator points out [0]), if an interviewer asks you call out questions you know of from before, then you most certainly should (unless you can sell the bluff...).
