Hacker News new | past | comments | ask | show | jobs | submit login
What to do if you get a question you've already seen in a coding interview
28 points by danielgh7 on Jan 29, 2022 | hide | past | favorite | 63 comments
The common advice you'll see is "Tell the interviewer so you can get a new question"

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




If its very obvious you've seen the problem before, this isn't neccesarily to your advantage.

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.


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.

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."


The reason I don't take advantage is to keep the process fairer. A fairer process results in a better team and a fairer distribution of resources.

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.


That’s an interesting definition of fair.

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 ;)


It's not fair for yourself and you'd do a huge disservice to yourself, but perhaps someone who said "I've seen this before" and got positive results can contradict me, but let me explain:

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.


My daughter (10 years old) has a saying.. "The wolf cares not for fair." It is perhaps one of my favourite sentences ever.


Not sure if that's smart. Firstly, others will take advantage of a known question, thus you're putting yourself at a disadvantage. And secondly, your job (and perhaps life in general) is about drawing on your experience to solve problems - being able to repeatedly solve similar problems is sort of what we do as programmers. In that sense, it's fair game.


> 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.

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)


Personally, I don't like lying to people I'm considering spending years of my life working alongside.

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,


>A fairer process results in a better team and a fairer distribution of resources.

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.


I respect your attitude to not lying to people you may spend years working with.

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.


How similar counts as same question? Exact wording? Same pattern of solution?


Same pattern is taking it too far. One of the main goals of your preparation is to learn to recognise these patterns. If you go with your last definition, you're basically saying "throw questions at me until we come across one that I can't solve and I'll try to solve that one".


Exactly, I was creating a reductio ad absurdum line of thinking.


Actually I don't think you should lie. So on a direct question, I would rather say "I think so" than "I don't think so", but leaving a small room for doubt. I don't think it is good in general to have a mental list of "acceptable lies", it kind of corrupts the mind. There are situations where lies may be neccessary, but this circumstance is not important enough to involve lies.


I would rather say "I think so" than "I don't think so", but leaving a small room for doubt.

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.


> If an interviewer asks you "Have you seen this one before?" you should say, "I don't think so!".

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.


Interviewers lie all the time during the process. So what makes you special? If you don’t disclose you’re thinking of leaving, or are micromanaged then you’re misleading the candidate.


I agree, as an interviewer. It’s quite obvious when a candidate has seen the question before. As long as they can execute properly, i consider this a good thing as it shows they prepared seriously.


I agree. I have yet to see a candidate that has obviously seen my questions before.


People don't realize it can work the other way around as well - when candidate knows they won't solve it, they can say "I think I already seen this one.".


This is very easy to validate with "cool, can you summarize the approach?"


Wow, that would be extremely bold and risky.

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.


I agree with you. I've done enough of the job prep process recently to know that there are websites dedicated to discussing recent interview questions. It seems unnecessarily principled to put yourself at such an obvious disadvantage by only seeking to solve questions you haven't seen before. Companies with standardized LeetCode-style questions are basically selecting for the meticulously prepared white liar.


Where did you hear this advice? Why wouldn't you take an advantage and who would recommend against it? What is the reasoning?


Sounds like you are an experienced interviewer ;-)


It’s in the “cracking the coding interview” book.


As someone that has to interview people quite often I would be completely fine with this, the interviewee should definitely feel free to use it to their advantage. I look at it two ways 1) They knew the answer the first time and thus they still know it now, no need to discount their knowledge 2) They didn’t know the answer the first time and they took the time for their own benefit to figure it out after the interview. This demonstrates some level of accountability that employers appreciate.


The last two times I did a coding interview, the right answer just popped out of my mind like I knew all along. I can’t say that I practiced those particular problems, per se, but they were definitely in the database.

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!


Sure, why not. Stupid problems call for stupid solutions


Once an interviewer wanted to do fizzbuzz with me. I've never had an interviewer do whiteboarding or something else with me (probably I had to few interviews in my life) and I got very excited.

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.


I'd just tell them. I wouldn't expect to get a different problem, but even if I did, so what. Those types of questions are all about the same, and coding questions are more about code than problem solving anyway. Even if you've already solved it, you can make mistakes when you do it again.


I’ve had Google ask the exact same question to me twice in a phone screen level interview, 5 years apart. (Count the number of 1 bits).

Certainly answered it better the second time, but it seemed like very sloppy technique from a company that remembers everything.


I never heard that advice. I would answer that question.

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.


> You should take every advantage you can get.

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.


(Small business owner): I prefer the "write me a function that squares a number" approach as the big filter. If they cannot do it, stop right there. If they write it and struggle a bit, stop there. If they write it at a normal or fast speed, continue. If they write an inlinable generic function that accepts anything that can be multiplied - things are looking really good.


Interesting. My signal from a generic function is that this person tends to overarchitect, if my request was about squaring numbers specifically.


You can actually train these people by making them create quick POC projects until they become practical programmers. I would take the overarchitechting person.


Some people love asking interview questions where they don't state all the requirements, so I suppose the idea is to see if the candidate can discover the "hidden criteria".

This also makes more sense in a language where number types need manual casting.


If I heard this question, I'd be more confused than anything. The answer seems like it's just return x*x but I'd probably be more interested in why squaring numbers is so important that it needs a special function. Maybe I'm supposed to implement a BigInteger class or something like it...


> why squaring numbers is so important that it needs a special function

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


What about using an actual vector library like Eigen? I wouldn’t dream of reimplementing basic maths like that.


Okay, let's role play this. Here's my Python solution:

    def square(n):
        return n**2
As a well prepared candidate, it took me seconds to write this. What did this tell you about me? Did I do anything wrong and if yes, what did you expect to see instead? What does this score out of 10 and why?


You are almost certainly better off just writing x*x whenever you need a square. A good programmer would point this out.


If I were interviewing you, and this happened, you could take a different path and absolutely dazzle me:

“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.


simply refuse to do coding interviews.


MD job candidate: diagnose this patient for free.


MDs have years of schooling through accredited institutions behind them, easily verifiable. There is nothing similar for software engineers - there is no standard curriculum, the average curriculum has little to do with what you do day-to-day.


the same goes for computer scientists. the standard curriculum is computer science, and if you have a real software engineering job, you will be using what you learned in your CS program on a daily basis. if you went through a reputable university, you will have worked pretty hard to earn your degree.


That goes for a very limited subset of jobs. For the most part you are going to be designing some systems which push data through some queues, not deciding whether languages are context-free, writing parser generators or proofs of complexity of the given piece of code. There is a real disconnect between what's needed on the job vs what is being taught.


that goes for other professions just as well.

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 is the answer imo.


why is this voted down?


The only time I've been asked this the question was... fizzbuzz. It would have been silly to pretend that I've never seen it.

For most complex questions the details are different enough that you've probably never seen it anyway, you're just recognising a pattern.


Factor them into a library and put it on GitHub.


One of the problems with advice is that some of the best advice people cannot say publicly as it clashes with the imaginary world where people are good, companies are fair, bosses are great, and human resources people are more than lying sociopaths.

I have given up anything other than playing for maximal advantage. I would let a billion dollar company fail for an extra few thousand bucks.


I had a co-worker like this before. He was one of the most disgusting people I have met in my life. Needless to say, he only attracted other people as heinous and disgusting as him who would backstab him for a few hundred dollars.


> 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.


I wouldn't cause the failure. That is risky to my rep and potentially illegal. But I would through neglect allow it to happen.


Would you make that company fail for an extra few thousand bucks?

Foreign intelligence operatives would like a word with you.


"If you're good at something, never do it for cheap"


I do not believe I have that power.


Don't let that hear your current or next employer;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: