I was recently asked by a job seeker whether they should be honest about already knowing how to do a coding question. In short, my answer is "no." ...
For further actions, you may consider blocking this person and/or reporting abuse
I completely agree. We've all seen bits and pieces of questions before. That's how you become more prepared to answer them. The idea that having coded something before is "cheating" implies that you shouldn't know how to solve the problem. But isn't that the whole point? Knowing how to solve the problem...
Plus I feel like it's on the company to provide good problems to solve. If it's another FizzBuzz how could you not expect some candidates to be familiar with it already?
Yes, the expectation of people being familiar with something shouldn't change the outcome of the interview. The questions I ask now aren't heavily influenced by whether they've seen the problem or not before.
Sure, it will make some difference, but that's what experience is for.
Ya, I think live coding is a horrible interview tactic anyway. So if a company is caught using something that’s widely known and it allows someone to game their process it further confirms that it’s a bad process.
I think the tension is that if you've practiced the exact question before and you know the answer, it stops being a test of your on-the-spot problem solving skills and becomes an exercise in mental copy-pasting.
But this gets to your third point: does it really make no difference at all? In the case that they've just "seen that before", maybe not, but I have certainly been in interviews where I literally studied implementations for the exact algorithm I was being asked to produce, and have been able to simply recite the code from memory, with basically zero critical thinking on my part, and no "thinking out loud" necessary, which is what a lot of interviewers seem to want.
I guess I'm unsure how I feel about it. I'll keep thinking.
The on-the-spot problem solving is in my opinion not at all linked to if you know the puzzle. If you can explain your approach to solve difficult stuff thats new to you it does not matter if you know the question.
If you want to test someone if he/she can solve this problem it is relevant. But thats often not the riddle to solve in a coding example.
Was about to say this exact thing. Being able to explain how something works means you understand it. Simply knowing the solution doesn't help.
If you're lucky enough to stumble across a problem that you're very familiar with, I'd say you can still use it as an exercise to show how good you are at communicating. You may not need to think much in order to find the answer, but you still have to explain the overall shape of that answer, as well as what each specific step is for.
I can't tell whether knowing it in advance makes no difference at all. If there was a substantial difference, I'd have expected these candidates to excel, and even finish the extended questions, but they did not. Were they perhaps really bad programmers that got lucky? No, I don't think so, since I can evaluate a lot about their coding style and how they talk.
What's the difference between having seen the question before, and getting a lucky thought that solves it within the first minute? I don't see any reason to treat these differently.
Looks like I'm in the minority, but I completely disagree with this.
If I know the solution before hand then the interviewer is learning nothing about me other than my ability to recite canned solutions to existing well known problems. There is no chance to explore how I would think about a new unknown problem, approaches I would take, things I would consider. This is critical because, unless the job is mundane and repetitive, most real world tasks are not going to be found in a coding interview booklet. They are going to require that I think about things, not recite.
They absolutely do need to know this. Just because I can give a pat answer doesn't mean I understand the concepts. It's incredibly misleading to insinuate that I've solved the problem on the fly when in reality I haven't. IMHO this is how you end up hiring someone that appears to be a rockstar, but then can't get anything done once hired.
Furthermore, I think it is dishonest. If you do this, what will you do once hired when I ask you for an estimate for a project you know how to do? Will you tell me two weeks when it takes two days and spend the rest of the time goofing off?
Honestly, I feel like a company that interviewed me in this manner and penalized me for knowing an answer to their quiz question and wasn't able to adjust the interview to discuss something more relevant in which we both learn more about each other and how things work isn't one worth working for. :two-cents:
An interview will consist of multiple questions. IT will not be based on a single question that you happened to have seen before. It's unlikely that you'll have been exposed to all of the questions before, and if you have, then it's just good preparations.
Your point about reciting from an interview booklet is why I advise against admitting you know it. Chances are the question is not the exact same one you've done before, in which case you have to adjust your knowledge. This shows thinking. Adjusting algorithms to new situations is a big part of programming.
Sure. I still think being honest is best. And I'd be happy to discuss the question if they want to and how it differs from my previous solution, etc. What I'm not willing to do though is "reverse a string in language X". Granted that's a horrible question, but I've gotten some like that, responded "i'd use the built in method, can we talk about something else?" and then gotten into much more interesting discussions :)
I've also been asked to solve Conway's Game of Life. And amazingly all I knew about it at the time was "it's that dot game." I didn't know how it worked or the rules. I'd like to think my solving that was more impressive not knowing anything about it than if I'd previously solved it several times and knew the edge cases. :shrug:
This is great advice. I've had a positive experience where I didn't say that I knew the question but in walking through it so smoothly with a smile, I could tell that they knew I knew. Got the job regardless, and since I lot of these whiteboarding exercises don't pertain to real "on the job" problems, I don't really think it matters.
You're right: If you know the answer to the question they're trying to outsmart you with, admitting that you do puts you at a disadvantage because the interviewer's ego is hurt. Their "hiring expertise" is being challenged.
...but if that's the environment they promote, it's time to run.
Don't try to get hired by a company that's worse at hiring (= dealing with people) than a technical expert (= someone literally paid to deal with code more than with people).
If you want to take on the challenge to promote better hiring practices, you're welcome to start the conversation yourself:
Never question the interviewer's approach! I'm going to repeat this in my class I'm filming. Your steps 2-3 are a near guarantee of not getting called back. It does exactly what you said in the first paragraph, it hurts their ego. It also makes an assumption that you know why they are asking a particular question, which you may not.
Like I said: If they promote a culture where you can't even hold a conversation with the recruiter that is trying to determine whether you're a good fit, run.
If you enjoy being human and learning, you're already not a fit at this point.
Companies that value learning and honesty will have no issue with improving the interviewing style. It's an immediate test for personality match (openness, ability to adapt), and gives them a better way to qualify the candidate for the work they will actually do on a daily basis.
Bonus points scored with the engineers and the bosses, because you get things done and don't hesitate to explain your thinking.
Like you said: Those that don't fit, won't call back. 100% sure-fire way to get hired with companies that are a fit, and 100% way to avoid companies that are a bad fit.
You can ask a question as a suggestion, not as a demand.
That's why I wrote "suggest".
Getting clarification on why a question is being asked = 100% OK and awesome.
Not saying you know the question and lying after you've been asked are different things. I agree on that. And probably you should only answer questions on interviews not give away any info not required by interviewer as sometimes it can even lead to interviewer thinking "we'll you give too much info but we need someone who's simple and just does what's asked of him".
I strongly disagree with practising for interview and schema like questions. This is pretty bad as people get to memorize some rules pass the test and then do same mistakes others do while programming. Candidate should be asked theoretical questions and their views on it. This gives you more perspective on does the candidate understand why is something a standard or a good practice. Example many design patterns are out there but some became "useless" like strategy pattern that can be solved by simple lambda. Now it's maybe not useless but why would you do it any other way when provided possibility. The answer is because you learn schema on how to solve problem and do not really understand what's it actually doing.
So if you're getting ready for a new job and know the questions and that helps you get the job you should really think about what's going to happen when it's time for you to make strategic decision and you deliver poorly. The post is written in a way that could make me think there's some honesty issues here and gives message like "look for yourself". I dislike that approach and always put honesty first as it hurts less later if I say in the start "yeah I'm not good at that".
But this is too subjective I'm aware of that.
If the system were fair, then honesty would be the best approach. But the interview system at a lot of companies is kind of random. The idea that throwing a random algorithm question at you is some way indicative of your ability is wrong.
So, in my view, if the interview process is a silly game, then learn to play the game. This doesn't preclude you from learning how to code, but navigating the dumb questions are a prerequisite to working -- especially if you're targeting specific companies.
As I mentioned, I think for good interview questions it doesn't really matter much if the person has seen it before. And I think this is what you're saying as well.
Of course. Companies tend to have silly "game" and what worries me is wanting to work for them. I had a lot of interviews were I did not have such questions but latest one I had with questions about design patterns and solid priciples was more of how would I explain it. On the other hand I disslike forcing patterns and some principels/architecture because others do it, so I'm glad I didn't get the job and accepted other opportunity.
The situation can go in the other hand as well if the interviewer asks you if you know how to solve the problem, and you say 'no' and proceed to implement it and find a hard time to explain, they probably will "catch" you cheating and this can put you in a bad situation. Personally, it happened to me that they asked if I knew the algorithm, I said 'yes' and still they asked for me to implement because the most important part of the algorithm is the discussion around optimizations, big O and alternative ways of doing that.
You should never answer, "Yes, I know how to solve this." That's almost never true. Even if you ask me to recreate code I wrote before, I can't for sure know I'll do it the exact same way, or not encounter difficulties.
A truthful answer can be, "I believe I can solve this."
The ability to explain what you're doing is critical. But I don't think it's tied to having an answer memorized or not.
You are right!
How about getting rid of these ridiculous coding interviews altogether? My current job didn't give me one and it's a great place to work. Whenever I interview someone now, I don't give coding interviews. I feel like I get a better feel for the candidate by just talking about their experience. Coding interviews are unnecessary and stressful. I have 15 years experience, I write code everyday and I'm pretty good at my job, but I'll fail a lot of coding interviews. No one codes on whiteboards in front of other people with no resources. It's the worst way to evaluate a potential employee. I'll never again work somewhere that screens candidates that way.
I'm in favour of coding interviews for people that don't have a public record of their work -- and even then I'm in favour of them in most cases.
The trouble with programming is that we have no general device to measure it that transfers between positions. The level of education and ability wildly differs between schools and individuals.
I've encountered people that have worked for 10 years, yet in my opinion, weren't qualified to work as a programmer. I've encountered people that haven't worked yet, but were excellent programmers.
There's a million ways into this profession. There's no reason to believe the history of an individual matches the expectations of your company.
I wouldn't ding anyone for not admitting to having seen the problem before, but let's not pretend it doesn't make a difference.
Seen or not, though, I feel like you can't really fake communication skills and clarity of reasoning, so your interviewer will at least have those things to go off of.
Of course it makes a difference, but that is the point of experience. The more you know, the better you should perform.
Why say anything at all in this case?
What are you "giving away" exactly? If you're faced with a day of random algorithm challenges, you'll naturally stumble on some and excel on others.
A good interviewer is looking for how you explain what you're doing, and how you come up with the solution.
A bad interviewer wants to stump and stress you... but in the case of a bad interview, who cares what is legit or not.
One thing I’ve seen and that was actually done in my interview where I currently work, is that if they solve the given problem to fast they keep adding “twists” to the problem just to see how far they could go.
It would be questions like,
What if the user presses this?
What if I do this?
Just trying to poke holes on what you did and see how you figure out a solution for these new bug/requirements that were thought of on the spot.
This is how I structure my interview questions. They come in phases, and I can always extend it if need be. I know about where people should make it to, and where top people make it to.
The main point if you admit that you've seen it before is that you better be sure that 1) You get it right and 2) You can explain in detail the why, and how of how it works.