# 12 Simple Coding Interviews Do's and Dont's

Many interviewers intentionally ask the question in an ambiguous fashion to invite clarification questions. Before proceeding, ask the interviewer some clarification questions such as

• “What should I do if the array is empty”
• “Can I expect the input to be reasonable?”
• “Can there be duplicates in the input array?”

If you need to assume something - double check your assumption with the interviewer!

1. Always let your interviewer know what you are thinking as he/she will be as interested in your process of thought as your solution. Also, if you’re stuck, they may provide hints if they know what you’re struggling with.
2. Approach the problem as if you were trying to solve it with a colleague, in which case it would be more of a discussion than a test.
3. It’s totally normal to struggle at a problem especially if you’ve never seen it. Be calm, start from a brute force solution, and mention to the interviewer that you’ll now start to optimize. Start from a few basic cases and try to generalize into a solution.
4. Listen - don’t miss a hint. Your interviewer is trying to assist you! Being able to take hints shows that you are open to new ideas.
5. Never stop optimizing. If you think your algorithm reaches the best possible run time, then try to improve on the space complexity.
6. Write clean code. Break a long function into smaller independent pieces shows good design, makes your code understandable and easily testable.
7. If using Java, proper use of an interface, generics, final/static are all a plus.
8. Discuss trade-offs. For this problem, why did you use a hashmap instead of a hashset? Why is it better to use iteration instead of recursion? If a problem can be solved in two ways – implementation A requires linear time complexity and quadratic space complexity and implementation B requires quadratic space complexity and linear time complexity, when would you use which?
9. Saying what you know can get you easy points. Specifically it will convey a lot of your knowledge while spending little interview time. For example, “I would normally use StringBuilder, but in the interest of time, I’ll use the + syntax because it is quicker to write.”If you are familiar with a more complex data structure or algorithm that fits a particular situation, mention it. Be ready for follow up questions. (ex: skip lists or binary indexed trees)
10. Don’t stress small syntactical errors. If you can’t remember whether the method is substring(start, end) or substring(start, length), just pick one and let your interviewer know. In the real world you could just check the documentation or even autocomplete. Don’t worry about occasionally missing a semicolon either.
11. Interviewers tend to leave the last ten minutes of the interview for you to ask about the company culture, work environment, interesting projects they’ve worked on, etc. So prior to the interview, do some research about the company or the team and come prepared with some questions to show your interest.

Enroll Now