How to improve code review skills?

Posted by mohammadmaleh@reddit | ExperiencedDevs | View on Reddit | 36 comments

Hello, I'm a frontend developer with 10 years of experience, I'm not the smartest dev you encounter.

I think I'm still mid level, I'm not able to get mid level interviews, I'm getting only senior level interview

Most of my career, I have worked solo, only 2 years of the 10 I worked with a team

I can produce really nice and clean code,

But I'm really bad at reading others code,

I'm finding it hard to join new teams, since I really can't understand the code from reading, unless I directly work on it, I won't be able to understand it

And while interviewing, I fail miserably when I get asked to review a piece of bad code

Do you have any suggestions for me to improve?

[-]

ConstructionOk4493@reddit

Man, I just built the platform for this: https://holynit.com/

Use it and give me your honest feedback!

[-]

Peace_Seeker_1319@reddit

reading code is totally different skill than writing it.

try this: pick random PRs on github projects you don't know. try to understand what changed. then read the actual review comments to see if you caught the same stuff.

also trace execution don't just read top to bottom. follow what actually runs. i use codeant.ai sometimes to visualize execution flow when code is confusing. makes it way easier to understand what's actually happening. you're not bad at this you just haven't practiced it much.

[-]

sweetno@reddit

If you want to improve it, how would you measure it?

[-]

Peace_Seeker_1319@reddit

reading code is a different skill than writing it. 10 years writing doesn't automatically mean you can read.
what helped me:

1/ start with execution flow, not syntax. trace what happens when code runs, don't just read top to bottom
2/ use tools that visualize behavior. sequence diagrams showing what calls what makes unfamiliar code way easier to parse
3. practice on open source repos. review random PRs, compare your findings to what maintainers caught

for interviews where they give you bad code: focus on runtime issues (race conditions, memory problems, edge cases) not just style. that's what separates senior from mid.
we use stuff like codeant that generates execution diagrams from code. helps understand what code actually DOES vs what it SAYS.

[-]

Chocolate_Pickle@reddit

Saw this posted on here a few months ago.

https://conventionalcomments.org

I immediately bookmarked it, but I've so far not needed to direct anyone towards the advice it has.

[-]

DoubleAway6573@reddit

I'm good reading bad code. That's the only way I can read what I wrote!

[-]

NonProphet8theist@reddit

Run it locally.

[-]

mohammadmaleh@reddit (OP)

I just finished an interview and got rejected on the spot

they just give me a really bad code, that is not runnable, a lot loops, with no context, no data, no description or types to understand it

I asked them to explain it, i found couple of problems, but didn’t catch all the vulnerabilities

Later they gave me a very nich function related refresh rate in browsers, they asked me to read about it and explain it on the spot

They expected me to understand everything the without a context

I failed miserably and feeling bad about it

[-]

DoubleAway6573@reddit

Don't bother for that. We all hit with bad interviewers.

I used to review a lot of code, before our team shrank, but had an interview where they gave me a 10 lines python code that "a senior made and since he left nobody touched, but now we going this fail for this and only this case".

Bad naming. Stupid transformations back and forth (multiplying and dividing by 10 the same variable) and they wanted me to say that the problem was a comparison between floating point numbers...... All the code was trash.

I think I dodged a bullet.

[-]

NonProphet8theist@reddit

Well there's your issue. If you can't fix things to run in your local environment, you won't get very far.

[-]

mohammadmaleh@reddit (OP)

The code was a screenshot

[-]

NonProphet8theist@reddit

So what

[-]

mohammadmaleh@reddit (OP)

I couldn’t debug it

As I mentioned my reading skills are bad

If i was able to run it without the pressure of 3 engineers asking me left and right, i think i would do better

Anyway thanks for the suggestion

[-]

NonProphet8theist@reddit

Just keep at it

[-]

necheffa@reddit

You kinda just have to read more of other people's code to get used to it and develop your own system for inspection.

If you really want to buckle down, find a FOSS project, especially one in a language you use professionally, and see if you can't read through part of it. Maybe even make some changes even if you never share the patches.

Running code through the debugger is a good technique.

[-]

avoid_pro@reddit

Can you suggest decent project written in JS/TS? Not even sure which ones to consider as examples to follow (maybe with many github stars)?

[-]

necheffa@reddit

Couldn't tell you. I do HPC professionally which is decidedly not anything JavaScript. And when I do web on the side it is something like Go + HTMX.

[-]

DoubleAway6573@reddit

HPC in is. I'm LOLing so hard by that idea.

I'm working in math heavy, but way outside HPC and wouldn't dare to attempt it in js.

[-]

Academic_Painter_897@reddit

solid advice right here. digging into open source stuff def helps sharpen those code review skills and boosts confidence too

[-]

mohammadmaleh@reddit (OP)

Thanks for the suggestion

[-]

zamkiam@reddit

Have them provide screenshots or videos of it working based on the acceptance criteria

[-]

ruibranco@reddit

Fellow frontend dev here. The 8 years solo thing is key context - code review is fundamentally a social skill disguised as a technical one, and you can't develop it alone. Some concrete things that helped me: (1) Start reading open source PRs on repos you use daily. Pick a framework or library you know well and read their merged PRs. You'll see patterns in how maintainers review and what they flag. Angular, React, or whatever you use - their PRs are public on GitHub. (2) When reviewing, don't try to understand the entire codebase first. Focus on: does this change do what the PR description says? Are there obvious bugs? Are there edge cases not handled? Is the naming clear? That's 80% of a good review. (3) For interview code reviews specifically: they usually want you to spot bugs, security issues, performance problems, and style inconsistencies. Practice by reviewing code on sites like exercism.io or just grab random GitHub repos and try to find issues. (4) The real skill gap isn't reading code - it's reading code with PURPOSE. When you work on a codebase directly, you have context. In a review, you need to build context fast. Train this by cloning repos you've never seen and trying to fix a reported bug. Forces you to navigate unfamiliar code under pressure. The good news: 10 years of writing clean code means you already know what good code looks like. You just need practice applying that judgment to someone else's work instead of your own.

[-]

mohammadmaleh@reddit (OP)

Thank you for writing this in depth

Will look at your suggestions for sure

[-]

yxhuvud@reddit

One way to get good at reading other peoples code is become the sole maintainer of a bigger project, while having noone to ask for help understanding it. I wouldn't want to go back to that year, but oh boy did I learn a lot when it comes to how I want code not to be structured.

Also it is fairly likely that what you consider nice and clean will change by that kind of experience.

Another thing that really helped was to develop a thing that was sufficiently big that the only way to reason about it was to blackbox the parts not currently under scrutiny in your mind. When you learn to fold different parts of the code you develop a big dislike against things that make that hard, and that is generally speaking very, very often also the things code review should be critical of.

[-]

mister_mig@reddit

Yes, make a checklist or even a SOP.

Use it periodically - and you will learn in tacitly.

[-]

Recent_Science4709@reddit

People use AI to vibe code but it’s good at explaining code that’s hard to read, have you tried that?

[-]

mohammadmaleh@reddit (OP)

I do that as well

But in interviews i cant do that

Im just not good at read bad code , and suggesting better alternatives

[-]

Recent_Science4709@reddit

In the context of an interview unknowns, all you can do is practice. GitHub has all the code you can read, and plenty of it is terrible; search by the language and practice, see if you can figure out what it’s doing, and then ask AI and see if you got it right.

[-]

mohammadmaleh@reddit (OP)

Thanks for the suggestion

[-]

Cultural_Shop4886@reddit

Honestly, this hits home for me too 😂 I spent like 6 years mostly working alone and when I finally joined a bigger team, reading their codebase felt like deciphering ancient hieroglyphs. What really helped me was starting small - I'd pick one component or function at a time and actually trace through it step by step, even writing comments for myself about what each part was doing.

For the interview prep, I started doing code review practice on sites like Exercism or just grabbing random repos from GitHub and trying to spot issues. The key thing I learned is that most "bad code" in interviews follows the same patterns - missing error handling, unclear variable names, performance issues, or violating SOLID principles. Once you start recognizing these patterns, it gets way easier.

Also don't beat yourself up about the solo work thing - that experience definitely has value, you just gotta frame it right. Maybe mention how you had to be extra careful about code quality since there was no one else to catch your mistakes? 💀 That's actually pretty impressive for 8 years of solo dev work.

[-]

mohammadmaleh@reddit (OP)

Will look at your suggestions, many thanks

[-]

cdcasey5299@reddit

I hate doing code reviews, always have. What helps me sometimes it talking out what's happening while I'm reading it. It's always been an expensive context switch for me, though. And yeah, now at work I get AI to assist me with them (and sometimes it's helpful).

[-]

mohammadmaleh@reddit (OP)

I feel you

Wish i can use AI in interviews lol

[-]

aviboy2006@reddit

Code reading thing is actually a skill you can practice separately. What helped me was picking open source repos - whatever framework or library you already use and just reading through them without running anything. Like I used to pick up Angular or NPM library PR's to see how others do things. Start small, like a single utility library. After a few weeks you start recognising patterns faster.

The interview code review thing is different - you need to spot common mistakes and explain what's wrong with them. Maybe practice on r/codereview posts, just look at what feedback others give.

Also since you mentioned you write clean code - try throwing your own code at an LLM and ask it to find edge cases or criticise it. You might catch stuff you didn't notice before.

[-]

mohammadmaleh@reddit (OP)

Thanks for the suggestion

I didn’t know about this sub

Checking it out now

[-]

private_final_static@reddit

Practice makes perfect.

Fail a lot, grt confy doing it and dont fret.