In coding interviews, what does "good code quality" mean?
I've looked through the code quality course but for the purpose of an interview can I get a checklist of things that the interviewer will be looking for in terms of code quality?
For reference I'm a junior SWE and I plan to use Python.
Discussion
(9 comments)- 5
4 months agoFriendly TarodactylTaro CommunityI could be totally wrong, as even I am working through this too, but what I'd think for the context of DSA, while this isn't comprehensive I'd focus on:
- using list comprehension wherever the logic is appropriate,
- for lexicographical comparison, make sure you use ord() so you are not writing lots of code to check if a is less than b.
- Sentinel values are huge, cuz you don't want to do any weird logic to handle the ends of your array.
- I think Alex mentions in his article how throwing array indices throughout the code instead of declaring a variable for them is a red flag, which I have adopted in my practice. (https://www.jointaro.com/blog/meta-software-engineer-onsite-interview-question-breakdown-k-closest-points/)
- In other cases, after doing a couple problems in the pattern type for DSA, I try to read the code so I get the clean code constructs, as there are a couple key readable syntax stuff I picked up going down this rabbit hole:
- For example, writing the code for boundary checking in grid search can get verbose and slow you down unless you use the inequality way of writing such that a <= b < c instead of a <= b and b <c
- 04 months agoFriendly TarodactylTaro Community
I'm assuming you do the other stuff like talk to the interviewer, try to get sign off on the approach, discuss the tradeoffs, and verify your code line by line in the interview as well. The main thing is the more readable the better, and it's a continuous practice.
- 04 months agoSoftware Engineer [OP]Taro Community
Awsome, thank you!
Can you elaborate on the array indices bit? I dont think I see it in the blog you linked. Is it mainly just not using raw numbers like arr[:4] and isntead doing arr[: stop] or something?
Also a bit confused on sentinel values. Would you elaborate on that?
- 14 months agoFriendly TarodactylTaro Community
For K closest points you have X and Y indices. The idea is that you should do x = point[0] and y = point[1] instead of referencing point[0] and point[1] everywhere in your code.
- 04 months agoSoftware Engineer [OP]Taro Community
Ahhh gotcha, thank you!!!
- 4
4 months agoTech Lead @ Robinhood, Meta, Course HeroI did 150+ interviews at Meta and Robinhood (2 top companies known for being very picky with engineers), so I can explain here in-depth. Coding interviews are extremely time-constrained, which is why I wasn't expecting beautifully crafted PRs from candidates.
However, I was expecting them to get all the low-hanging fruit when it comes to code quality as I break down in the code quality course starting with this lesson: https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/code-comment-caches/
In particular, I wanted candidates to have:
- Good names
- Some amount of code modularization (e.g. if you are using an OOP language, use classes as appropriate)
- Not too many conditionals, especially nested ones
On top of that, I expected good edge case coverage, because if you're working at a top company like FAANG, your code can live or die on the quality of that. Here's a great thread about that: "How do you find edge cases in DSA problems for FAANG?"
The code quality course talks about the edge case angle in far more depth as well in a way that's relevant to both DSA and system design: https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/sweat-the-details-call-out-edge-cases/
- 14 months agoSoftware Engineer [OP]Taro Community
Thanks Alex, what's the verdict on comments? In DSA I usually add in comments as placeholders/explaining the reasoning. But ofc in production I dont add in tons of comments and follow the guidelines in the course you mentioned.
e.g. I might add a comment saying
# tree has one leaf code # tree has no leaves code - 04 months agoTech Lead @ Robinhood, Meta, Course Hero
The best code is self-explanatory, but in an interview context and outside. A couple comments here and there is okay, but the ideal code doesn't need any comments at all.
For interviews, comments are less important as you essentially get to feed "live" comments to the interviewer in real-time so they can understand what each part of your code is doing.
- 04 months agoTech Lead @ Robinhood, Meta, Course Hero
Ah, the example with edge-cases is nice. Covering edge-cases tends to be if-statements at the top of the method for DSA problems so they don't really harmonize with the rest of the code, being more of an awkward bolt-on instead.
Regardless, I don't think comments are necessary there. Since edge-cases are usually a section that comes after the core problem solving where you can walk the interviewer verbally through each edge-case as you code it out. But if you want to do comments so your own brain can follow, go for it.
