Writing declarative code over imperative code.Moving duplicate code into separate functions.Avoiding nested if statements to make code more readable.We might not have enough time to go over everything we've discussed in this post: In an interview setting where time is a critical factor. They care about hiring developers that can deliver maintainable code. They want to know if a developer can ask the right questions to clarify requirements and to convey they understand the problem. Good interviewers don't only care whether or not the developer can find a solution to a problem. Please leave a comment to share your thoughts! Or maybe you'd prefer different test cases or patterns to be used.

Maybe there's even more improvements you'd suggest. Our code is fully tested to help ensure it doesn't break.We have comments to show that the order matters.* divisor ) Įnter fullscreen mode Exit fullscreen mode * dividend - number being checked if divisible by some other number (divsor) * Checks if a number (dividend) is divisible by another number (divsor) There are many variations of this problem, we'll be using: We'll also highlight good alternatives that demonstrate an understanding on how to write maintainable code. Let's go over some solutions for the FizzBuzz problem and highlight bad patterns to avoid in an interview. Deliver code that can be easily maintained.Naturally writing/refactoring code to be DRY.Writing self-documenting/commented code.

Good interviewers are looking out for strong coding habits:

Since the problem is 'simple', the focus isn't on whether or not someone can solve it, but how one goes about solving problems and gives that developer a chance to showcase their process on writing maintainable code as a member of a team.īad interviewers only care whether or not the interviewee can actually solve the problem. Why Interviewers Use the FizzBuzz ProblemįizzBuzz is a well-known, simple coding assignment that is commonly used as an entry, technical whiteboard exercise in interviews.

Fizz buzz java