What to do if you get a question you've already seen in a coding interview
I disagree.
You should take every advantage you can get. The whole point of studying ahead of time is to prepare yourself for the inevitable interview question, if you've seen it before you are likely in a really good place to answer it well.
My take on what to do if you've seen a question before
* Don't get overly excited, if you let out an audible "YES I know this one", the interviewer may give you a different problem.
* A lot of the time you think you've seen a problem before but you really haven't. When you get overly confident and then realize you haven't seen it, it looks really bad. Don't introduce that opportunity to get hit
* If an interviewer asks you "Have you seen this one before?" you should say, "I don't think so!". Why? Because it's the truth, you probably haven't. A lot of the times you've seen a similar problem, one small tweak can result in a very different solution. You should be cautious!
* You want to be sure you walk your interviewer through your thinking even if you know the right solution out of the gate. Spend time analyzing the problem, really quickly coming up with a brute force solution, and then showing how you can optimize it to the real solution. This will show a clear line of thinking which is what the interviewer is looking for. As long as you have structure in how you solve interview problems you shouldn't have an issue. Here was my structure: https://docs.google.com/spreadsheets/d/1gy9cmPwNhZvola7kqnfY3DElk7PYrz2ARpaCODTp8Go/edit#gid=0
Tldr; I firmly believe you shouldn't throw away any advantage you have
70 comments
[ 3.1 ms ] story [ 48.1 ms ] threadI have given up anything other than playing for maximal advantage. I would let a billion dollar company fail for an extra few thousand bucks.
This seems quite short-sighted, as the damage to your reputation would cost you more than few thousands in the long run.
Foreign intelligence operatives would like a word with you.
the reason people make arguments like what you just wrote is so cheaper labor can be hired, and does not need to be compensated for prior education.
that is the real problem of our industry. it’s still a very young one with no unions or professional organisations that protect the interests of those working in it. law, medicine, construction etc all have solved these problems.
This also makes more sense in a language where number types need manual casting.
I've had pow2() in pretty much every codebase I'd worked on, ever. pow2(x1-x0) looks nicer and less error prone than (x1-x0)*(x1-x0), and less verbose and distracting than first separating to a local var as dx = x1-x0
But that is lying, of course. You're basically saying "no, I haven't seen it" -- just with a bit of a spin on it, for the sake of plausible deniability.
Not that's the wrong thing to do here - I agree that that's exactly what you should do (if your main goal is to get the job and grab the money).
And in fact that's exactly what these companies expect you to do.
I didn’t ask to have a different question, I just used the opportunity to display confidence and deliver an excellent answer. I felt: If this is not the ideal outcome, to see an interviewee ace a question, I don’t know what is!
Then he let me down by not doing anything. :(
We decided to do 2weeks paid, they offered me a full job but I declined, because I found a more interesting job without commute.
It's the same reason I return a shopping cart after loading groceries in the parking lot. I don't benefit, but others in the system do.
I myself have told interviewers when I've seen a question before. If they want to see me solve a question I've seen before, they're welcome to watch. So far, none have wanted to see me solve problems I had seen before.
Personally, I don't like lying to people I'm considering spending years of my life working alongside.
surely that only results with a good methodology for choosing people. If whiteboarding and testing are inherently flawed following the correct process would not reliably lead to a better team (unless of course the test then shows honesty), because if it did reliably lead to a better team it would show the process was not flawed.
An interview is not a fairness competition. They are rarely fair and subjective. The end goal of any interview is to enter into a contract which exchanges money for time. The setting of an interview is an informational asymmetric paradigm. Your one sided fairness won’t make the process fair.
You may still want to keep letting your interviewer know that you solved the question before. However, this doesn’t make the process fair. It’s a story that you’re probably telling yourself to make it feel better ;)
99% of people (as a person who's done interviews a while ago) never say "I've seen this before" -- either because they're lying or never seen it before or don't remember.
When you say "I've seen this before" you put the interviewer on edge and derail his interviewing flow, he's going to second guess every answer you give -- "has he seen this one also?" and might switch to really obscure questions that actually disadvantage you as an honest interviewee.
Then when he'll make his final appraisal of your score he'll put a big question mark over your result and might go for someone with lower scores but that he feels has never seen those questions before.
To be clear, I'm not talking about obvious questions like "how can you determine if a linked list has a loop without aditional data structures" -- where you either know Dijkstra's solution or you don't, and can't possibly come up with the solution on the spot.
It's not the same. The parking lot isn't a competitive game. You can't enforce fairness unilaterally in a competitive game. The people who benefit from your actions in the interview case are the people who are willing to take advantage.
In a game where everyone is "cheating", you can cheat to be on even ground or you can not cheat and be at a disadvantage. You don't have a way to make the game fairer.
(btw I wouldn't lie in the interview either, I just don't agree with how you're applying the concept of fairness)
However, your approach does not result in a fairer process or a better team. That would only be true if everyone behaved like you.
In fact, you're condemning the teams you don't take a job with to have more dishonest people in them! But only by such a small margin that it really won't affect anything.
Me neither - but you if you want to work for FAANG, or wannabe FAANGs - you're going to have to get used to it.
In fact, arguably that is the very purpose of these "tests" - to get you to compromise your integrity and negate your gut intuition about how professionals should treat each other -- even before you are invited to come in for an interview,
It is easily countered with asking you to summarize it, or them saying they'd like to see your solution anyway.
Both of those seems so much worse than trying to solve it and fail.
People go through books and websites in preparation for interviews. That is fairly normal. And interviewers consult similar books and websites. Once in a while, it is going to match.
For example, people who have seen the problem before will sometimes more or less remember the solution but not how they got there. Then the interviewer asks some questions about the solution which they really don't know how to answer and that looks bad.
> You want to be sure you walk your interviewer through your thinking even if you know the right solution out of the gate. Spend time analyzing the problem, really quickly coming up with a brute force solution, and then showing how you can optimize it to the real solution. This will show a clear line of thinking which is what the interviewer is looking for. As long as you have structure in how you solve interview problems you shouldn't have an issue.
This is the key point. Interviewers aren't looking for you to get the right answer, they are looking at how you think about the problem, how you communicate your solution, and what trade offs you make. If you just blurt out the correct answer without context, you probably haven't demonstrated the things they are looking for.
That's what everyone wants to believe. But in reality, about 90 percent of the time, it basically is all about just getting the right answer within the given (patently unrealistic) timeframe. "How you communicate" is at best gravy. But if you don't solve that Two Sum problem in linear time in 27 minutes or less -- you're flushed, gone... and "don't let the door hit ya."
Please don't lie to me as an interviewer. I do everything I can to treat you with respect, and I ask the same in return (though I can't speak for others.) It's not a life-or-death situation. I just want to make sure you can be helpful in my team. And you want to be sure me and my colleagues treat each other (and you) fairly.
That said, if you're actually not sure, by all means, don't throw away a good opportunity.
Certainly answered it better the second time, but it seemed like very sloppy technique from a company that remembers everything.
For most complex questions the details are different enough that you've probably never seen it anyway, you're just recognising a pattern.
If you want to be consistent with this attitude, you should answer "I've seen this question before" always when you see a question that is too difficult for you to answer.
“I did this at another interview, and here’s how I solved it. But now that I’ve had time to think about it, I’d do this differently instead because...”
That demonstrates honesty, insight, and great problem solving skills. If you could pull that off, I’d give you a strong yes.