What actually proves someone is a good developer?
Posted by alkeshjethva@reddit | learnprogramming | View on Reddit | 106 comments
Let’s say two people apply for the same role.
Developer A:
- 500+ LeetCode problems
- Strong GitHub
- Multiple projects
Developer B:
- Fewer projects
- Less activity
- Less public work
But in a real discussion, Developer B understands systems better, explains decisions better and solves problems better.
Who would you trust more and why?
Genuinely curious how people judge this.
Guideon72@reddit
I will just say that in 20+ years working in software development, and a good 12 of that being on hiring teams, I can assure you that no one was ever hired for their LeetCode abilities. It has never once come up in any professional setting and I never even heard the name until I started trying to learn Python on my own.
bitofbeans@reddit
AI slop. How does no one notice
alkeshjethva@reddit (OP)
Damn 😭 I think I’ve just been replying too much today.
bitofbeans@reddit
No correlation between quantity of replies and AI content of your post and replies
BaronOfTheVoid@reddit
My honest opinion is that you have to work for a year with both in order to be able to judge.
Important_Staff_9568@reddit
Good referrals from people you know is the best way to tell. None of what you list for a and b means much.
alkeshjethva@reddit (OP)
I get that for experienced people, but that feels rough for students, self-taught devs or people trying to switch careers.
Not everyone has a network that can vouch for them, so at some point they still need some way to get through the door
Important_Staff_9568@reddit
That is definitely true. It can be a tough business to break into. I have been doing it for a long time and my first job was pure luck of the draw applying at the right place at the right time but every job after that was based on networking.
If A and B are new to the field, their credentials seem pretty even and are mostly window dressing (although I personally might give B a slight edge for the real discussion aspect since that is more relevant to real work). But since they seem relatively even I would hire whichever one seems like they would be easier to work with. That is ultimately going to be more important than one being possibly slightly better than the other.
alkeshjethva@reddit (OP)
The “first job was pure luck” is kind of wild because I keep hearing versions of that from different people. Feels like breaking in and actually doing the job are almost two separate problems.
C0rinthian@reddit
lol if you’re judging me based on my GitHub, then I’m dodging a bullet when you prematurely dismiss me.
Red flag. Too much time playing games, rather than getting real world experience.
Do you also ask candidates for their Wordle streaks?
alkeshjethva@reddit (OP)
Okayyy the Wordle streak line got me 😄
I do think raw numbers without context can get weird though. 500 problems by itself doesn’t tell much. Someone could grind problems for months and someone else could spend that same time building real stuff.
Feels like the context behind the work matters more than the count itself.
C0rinthian@reddit
It also very much depends on the role you're hiring for.
alkeshjethva@reddit (OP)
Yup, That’s fair
Wauwser@reddit
Somebody who gets the job done
alkeshjethva@reddit (OP)
Simple answer, but honestly hard to argue with. Nobody really cares how elegant the journey was if nothing ever ships.
quietcodelife@reddit
the 'why it clicked' part is actually the most revealing piece. that requires understanding not just the answer but the exact shape of your own misconception - which means you had to sit with being wrong long enough to map it.
alkeshjethva@reddit (OP)
Damn that’s actually a good way to put it. Real learning usually wasn’t “I got the answer”, it was more like “ohhh wait… I was wrong because I was thinking about the whole thing backwards.”
Personal_Penalty8219@reddit
Folder structure
6104567411@reddit
There's a bunch of YouTubers that have insane content (the cherno, lauriewired, the new Boston, Sebastian League) that I've never seen do any leetcode nonsense. And I bet some of them have tried it, failed miserably and just never uploaded.
No one cares about that slop. What matters is that you can understand and reference it later in a context when you would need it. For example fizzbuzz is more difficult if you don't know what modulo is. And that would apply to any developer at any skill level for any concept.
AutoModerator@reddit
Please, don't recommend thenewboston -- see the wiki for more info about why we consider them a discouraged resource.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
0xjvm@reddit
Silly post. It could have been simplified to just
Developer A:
Developer B:
Developer B understands systems better, explains decisions better and solves problems better.
Answer is B. Straightforward.
But in the real world many people who only code as a means to work with no real interest doesn’t end up as someone who understands systems better etc
quietcodelife@reddit
the tell for me is how someone describes a bug they couldnt figure out. anyone can walk through a project that shipped cleanly, but talking through something that resisted you - or still does - is a completely different kind of fluency.
alkeshjethva@reddit (OP)
That actually makes a lot of sense. Anyone can explain what worked, but explaining something that completely broke your brain for two days and why it finally clicked feels very different.
LoL_is_pepega_BIA@reddit
Developer A is usually someone who's looking for a job as a developer B
alkeshjethva@reddit (OP)
That's probably true more often than people think.
N7Valor@reddit
I think the more interesting question is:
In the real world, which of the two actually gets hired?
alkeshjethva@reddit (OP)
Honestly? Probably Developer A gets the interview more often and Developer B gets picked more often once they actually get in the room. That’s kind of why this whole thing feels messy.
corvusfamiliaris@reddit
References. Not in a Nepo baby way but someone actually trusted verifying the dude/dudette can walk the walk.
Also, don't be an extremely unpleasant person. The bar for personality is kinda lower compared to the classic office jobs, just don't be someone people dread interacting with.
alkeshjethva@reddit (OP)
The “don’t be someone people dread interacting with” part is probably more important than people admit. I get the referral point too, although that gets tricky for people just starting out since they usually don’t have anyone who can vouch for them yet.
_Being_is_Becoming_@reddit
This could also read as theory versus practice. Being able to spit game isn't the same as actually being capable of building things. Problem solving occurs in the actual development of things.
alkeshjethva@reddit (OP)
I think both can fail in different ways though. Someone can be great at talking and struggle when real problems show up, and someone can build great stuff but struggle to explain their thinking.
Probably why interviews get messy in the first place.
Pale_Height_1251@reddit
B, I suppose.
Leetcode is meaningless, GitHub can sometimes be meaningless because it might all be forks and tutorials.
alkeshjethva@reddit (OP)
I don’t know if I’d call them meaningless though. LeetCode can help with problem solving fundamentals and GitHub can still show useful things.
Feels like the issue is more when people use those as the whole picture instead of one signal out of many.
zugzwangister@reddit
Your question doesn't have an answer.
The hiring process isn't about proving anything. It's about minimizing the risk of making a bad hire for one specific team.
Developer A in your example has higher risk and more unknowns. Maybe they're just stressed by the process and they would be the better developer.
Hiring is part art and part science. You want to get the art right without getting the science wrong and vice versa. What proves somebody is a good developer is that they leave successful projects and happy coworkers in their wake.
If they seem like they can talk the talk and I personally know somebody who vouches for them, that seems like a decent indication.
alkeshjethva@reddit (OP)
The “minimizing risk” part actually makes sense.
I think I was looking at hiring too much like “find the best developer”, when in reality teams are probably asking “who are we most confident won’t be a bad hire?”
AdventurousLime309@reddit
In real hiring, neither “LeetCode count” nor “GitHub activity” alone decides it.
If Developer B genuinely thinks better and understands systems deeper, they often perform better in real work but they still need to prove it through:
Developer A shows consistency and practice, but that doesn’t always equal real-world judgment.
So what actually matters is: can you reliably solve real problems and explain your reasoning under constraints? That’s what good developers are judged on.
alkeshjethva@reddit (OP)
I think that’s probably the part I underestimated when I made the post.
Getting to an answer matters, but being able to explain why you got there and what tradeoffs you made seems to keep coming up over and over in these replies.
namrog84@reddit
This reminds me of an article I read recently
https://darkounity.com/blog/how-i-learned-unity-the-wrong-way
Although it was a bit of gamedev focused. It kind of answers the, this person was more the Developer A, but couldn't land the job type situation.
No affiliation
alkeshjethva@reddit (OP)
That Microsoft story is actually pretty cool. You started with one question and somehow ended up in a completely different conversation because of one random side comment.
Feels like at some point the interview stopped being “solve this problem” and became “let me see how this person thinks.”
TumbleweedTiny6567@reddit
the "understands systems better, explains decisions better" thing is exactly what separates people who can build from people who can grind. leetcode is a skill you can practice in isolation, shipping and making tradeoffs isn't. developer B wins the job at any company worth working at.
alkeshjethva@reddit (OP)
I think that’s why this thread became interesting.
A lot of people started with projects, GitHub and LeetCode, but somehow almost every discussion ended up coming back to thinking, tradeoffs and decision making.
Feels like building something and making it survive real problems teaches a different skill entirely.
dmazzoni@reddit
I've worked at various companies from FAANG to smaller startups to government.
At FAANG companies with centralized hiring (like Google and Meta), they interview hundreds of applicants every day, set a high bar, and hire only the ones who exceed that bar. I'm not saying it's a perfect system by any means, and it weighs too heavily on DS&A, but it focuses really heavily on your ability to code and problem-solve in the interview, less on what your resume says you accomplished.
At most other companies where they don't have such a massive centralized system, it's much simpler than that: each team hires the first person who seems like they know their stuff and seems like a good fit.
Either way, my experience has been that most applicants are terrible at coding. Whether it's new college grads or people with 5 years of experience, the first question I ask is always FizzBuzz-level difficulty and most applicants can't solve it.
It seems absurd to me but that's the reality.
Another half of what remains might fail an easy to medium DSA problem, like something involving recursion in a tree structure.
However, of the ones that remain it's not usually technical things that determine who gets hired. There isn't that wide of a gap between candidates who can code in interviews, if you're not Google.
So it comes much more down to:
alkeshjethva@reddit (OP)
This is probably one of the most interesting replies here.
I expected more emphasis on projects, GitHub or LeetCode, but communication keeps showing up over and over again
Also kind of surprising (and scary) that after the coding bar is cleared, attitude and curiosity start becoming bigger differentiators.
SevenFootHobbit@reddit
I think project, Github, and LeetCode are good for beginners. How do you differentiate between yourself and someone who just went through some tutorials and have only made something basic like a half working calculator or something?
For myself, I don't put anything on github. Because I enjoy self hosting, any coding I do lives on a self hosted instance of gitlab. And honestly, I code enough at work that I don't want to when I get home. I have kids, I have other interests, etc. So my personal projects are small and half done anyway. But if you ask me about work in an interview, I will talk your ear off about what I've been doing. About the first thing I ever did at work, and how proud I am for getting it working despite the rather questionable parameters placed on the project, and about how much I wish I had done things differently with what I know now. I'll tell you about what I do right now, and the challenges we face and what I do to overcome those. I'm not a senior dev, but I'm confident in my long term growth, and happy with my previous accomplishments. I don't think I'd have any trouble getting a job if I get to the interview stage. I do worry though that if I do want to leave my current role, my lack of public work may make that interview harder to get.
alkeshjethva@reddit (OP)
The last part feels like a real problem.
You sound confident about the actual work and experience part, but the worry isn’t “can I do the job?”
it’s “can I get through the first gate?”
Feels like there might be a gap between having experience and having visible proof of that experience.
EntrepreneurHuge5008@reddit
You answered it yourself, my dude/dudette.
Dev A is flashy, but it doesn't matter if they can't justify the decisions they made.
alkeshjethva@reddit (OP)
Yeah that’s kind of what got me thinking too 😄
Anyone can list projects or stack names on a resume, but explaining why something was built a certain way usually reveals much more.
Do you think that only becomes visible during interviews though? Or can it be shown before that as well?
AwayVermicelli3946@reddit
you can definitely show it before the interview if your public stuff goes beyond just the code. tbh i look for repos where the readme explains why they chose a certain stack or how they handled a weird bug. that tells me way more than a perfect commit history.
when i was interviewing for my current role, i had a pretty messy Python project on my GitHub. but i wrote a whole section in the docs about how i messed up the initial deployment and had to fix my Docker setup.
the hiring manager actually brought that exact section up during the call. fwiw, if someone documents their thought process, it totally bridges the gap before they even get to the technical screen.
alkeshjethva@reddit (OP)
Okay this is interesting because this feels way more concrete than just “keep a GitHub profile.”
The Docker part is exactly the kind of thing I was thinking about. Not just what got built, but the mistakes, fixes and decisions behind it.
Sounds like the thinking itself became part of the signal there, not the final project alone.
EntrepreneurHuge5008@reddit
Depends if you're applying to entry-level roles or senior-level roles.
At the entry-level, you don't have a proven record that can be validated by reaching out to your references. Unfortunately, very few recruiters/hiring managers will take the time to look at your portfolio, so it all boils down to whether you even make it to the interview to convince them you know your stuff.
No one cares your Leetcode rank if you put it on your resume, so that's dead weight on your resume.
alkeshjethva@reddit (OP)
That actually makes a lot of sense.
The more replies I read, the more it feels like the biggest struggle at entry level isn’t even skill itself — it’s visibility.
If recruiters barely look at portfolios and both candidates look similar on paper, then getting noticed becomes half the battle.
_everynameistaken_@reddit
What does the justification matter if they consistently resolve the problems they tackle?
Ok_Chemistry_6387@reddit
B.
johnpeters42@reddit
Everyone downvote this bot into oblivion
Lanky_Supermarket_70@reddit
I think and hope that places that are hiring are smart enough to care about how the actual interview it, no company cares really about your resume.
alkeshjethva@reddit (OP)
I partly agree
I think once you’re in the interview, the conversation probably matters a lot more than the resume.
But a lot of replies here also mentioned the hard part is getting through the filters and actually getting into the room first.
Lanky_Supermarket_70@reddit
yea exactly once your in the interview resumes dont matter unless you like cured cancer or smt
davitech73@reddit
when i interview someone for a dev role, i ask questions about how they solve problems. i'm trying to learn how someone thinks. anyone can look up solutions to leet code problems. but it's much harder to fake how you approach solving a problem when you're having a conversation with someone. i want to hire people that can innately solve problems. if you've got that skill, you can look up information on specifics
alkeshjethva@reddit (OP)
Okayyy this is interesting because a lot of replies are landing around the same point.
Not “what did you memorize?” but “how do you think?”
Makes sense honestly. Specific tools and syntax can be learned later, but the way someone approaches problems probably stays with them much longer.
davitech73@reddit
exactly. skills can be learned. the ability to understand cannot
AlSweigart@reddit
"Who is better, a developer that looks better or a developer that actually is better?"
alkeshjethva@reddit (OP)
That feels like the whole problem in one sentence honestly.
Because “actually better” only matters if people get a chance to see it in the first place.
ImprovementLoose9423@reddit
I would go with dev B since most of what dev A did could have been AI'd or googled as they don't understand many concepts as well as Dev A.
alkeshjethva@reddit (OP)
Ahh interesting. A lot of people here seem to trust understanding over raw output.
Although I wouldn’t immediately assume Dev A is bad either. Someone can grind LeetCode and still be solid. Feels more like the real question is whether they actually understand the decisions behind what they’re doing.
ImprovementLoose9423@reddit
I agree, however you must remember the fact that dev a is showing only the completed project, and not how he actually built it. You also verified that Dev B actually understands concepts much better than dev a.
alkeshjethva@reddit (OP)
That’s fair actually.
I kind of stacked the comparison against Dev A by only showing the output and against Dev B by showing the understanding.
Feels like the missing part is how someone got from point A to point B, because that’s where the thinking usually becomes visible.
Rhemsuda@reddit
They know the consequence of every action they take
alkeshjethva@reddit (OP)
That’s actually a good way to put it.
Beginners usually ask: “Will this work?”
Experienced developers often ask: “What will this break six months from now?”
Main-Lifeguard-6739@reddit
sounds like you see yourself like developer B
alkeshjethva@reddit (OP)
Maybe a bit.
I think a lot of people early in their career probably see themselves as Dev B though.
You can be learning a lot, building things and improving, but still feel like none of it is visible until someone finally gives you a chance.
NotACoderPleaseHelp@reddit
As the load bearing veteran of many a group project... I'm leaning to B. Leetcode problems can be googled/AIed, GitHub is rife with 'not plagiarism' and projects really needs to be defined in this use case. Are these open source? Private projects? How developed are these projects?
FourTwentyBaked@reddit
Yes. I interviewed a guy recently who had a bunch of github projects to show off. It worked against him 100% because they were all just meaningless drivel with perfect naming conventions and formatting. That isn't experience doing anything.
alkeshjethva@reddit (OP)
That’s interesting
So having more projects wasn’t the issue, it was that they didn’t show real thinking or real problems being solved.
Feels like “I built 20 things” and “I actually learned something from building 20 things” are very different signals.
FourTwentyBaked@reddit
Absolutely. The last thing I want to consider is a carefully curated interview portfolio. Get out there and work, solve a real problem and tell me about it.
alkeshjethva@reddit (OP)
I think that’s an important distinction actually.
You’re not against showing proof, you’re against proof that was built only for the interview.
Real work usually comes with tradeoffs, mistakes, weird bugs and decisions you didn’t expect to make
alkeshjethva@reddit (OP)
That’s fair 😄
The more I read replies here, the more it feels like raw numbers don’t mean much without context.
500 problems solved tells me less than seeing how someone thinks, builds and handles real situations. The project details probably matter more than the project count itself.
_QuirkyTurtle@reddit
B. Idc about leetcode or your public GitHub if I’m hiring for my team.
I care if you can design a system, communicate with non technical stakeholders and if you’re a team player.
alkeshjethva@reddit (OP)
That’s interesting actually.
Most replies here seem to be moving away from raw coding metrics and more toward thinking, communication and decision making.
Out of curiosity, for someone junior with little real-world experience, how would you evaluate those things before they get a chance to work on a team?
Vandrel@reddit
I've been working as a dev since 2018 across 3 jobs and interviewed for a number of others. Not once has anyone even mentioned leetcode or GitHub profiles including for hiring decisions I've been loosely involved in. I'm sure there are companies out there that do care about that stuff but a lot don't.
alkeshjethva@reddit (OP)
That’s honestly interesting because it’s becoming a repeated pattern across the replies here
I started this thread expecting GitHub activity and LeetCode to come up a lot more, but most people with hiring experience seem to care more about problem solving, communication and real work experience.
Feels like the internet talks about one game and actual hiring sometimes plays another.
_QuirkyTurtle@reddit
We’ve not hired juniors in a while but generally I wouldn’t be asking them to design me a system or anything like that on a whiteboard.
We can judge their communication just from them telling us about their experience or things they’ve worked on, even if that’s in university.
Decision making wise I might present them with a fairly simple problem and ask them how they’d solve it. Then if I wanted to know more I’d ask more proving questions as we go.
alkeshjethva@reddit (OP)
This is actually useful to read.
What’s interesting is you didn’t mention GitHub streaks, LeetCode counts or flashy numbers at all 😄
You mostly described understanding how someone thinks and communicates.
Seems like for juniors, the challenge becomes finding a way to make those things visible before getting into the room.
_QuirkyTurtle@reddit
Yeah I’d say you’re right. The hardest part is often getting the interview. Then you just need to be you.
I can tell you in any of the interviews I’ve done we’ve never asked about GitHub streaks etc. Perhaps FAANG companies do but I work for a pretty big UK fintech.
alkeshjethva@reddit (OP)
Interesting!!!
So the repeated pattern I’m seeing here is: getting the interview is the hard part, not proving yourself once you’re in it.
Funny thing is I expected more people to mention GitHub activity, but almost nobody seems to care about it in actual hiring conversations.
_QuirkyTurtle@reddit
Well don’t get me wrong, the interviews can be hard too! But if I’m hiring for a junior the main thing I’m looking for someone keen to learn and that meshes well with the team. Obviously you should have technical knowledge and understanding of fundamentals as well.
alkeshjethva@reddit (OP)
This thread is slowly changing how I think about it
I expected more emphasis on project counts and activity, but a lot of people hiring seem to care more about learning ability and whether someone works well with others.
Feels like raw output matters less than showing potential and how someone thinks.
FourTwentyBaked@reddit
I would see if they ask clarifying questions to something they do not know.
RainbowCrane@reddit
Yes, this is the key thing to evaluate with a junior developer. We used to do team interviews, so a manager plus 2-3 senior developers would be in the room. A really great candidate would be able to overcome any initial nervousness by 10-15 minutes into the interview and have technical discussions with the senior developers. We did pair programming, so sometimes we’d simulate that by walking through an algorithm together at the whiteboard.
You don’t expect the junior developer to stun everyone with amazing algorithmic design. You want them to be able to discuss algorithmic complexity with the assistance of the senior developers and articulate why one algorithm is logarithmic time while another is exponential time, and why the quick and dirty exponential version could be acceptable for small values of ‘n’.
One big caveat: interviewing junior developers is a skill, just like mentoring juniors is a skill. It’s cruel as hell to throw certain senior developers in a room with folks who they consider to be their inferiors. When we were doing “recruiting classes” to hire 3 or 4 juniors at once we always picked an interview team who were willing to put in the effort to make folks comfortable in a naturally uncomfortable situation
thequirkynerdy1@reddit
It's unfortunate, but for our industry getting a job and actually doing the job are fairly different skillsets (albeit with some overlap).
Leetcode is mostly for interviews. The basics are useful (e.g. you should understand what a hash table is), but the tricky kinds of problems you see in interviews virtually never come up.
Side projects do build skills, but you can also build skills through spending more time on your day job so the lack of side projects isn't a bad indicator.
alkeshjethva@reddit (OP)
This might be one of the biggest takeaways from all these replies honestly.
Getting the interview and actually doing the job seem to be different games.
Feels like interviews optimize for filtering people quickly, while real work optimizes for problem solving over time.
sad_ant0808@reddit
i mean depends if dev B can actually build stuff and can use all his knowledge and understanding in a real world scenario and apply it then obviously hes a better dev.
alkeshjethva@reddit (OP)
Yeah I agree with that.
At the end of the day, building real stuff changes things. You can solve 100 problems, but applying that knowledge when requirements change, edge cases appear and things break is a different skill entirely 😄
sad_ant0808@reddit
yep. knowledge is nothing unless you can apply it somewhere.
FourTwentyBaked@reddit
Always B. I would ask dev A about their personal life a bit, not in an illegal way, but to gauge if they do anything but sit at a computer. Liked, do you have any cool hobbies? If the answer is game dev or something I'll probably pass on them.
alkeshjethva@reddit (OP)
😄 Interesting take.
I wasn’t expecting hobbies to enter the discussion, but I get what you’re saying. Someone being technically good is one thing, but being someone people actually enjoy working with is another.
FourTwentyBaked@reddit
Dev A likely isn't actually technically good.
alkeshjethva@reddit (OP)
Maybe not necessarily.
Dev A could still be technically good, just optimizing for the wrong signals.
The replies here are making me think the gap is between looking good on paper and actually showing real engineering ability.
Alextherude_Senpai@reddit
Not a recruiter or anything, but this feels like a loaded question, Developer A makes it through the door most of the time simply because of their resume surviving more filters. B is generally only making it through if they have connections or sheer luck of bulk applies.
Whoever can explain the thought process and procedures of how to carry out the task would be getting the job regardless.
FourTwentyBaked@reddit
Yeah. The selection filters are for the essy part of the job.
For example, if I didn't have Java on my resume, but I had ten other programming languages i may be filtered out.
If i was a bike riding job and the specific bike was a 12 speed my resume has strait, three speed, five speed, ten speed, and 18 slide you can safely assume a 12 speed won't be a problem for me. The filters appear to assume I cannot ride a 12.
Filter for engineering skill, not specific tools people! Skilled is skilled.
alkeshjethva@reddit (OP)
That bike example actually explains it really well 😄
I get why filters exist when there are thousands of applications, but sometimes it feels like they end up measuring tool matching more than actual ability.
Someone can learn a framework in weeks. Problem solving and engineering thinking usually take much longer.
alkeshjethva@reddit (OP)
This is actually a really interesting point.
Developer B might be better, but Developer A probably gets seen first because of filters and visibility.
Feels like there are two separate problems here: getting through the door vs proving yourself once you’re inside.
NotLomatic@reddit
yes but having a non flashy resume does not even gets you past the ATS. Dev B never gets that far
i am dev B in real life trust me on this
alkeshjethva@reddit (OP)
This is actually something I wasn’t thinking enough about.
A lot of people here are saying communication and thinking matter more, but you still need to get through the first gate before any of that matters 😄
Feels like getting noticed and proving yourself are two separate problems.
OverLiterature3964@reddit
I personally know zero good programmers who think solving leetcode is impressive. Focusing too much on it thinking it's important is a negative point for me.
Frolo_NA@reddit
figure out who communicates better. that's more important
alkeshjethva@reddit (OP)
Honestly, a lot of replies here seem to be pointing in that direction 😄
Technical skills get you noticed, but communication probably decides whether people actually want to work with you.