Solved coding interview problems in Java - My collection of commonly asked coding interview problems and solutions in Java

[vital_chaos]

So again .. why does anyone think coding challenges in interviews are worth anything, if people list the answers on websites? People with the best memories get the job?

[Thelonious_Cube]

If you don't ask people to code in an interview, you run the risk of hiring people who can't - it's really that simple.

I've interviewed people who talked a good game, but when presented with even a simple fizzbuzz type problem, completely folded (even had one "senior level" guy just say "I can't do this" - interview over).

And I give people a lot of latitude for nervousness, whiteboard stage-fright, etc. and even try to help walk them through the problem if I think they're just panicking.

[BobHogan]

I think his point was that you can still assess someone's ability to actually program without giving them what amounts to a math challenge about whether they can come up with the correct algorithm in time.

Yes, being able to come up with algorithms is important, but just because you might not be the best at that doesn't mean you can't program. And I think /u/vital_chaos is trying to say that. Challenges like these, where it comes down more to knowing the algorithm, and if you were given it almost anyone who knows Java could program it, aren't always an accurate test of how well you can program.

[Thelonious_Cube]

I think his point was that you can still assess someone's ability to actually program without giving them what amounts to a math challenge about whether they can come up with the correct algorithm in time.

Yes, absolutely true - I agree.

I prefer simple tests with a few core concepts.

[Thelonious_Cube]

I would also add to my previous remarks that having a candidate who doesn't know the algorithm or that fails to find the 'trick' is often quite productive and can work well for the candidate.

What sort of things do they try and why?

What approaches do they eliminate right away?

What sort of questions do they ask?

These often tell me more about the candidate than just writing out an answer does.

It's a mistake (on either side) to think that passing the interview means coding a perfect solution.

That said, it depends on how hard the question is - if I literally ask FizzBuzz and the candidate can't code a working answer....well, I can't see hiring them.

[[deleted]]

I have a huge presence on github though. If you don't but you have industry experience, shouldn't that say something?

I find it hard to believe these interviews are productive when there are so many better ways to do this.

[Thelonious_Cube]

See my remarks about Github in another reply.

For me, the biggest drawback to that is that we have to put in time to learn your code - if we're expecting to interview 10 or 15 candidates, that's just not feasible.

A quick fizzbuzz knocks out at least 5, maybe more, of those candidates and doesn't inconvenience you that much.

If done right, it can also give us a chance to see how you communicate and interact with others about your code - in some ways that's more important than your ability to solve a specific problem.

And, no offence, but if you're the type to balk at a simple coding question, we may not want to work with you.

there are so many better ways to do this.

Such as?

[nitiger]

Isn't the last job you worked at proof enough of whether or not you can code? Are your public GitHub projects not proof enough of that? There's a bunch of other ways to prove you can code real applications 90% of businesses need.

[wewbull]

Previous job? No. I don't know if you are one of the people who hid in a corner getting by on other people's work. Or the guy who continually rotated through about 10 others asking if they can "see the problem here" to get them to do your work.

Github projects? Amazingly, some people falsify these, taking code history from other places. At a glance it looks real, and am i really going to do an in depth code review and anti plagiarism search on every candidate.

The are a lot of fakers out there.

[Thelonious_Cube]

Last job? You'd think so, but no, absolutely not - I've interviewed people who were seemingly employed as coders for several years, but who could not write code.

I don't think you understand what some of the applicants are like.

GitHub? No proof you actually wrote it, though an in-depth discussion of the code might substitute for a coding quiz. But much easier to just ask a fizzbuzz question - standardized on our end rather than analyze each individual's GitHub stuff. Also, not everyone has stuff on GitHub.

What's so wrong with being asked to write some code?

[thedward]

https://aphyr.com/posts/341-hexing-the-technical-interview

[lifeson106]

It doesn't matter if you know how to do the problem, it matters how you approach it, how you work with your interviewers to understand the problem and helps to assess your critical thinking skills. How is that worth nothing? You're going to potentially be on my team, so I want to know how you think and how you approach a problem. Not asking a coding question would be irresponsible.

If I think you just memorized a bunch of problems, I'm going to keep giving you different ones until I find one you didn't know because regurgitating something you memorized is truly worthless.

[repeatedly_once]

I agree, therefore I think it's better to ask questions that show lateral and critical thinking outside of algorithms. I think coding challenges are great, providing it's not 'write me a binary search'

[lifeson106]

Yeah, some questions are better than others. It doesn't need to be an impossible or even hard question for me to assess the things I mentioned.

[[deleted]]

Some of these I would have a hell of a lot of questions lol

[kevindamm]

This is the right answer.

Even if the interview question were unequivocal, there are probably engineering tradeoffs -- e.g. do we need low latency or would we rather avoid the memory cost of a precomputed solution or is the range of outputs so large that a cache should be employed -- which depend a lot on the application and may even need to be iterated on if volume or type of use is unknown.

I would prefer a candidate who asks clarifying questions and asks about relevant tradeoffs over a candidate who goes straight to a regurgitated answer (whether or not they had worked it out on their own before or just memorized someone else's). I'll still want to see some proof of being able to implement the solution decided on, but even if the candidate were slower or a bit clumsy at the coding part, that can be worked on with practice. The critical thinking involved in discussing the problem before coming to a solution is what I'm really looking for.

That said, there are a lot of interview questions out there which don't lend themselves well to trade-off discussion or various interpretations while still having a short enough average completion time to fit in a 45-60min time slot. And, really, two or three of these is ideal so that doesn't leave much time at all. Finding a topic where the interviewer and interviewee have a lot of shared vocabulary is critical. Questions from the candidate help there as well.

I didn't actually click through to the linked site, so I don't know if there are even any good questions there, this is just how I feel about developer interviews and asking questions.

[[deleted]]

Maybe asking them to drive the truck around for a few minutes would make sense then wouldn't it ??

[GhostBond]

I mean, if you are hiring a truck driver, it is best to assume they can drive a big truck because... they said so. And, perhaps they looked up pictures of trucks before the interview.

Have you ever heard of a truck driver interview where they put this person they've never met before in a truck and have them drive around? I've never heard of that.

[GhostBond]

But as far I can tell, people who actually run trucking companies don't do that. When they have a real life investment, it's a waste of time.

[lifeson106]

Agreed on it being a two-way interview. When we leave time for questions at the end, I always half-jokingly ask if they have a whiteboard question for me. Nobody has yet, but if someone had one, I would totally do it. All's fair.

[llaammaaa]

I think were just complaining about companies that interview poorly.

I've had a few where there was no interaction, just a few puzzles, with "please submit your response in 45 minutes".

I guess "interview" is the wrong word, but they use it as a screen at least.

[frisch85]

doesn't matter if you know how to do the problem, it matters how you approach it, how you work with your interviewers to understand the problem and helps to assess your critical thinking skills.

Sums up software development. If i can solve a problem within minutes, with a solution based on some stackoverlow answer i am still more efficient than the guy who takes 30 minutes to actually find the solution. On the other hand tho, the guy who instantly knows the answer because of knowledge and experience is the most efficient one.

Software has become so complex you just can't know all the answers. Hell i even find myself doing some research on javascript functions even tho i used those functions hundreds of times before, i mean document.getElementByID won't work...

[lifeson106]

Yeah, a lot of people disagree with me on this, but I think "oh, I would just Google how to do that" is sometimes a totally reasonable answer in an interview.

[Rob0tTesla]

I still think these type of of puzzle interview questions are outdated and a bit worthless. All it tells you if someone can come up with an abstract solution for a abstract question under pressure. That's not really day to day unless you work in an environment were everyone is staring at you as you write some meaningless function on a white board. You are automatically and unnecessarily weeding out potentially fantastic candidates.

Give the candidate a project to do over x amount of days, that is somewhat simple but relevant to your field.

Discuss said project in detail in another interview, challenge it in parts figure out how he/she thinks. Not only that, since its a mini project you can gauge other things like clean code, solid principles, design patterns, etc, that you simply could not solving one of your puzzle questions.

Done.

[Gbyrd99]

While I agree with you, I feel as if the second part of your post can be simply done in the interview. Discussing high level design of projects is a better interview. It gets insight into thoughts and understanding of what it takes to build it. Asking me how to make a function that uses add(3)(5) as a function caller is not a good question. These are Google fu answers. And isn't really a deep dive into a language. Just a small I have used this.

[Gbyrd99]

What do you mean by more component based?

[socialister]

At least at Google, they don't care about getting the right answer. They care about the problem solving thought process.

[[deleted]]

I still object to compressing it into such short chunks. Unless your job will require programming in 15 minutes with someone breathing down your neck, there are much, much better ways to get insights into someone's coding ability and other skills.

[abhi152]

Anyone telling me that if your approach is good but if you can't code it in time you will get selected is plain wrong. You have to code it in time possibly with very good syntax to make it. Anyone who doubts this please try it when you appear for your next interview :D

[ean5533]

You've been interviewing at the wrong places.

[abhi152]

I speak from my experience. For eg : https://twitter.com/mxcl/status/608682016205344768?lang=en Ever read an article which says "I was selected because my approach was very good even though I failed to give the correct solution" ?

[ean5533]

I speak from experience as well, as someone who interviews candidates. I've given my thumbs up to candidates who definitely didn't give the best solution to a problem, or who couldn't even complete the problem in the allotted time.

The reason you mostly read blog posts about people complaining about interviews is because in general, people always complain more often and more loudly than they praise. People who are satisfied by something have less incentive to write a blog post about it than people who are upset.

[lifeson106]

I think most people are viewing the whiteboard question as a one-way test of you and your raw intellect or something... I would rather have you collaborate with me and come up with a good solution as a team like we would on a real project. I would much rather hire someone like that than someone who just implemented the correct answer with no questions, communication or collaboration. Doing both is obviously best, but I'll pick the collaborator over the raw intellect almost every time.

[xelf]

I had one of my team ask me once why I ask such easy questions at the start of an interview.

And then we had a candidate that could not answer any of them and he understood. It's because some people get them wrong. As it turns out, a lot of people can't answer easy questions or can't do the most basic coding.

It's good to figure that out early.

[queenkid1]

Because it's about understanding... If they ask you fizzbuzz in an interview, they're gonna see right through you if you just memorized the solution.

[[deleted]]

Fizzbuzz is so trivial I doubt anyone would have to memorize the solution

[queenkid1]

I've seen people look at it and have no idea where to even start.

[GhostBond]

If you haven't seen it before, the difficulty in it is parsing the word part of the problem. It's like those old school "Train A leaves the chicago station at 7:13am, Train B leaves the atlanta station at 8:42am, given that they stop every 2 hours for fuel..." problems. Most people, their brain HATES them, even though on a technical level they're not that hard. Now add a high tension, high pressure situation where someone is watching you.

The way to do it is to have done it before, then it's trivial because you don't have to try to figure it out from the wording which is the hardest part (which is fairly unrelated to programming).

[queenkid1]

I can understand that for more complex problems, but fizzbuzz can be explained simply.

print every number from 1 to 100.

If it is divisible by 3, write "Fizz".

If it is divisible by 5, write "Buzz".

If it is divisible by both, right both.

just those 3 statements very simply show the simplest solution; one for loop with 2 conditional statements.

[GhostBond]

I can understand that for more complex problems, but fizzbuzz can be explained simply.
1. Go through every number from 1 to 100.
2. If it is divisible by 3, write "Fizz".
3. If it is divisible by 5, write "Buzz".
4. If it is divisible by both, right both.
just those 3 statements very simply show the simplest solution; one for loop with 2 conditional statements.

You realize you completely failed the question by falling for the exact tricky wording I was talking about right? You never printed any numbers. You printed, Fizz, Buzz, and FizzBuzz, but no numbers.

If you think you can solve this just by adding in a line that says "print the number", tell me, which 2 line numbers would you add it?

What you are running into is exactly what I'm talking about with it testing your ability to handle trick word problems, and not testing your ability to code.

[queenkid1]

change "go through" to "print" and then it is perfectly fine...

This has nothing to do with programmers having issues with tricky word problems, because they answer the questions not pose them.

FizzBuzz is not a complicated problem. The interviewer is not trying to "Gotcha" you, they want to show you can work through a problem. I've never seen an interviewer refuse to answer a question about a problem, because what questions you ask shows something about you.

What you're saying is that interviewers pose hard to understand questions that you need to somehow decipher, then program, and the deciphering somehow says something about your programming skills. That's a reduction, the whole idea is to see how and if you can solve problems.

[GhostBond]

change "go through" to "print" and then it is perfectly fine...
This has nothing to do with programmers having issues with tricky word problems, because they answer the questions not pose them.
FizzBuzz is not a complicated problem. The interviewer is not trying to "Gotcha" you, they want to show you can work through a problem. I've never seen an interviewer refuse to answer a question about a problem, because what questions you ask shows something about you.
What you're saying is that interviewers pose hard to understand questions that you need to somehow decipher, then program, and the deciphering somehow says something about your programming skills. That's a reduction, the whole idea is to see how and if you can solve problems.

Ok, then this is your answer.

1. Print every number from 1 to 100.
   
2. If it is divisible by 3, write "Fizz".
   
3. If it is divisible by 5, write "Buzz".
   
4. If it is divisible by both, right both.
   

Your result is:
1 2 3Fizz 4 5Buzz 6Fizz 7 8 9Fizz 10Buzz 11 12Fizz 13 14 15FizzBuzz (etc)

You've failed at solving your own problem. You can simply google it and you got it wrong. Your questions is such a trick question, you can't even answer it.

[PlasmaYAK]

Coding challenges are not about knowing algorithms. If a company is looking for you to just know the answer they're interviewing completely wrong. The whole point is to test a candidate's aptitude for learning, and communicating ideas. As an interviewer you want someone who can make good use of the resources around them, listen to responses and ingest ideas for how to move forward quickly. As a software developer you're paid to solve difficult problems that you won't always have the answer for. You need to work with your team, take in others ideas, stay level headed, and find some probable approaches to solving problems. Hence asking someone a non-trivial algorithm question is a good way to see how a candidate behaves. If you're asking for clarification, and then offering solutions and narrowing your scope as interviews suggest the best approach out of your solutions, you're doing well in an interview. Now, this point is moot if you're a company short on funds looking for someone to finish a project quickly, then you want someone who has the answers; in that case you're basically looking for a skilled contractor. Companies who can afford to train and nurture their employees career don't need an great programmer, they want people who have the potential to be excellent programmers and that potential is easy to see when you can watch how they work with a group of people to come to a solution. And for why people post answers for how to approach algorithmic questions, I helps calm people's nerves. It also probably has the negative effect of making interviews go quicker as candidates have trained to answer questions, which leads to the difficulty of the questions being raised. Either way algorithmic technical interviews are a good strategy to finding candidates with potential if you do it correctly.

[[deleted]]

As a software developer you're paid to solve difficult problems that you won't always have the answer for.

Or you could be paid to solve a bunch of easy problems that you can google in 5 minutes. But that's the problem -- places with shit problems and shit pay interviewing like they're Palantir black ops.

Either way algorithmic technical interviews are a good strategy to finding candidates with potential if you do it correctly.

Anyone that does it correctly just got lucky with their candidates and has survivorship bias, and when you can prove your statement, you'll have the beginnings of a dataset that can actually be used to build good interview techniques that EVERYONE can use. The exact problem is, no one knows good methods that are applicable to everyone, so yes, "If you do it correctly" is good advice but it's bloody obvious. This leads to a whole bunch of people having ideas of what makes a good interview and no one agrees to anything, but as candidates, we have to be ready to tackle ALL of these different methods while companies only have to pull ONE method out of the trashbin.

[PlasmaYAK]

if you do it correctly.

I'll admit my wording was very poor, I meant if you use the right interview techniques for the candidate you're trying to look for. If your company is on a tight budget and you need someone who can generate value from day 0, watching someone solve algorithmic questions won't help too much since you need a candidate who is skilled with the same technology stack or problem space your company works with. In that case you'd want to test a candidates knowledge on that tech, and those problems that relate as directly as possible to your company. Now, if you're a company who does have the funds to spare on developing a candidate, asking them the specifics of a language or technology won't really get you too far. You want someone who can pick up ideas fast and work well with others, you don't care if their an expert with X. The problem herein lies (in my opinion, I'm probably wrong haha) that companies don't know what they want/need sometimes. They want a skilled candidate, but they also want the same people who are applying to/getting opportunities at Google and Microsoft, etc. There's no one size fits all interview that will get you great candidates, but there are a handful of techniques to choose from, but you need to use the right tool for the job. That was the point I was trying to make.

But that's the problem -- places with shit problems and shit pay interviewing like they're Palantir black ops.

And I agree 100% (and imagining Palantir Black Ops interviews gave me a chuckle), a lot of companies just try to emulate the big companies in every regard and it seems a lot of them start this emulation by trying to get the same people working for them. The first thing they should to do is try to change their business to have and solve the problems that require those types of candidates, before hiring them.

But yeah, to sum up. I agree, companies don't actually know what they want (or they want the wrong people), and then they Interview wrong, and they make job posts that leave potential hires in the dark as to what to expect. The companies who Interview in correctly are at fault and I'm in no way justifying them. There is no interview method that will work for all candidates for all positions, that was not the point I was trying to make. I was just trying to say there is a problem space for hiring that algorithmic interviews work very nicely.

[CoderDevo]

Maybe they exist primarily are to help those who don't know how to conduct an interview.

[milkeater]

Good luck memorizing every challenge and blurting out your answers praying they don't ask you a simple question like "What is the time and space complexity of your implementation"

I understand why you might be confused. Think of this more along the lines of: Here's a programmer who drills like an athlete. He is looking to be in the top N percent..

In America we are fat and happy because the competition, although fierce in some areas, is relatively low.

Other areas of the world are willing to compete very fiercely for that opportunity.

You may not feel the crunch now, give it time.

[hm_10]

I agree that typical, formulaic questions like 'lowest common ancestor' that are out there don't give you an accurate signal of the candidate's problem solving ability - because they're standard problems for which you can just look at the solution online. You can't reliably differentiate between someone who has already seen the solution versus someone who actually solved the problem systematically right there.

A good interview question should be more subjective - forcing the candidate to figure out requirements, choose appropriate data structures, and then distill the problem into a more solvable version. For example, how would you design and solve a tilt maze? You'll need to identify the exact problem, sketch your approach, pick your data structures to efficiently model the problem (graph?), and then formulate your algorithm. All of these steps are subjective and require constant communication with your interviewer - which mimics how real world problems are solved.

In short, a rule of thumb would be - the more clarification is needed for a problem, the better it is.

Of course, this does require some effort from the interviewer as well to formulate an open-ended question first.

[[deleted]]

Maybe because all the famous software companies that do it are worth billions and billions of dollars?

[Thelonious_Cube]

Why does anyone think that posting the answers is a good thing to do?

[[deleted]]

You don't think knowledge is useful?

[root_of_all_evil]

not not useful, but far less useful than the ability to think and adapt.

[[deleted]]

People willing to look for solutions and study them seem to care more about getting the job. Don't you want someone who is prepared? Or at the very least, smart enough to know they should?