[cleverwebble]

As an interviewer, this is so incredibly frustrating - we don't change our questions often and because of that the questions and answers are all over these forums. With that said, it is incredibly easy to spot someone cheating - they often write the most perfect optimal solution from start to finish, helper functions first, often with the same function names as the forums themselves. The trick I've learned is to ask "why" - "why did you decide to use a linked list for this problem?" - the real cheaters often freeze up and can't give an explanation at all. It's rare, but still too common.

If you've seen the question/answer before just say so! I will totally appreciate the honesty and it goes a long way.

[o10449366]

> If you've seen the question/answer before just say so! I will totally appreciate the honesty and it goes a long way.

Why? You're testing their ability to produce the right answer to a given problem - not their problem solving ability. To that end it shouldn't matter if they've seen the problem or not.

I always find it hilarious when recruiters say that "getting the optimal solution isn't everything." I've failed numerous interview rounds where due to time constraints or implementation details I'm not able to completely code the optimal solution, but I am able to talk/walk through each step of it in pseudocode with the interviewer. By your own criteria, being able to clearly explain the solution and demonstrate an understanding of the different tradeoffs should count for much more than just being able to copy/paste the solution from memory, but I've never advanced in any round that finished without a "working" piece of code.

Honestly, the one thing I appreciated about FB/Meta's recruiters is that they were always honest about the process and what was expected - 2-3 Leetcode mediums/hards in 45 minutes and they only care about optimal solutions. I much prefer that to disingenuous sentiments of "getting the right answer is important, but we also want to see your thought process and how you might work with another engineer on the team."

[jokethrowaway]

> "getting the right answer is important, but we also want to see your thought process and how you might work with another engineer on the team."

That's how it works in all the companies I've hired in.

It doesn't matter if you don't get to the end of the problem, I just need to see you can think and that you know how to code. Do you think your daily job will require you more than that?

And believes me, this is enough to filter out plenty of bad apples.

Poor performance in my experience was never about not being able to solve a technical problem, it was always personal issues / not having motivation / hating the environment.

[tomtung]

> the one thing I appreciated about FB/Meta's recruiters is that they were always honest about the process and what was expected - 2-3 Leetcode mediums/hards in 45 minutes and they only care about optimal solutions

A counter data point: I recently passed Google's interview a few months ago. In one round, I was asked to solve a certain kind of bipartite graph matching problem; not being a fresh new grad with ACM medals, I obviously couldn't solve it in polynomial time and just implemented a brute-force solution in the end. In another round, I came up with a solution the interviewer said they've never seen before, although it could be slightly slower than the "optimal" solution he had in mind depending on the input size.

As an interviewer in my last company, I always made sure the solutions were well motivated, and have rejected candidates who could write down the perfect solution but couldn't explain why. If I were to be asked by the candidate for the specific runtime I was looking for, I would probably just reply with "don't worry about it, just try your best" or "let's focus on correctness first and worry about efficiency and other trade-offs later".

Testing for problem solving ability is hard, but that's still one of the key signals we wish to extract whenever possible.

[vineyardmike]

> Why? You're testing their ability to produce the right answer to a given problem - not their problem solving ability. To that end it shouldn't matter if they've seen the problem or not.

Pretty sure most people want to test problem solving ability, and hopefully your problem solving ability solves the problem correctly. If you method to solve the problem is to find the answer online and repeat it... that may not be how the company wants you to solve their problems.

[o10449366]

Really? In my position as a senior member on my team, one of the biggest mentoring costs is just teaching junior members how to search and find answers for themselves.

Yes, day to day I'm not copy and pasting huge blocks of code from Stack Overflow, but when I need an answer and I don't immediately know it my first move is always to search internally or externally for others who may have already shared it.

Why is being able to effectively search for for answers not considered good problem solving?

[MauranKilom]

> Why is being able to effectively search for for answers not considered good problem solving?

Memorizing interview questions is decidedly not "effectively searching for answers".

Effectively searching for answers requires breaking the problem down into separate pieces that you can actually search for. This is one of the skills that can actually be demonstrated during the interview. And then showing that you can also come up with the solution (or be guided towards it in discussion with the interviewer) is the natural way to round it out, instead of "ok, now google for this sub-problem while I'm watching you".

[vineyardmike]

Yes really.

Go ask your manager if you should copy and paste something you found on a chinese forum as 100% of the output you generate. Nothing original, no actual thoughts for yourself, JUST copy paste.

Search and find answers for themselves is not the same as blindly copy/pasting, which is basically what the scripted forum answers are.

[godelski]

Why not just throw out the questions. They seem useless, easy to cheat, and as commenters are suggesting there's a "pay to win" component. What are you really getting from these questions? Why is software engineering so different to other industries when it comes to interviews? Is there really a positive to this type of interviewing? Why not do what everyone else does and look at previous work (which in software we have a lot more considering GithHub), ask some questions relevant to the job, and see if the person has a personality match. Most jobs don't need the best of the best.

I'm not convinced the coding interviews have improved upon the standard interview style in any meaningful way.

[abswest]

> If you've seen the question/answer before just say so!

I did that once at FAANG interview, instead of honesty credits I felt like the interviewer just got annoyed by having to come up with another question.

[AbbeFaria]

I recently interviewed with a startup. They had "outsourced" the first round to a 3rd party firm that specializes in taking tech interviews (Mostly Algorithm rounds).

The interviewer posted an LC question and asked me to read it. Since I was already logged into my LC account, he first asked me to show if I had solved it. I said I did. He then posted 9-10 LC questions one by one, all of which I had solved (I was doing LC regularly then). In the end he got tired, and posted a question from another website (Hackerearth) which I hadn't solved. We ended up taking ~5 minutes just going through different LC questions and he was disappointed that I had solved all of them.

I have also faced situations where I have seen an LC question that I solved but couldn't solve it in an interview setting, mostly because of the pressure.

[the_arun]

Unfortunately goal of interviews these days is to know what you don’t know, instead of what you know

[Aeolun]

> If you've seen the question/answer before just say so!

In my experience failing to answer the alternative question you give me has (on average) a much more negative impact than pretending I don’t know your question (especially when I can explain it).

[dvirsky]

Yep, I did it a couple of times and I didn't get any credit, just got harder questions that the interviewer did not practice in a long time. You should only disclose this if you're getting the same question in the same interview round from the same company, or maybe if you're back for another round a couple of years after failing.

As an interviewer though, there were a few instances where I just told people "let's do this problem anyway, don't worry" and the candidates didn't always do a good job.

[xtracto]

> As an interviewer though, there were a few instances where I just told people "let's do this problem anyway, don't worry" and the candidates didn't always do a good job.

This is what I've done as an interviewer. But then, my questions actually lend themselves to that. Something that the sample LeetCode questions just don't.

In my experience (as interviewer) LeetCode kind of questions are "gotcha" kind of tests: Either you know "the trick" or you don't, but there's no real constructive value.

In contrast, I prefer tests like let's write a Tic-Tac-Toe, Snake, Twitter-clone (no DB in memory), etc. in 30/60 minutes together in your computer with your IDE, your software, google and language of choice. I am able to do a quick coding session with the person, see her weaknesses and strengths, and even if he has done it before, looking at his real project coding style is super useful.

[raydev]

> there were a few instances where I just told people "let's do this problem anyway, don't worry" and the candidates didn't always do a good job

Which should be a clear indicator that interviews aren't only judging problem solving skills, but also the candidate's ability to withstand the pressure of being watched and judged while they solve complicated problems.

For the interviewer, it's just another day and sure, they "want the candidate to succeed" and all that, but for the candidate, their future and livelihood are on the line and that's tough for some of us to just ignore while we focus on the not-easy school quiz problem of merging overlapping intervals or whatever.

[jjj123]

Yeah and often the interviewer won’t be prepared with a backup question so you waste time for them to find one. It sucks that it puts the interviewee in a worse position for being honest.

[sharpy]

A advantage to having standard interview questions. Plus the questions we ask lend themselves to extensions (also predefined) so you can still see how they reason about and solve those. And given that our interviewers are familiar with them, we can calibrate across many candidates. We also have a pool of people who maintain the standard interview questions.

[jjj123]

Yeah I worked for a company that did all of those things as well, it didn’t change the fact that the interviewer was always less prepared with the second question, and that there’s always wasted time switching between questions. The true nightmare was when a candidate knew two questions in a row, or when they didn’t realize they knew a question until 5-10 minutes in.

In a perfect world every interviewer would calibrate for those minutes lost, but that calibration is fuzzy at best unless it’s built in to your scoring rubric.

[heywintermute]

>If you've seen the question/answer before just say so!

In reality no one will do this though. There is way to much of an incentive on the candidate side to lie and work through as if they haven't seen it before.

[JustFinishedBSG]

> someone cheating

It's not "cheating".

> If you've seen the question/answer before just say so!

Haha good one.

[lkxijlewlf]

Why are they "cheaters"? If candidates are supposed to study LC to pass a stupid interview, why get all pissy when they do exactly that?

[vsareto]

>I will totally appreciate the honesty and it goes a long way.

Not far enough to get a job in most cases, at which point, after the rejection, you and I are likely done and won't talk again. On the remote chance we cross paths again, the honesty might be worth another interview (if you're still in that position), but not much more. Person-to-person, I know the honesty is appreciated, but here's why candidates are not likely to be honest and simultaneously have no moral/ethical failing during interviews:

You're an agent of the company with a power dynamic over candidates when interviewing. You can't be honest with us via feedback, even if you wanted to, because there's potential legal problems for the company if you are. Many companies don't give feedback as policy for these reasons. So, knowing that I know that you can't be completely honest with me, I only hurt myself by being honest by telling you I've seen the problem before.

If I already knew the answer, but can't answer 'why?', then that's on me - I likely don't fully understand the solution in that case. Reject those people, sure. But they have no obligation to be honest with you. Similarly, if I already knew the answer and disclosed that fact, I might get a tougher question. So there is real a risk that I hurt my chances by being honest.

The risk of getting a tougher question is important. For it to be really fair, you'd have to grade these questions and determine if the next question is of similar difficulty. But your interview and problem grading process (if you have one) is not likely to be disclosed to me. The honesty would be appreciated, but we both know that interviewers aren't going to share those details chiefly because it defeats the purpose of the test, but also it'd end up on a forum if you're a well-known company leading to more cheating.

If you were giving a well-known test developed by professionals (GRE, GMAT, LSAT, SAT), there are significant resources to show me that those are fair tests developed by academics and other professionals. I would trust those testing admins to substitute questions of a similar difficulty. Were that the situation with your interview, the risk of getting a tougher question by being honest is significantly diminished because I know you have a bank of questions with accurate difficulties attached.

---

I'm not arguing that you should change your process. A candidate unable to answer 'why?' is a perfectly good reason to say the candidate failed the question and maybe the interview. I'm arguing that this really shouldn't be considered cheating or a moral/ethical failure.

[asxd]

If you had honest experience with the question at hand, it seems a little weird, to go into an interview, and basically say "I already know I can answer that one. Give me a new one."