Ask HN: Do you ask to see the codebase before taking a job?
Every developer job that I have regretted taking could have been avoided by first asking to have an in-depth review of the existing codebase I would be working with.
But it seems to me that this is something very few people ever do?
I'm specifically talking about poor coding standards, spaghetti code, monolithic pieces of code that nobody understands and is too scared to changed for fear of breaking something, not enough tests or the wrong kinds of tests etc. The kind of stuff that people say "we really ought to tidy this up" and everybody agrees, but it never gets done. Especially for a large scale application with an existing user base - these kind of poor coding and architectural decisions can be very very time consuming and difficult to change.
43 comments
[ 2.9 ms ] story [ 93.6 ms ] threadThe jobs I've enjoyed the most and learned the most from were incidentally the ones with the worst codebases.
That said, it's probable that there's a certain degree of awful that it's simply impossible to work productively with. As a hiring manager, I wouldn't consider it unusual or a red flag for a developer to ask to see the codebase; and every project has at least some code that isn't too sensitive to share (well, there are probably some exceptions in regulated industries).
If a developer doesn't have the maturity to be willing to work with a codebase that's six years old, where the earliest layers were quick-and-dirty proofs of concept developed without automated testing just to get a startup off the ground, and the latest are better but still flawed, then they're a poor fit here anyway. We need developers who understand that the code exists to serve the business and not for its own sake.
You're absolutely right about that - there is always a balance to be achieved between delivering a feature/product on time and writing maintainable / "good" code.
What would be a red flag for me as an interviewee would be to see a codebase with poor standards, and then see pull requests open with code that wasn't any better. If the quality of the code is only getting worse that makes my life as a developer pretty miserable.
Nothing is perfect but in my experience the difference between working with a well thought-out and architected codebase and something that has been hacked together as proof-of-concept is immense. Fewer bugs, fewer security vulnerabilities, the ability to deliver features faster etc. I don't think that code quality is just something for developers to pat themselves on the back for - it genuinely effects business outcomes.
Bingo. Bad code bases are fine as long as people agree that it needs to be better. I’ve worked on bad code bases that people just do the bare minimum, quick and dirty bull shit they’ve always done, and it’s absolute misery.
Those people do not realize anything is even wrong. :(
This is some of the best advice you can give a developer I think it's known as; The Boy Scouts rule: “Always leave the campground cleaner than you found it”.
Some people I've worked with seem to miss the importance of this...
But generally people can agree on badly designed code eg; bad naming, deeply nested logic, bad structure, tight coupling, no separation of concerns...
Employees always sign stuff to protect the IP. I’d have to go get paperwork from the company attorney to cover non-employees before I can show them anything.
Can they really learn anything about the codebase in the limited interview time we have? They’re not getting repo access.
Why is the candidate asking this question in the first place? It makes me wonder if they’re inflexible or unwilling to be pragmatic about imperfect code. If they have a track record of leaving companies because the code isn’t up to their puritanical standards then it’s a hard pass.
If I see a codebase that is blatantly vulnerable to something like SQL injection (i.e. GET parameters being referenced directly in SQL query strings) then this would probably be a deal breaker for me. I get that nothings perfect but something like that would indicate an extremely poor competency of the development team.
EDIT: That said there is another side of the coin - the kind of place where developers spend hours discussing things like how to name a class or a variable. That would also be a frustrating place to work in - its about getting the balance right. Also seeing the way the developers talk about their code would be interesting - are they dead-set and have an "emotional" attachment to their way of doing things - or are they open to new ideas and willing to discuss pros/cons of differing solutions and make compromises as a team.
Plus, it gives you an honest picture of something you will literally be looking at for thousands of hours. Would you buy curtains without knowing what they looked like?
If someone like you has a bad impression of me even though you understand why I'm asking, then I guess it's a bullet dodged.
I should say that I understand if a company cannot show me their codebase, it is just one thing to consider among many.
Because every company says "we take quality very seriously" and standard crap like that, looking through the code and the most recent contributions is the only way to actually assess them.
> It makes me wonder if they’re inflexible or unwilling to be pragmatic about imperfect code.
Which is perfectly reasonable when the hiring companies try to avoid being pragmatic about imperfect people. They'll give stupid codes tests and look for rockstars, this is the employee equivalent. Rockstars are picky about their collaborations.
> Can they really learn anything about the codebase in the limited interview time we have? They’re not getting repo access.
Ideally I'd want to run some tooling over it and get some stats like cyclomatic complexity and collaboration graphs to see how many pointless layers they have. I'd also take a look at their unit testing to see if anyone in the company actually understands what a unit tests is.
Interviewing is meant to be a two-way street and code review is the only way to address the information asymmetry and make this true.
With that said, for the companies I've hired for in the past someone who sees the state of unit testing as a dealbreaker would likely be a bad fit. If they're hiring it might be because the company needs more hands to help make the tests better!
unfortunately those are things organizations like to make lip service about fixing. often times the state of the project is symptomatic of underlying structural issues in the organization that they aren't really willing to address.
There are other factors too, I work somewhere with mountains of horrible code, but they compensate by not putting you under pressure and giving you time to work through the mess. If they had the same code and constant pressure then I'd be long gone, life is too short for that.
I'm really surprised by the opposition to the idea, we all seem to agree that good devs are in high demand but few on the hiring side seem willing to bend to that reality. We all seem to agree that hiring is expensive but the hiring side doesn't seem willing to let the candidate who will walk in a month eliminate themselves.
Conway's Law. You can lie about your company during the interview. (You probably do, at least a little. In my experience, every company does.) But ultimately, if your company's product is software, you can't fake the quality of the source code. If your teams are dysfunctional, it'll show.
(It can also be apparent in the use of the product, but lots of companies don't make consumer products, so it's not reasonable to expect the applicant to have used your software.)
> Employees always sign stuff to protect the IP. I’d have to go get paperwork from the company attorney to cover non-employees before I can show them anything.
Why? There are very few companies in the world where the source code contains any 'secret sauce'. There's PageRank, and ... that's about the only one I can think of. What exactly are you afraid they'll see? Give me 5 or 10 minutes to look at the source code to Photoshop or Mathematica and I might learn something, but I'll be no closer to launching a competitor, or hurting your business.
What I'm hearing is: applicants are expected to trust you implicitly, while you display absolutely no trust in them. Interviews are already an inherently asymmetric relationship, and you're doubling down on emphasizing your power over the candidate.
Compared to my experience in other fields, this is not normal. It's paranoid and petty on the part of the company, and it's no wonder tech companies have trouble with hiring and retention when they start business relationships this way.
Sure, there may be very few companies in the world where there is 'secret sauce', but the problem is that they all _think_ they have it. If my GC says I can't share IP without paperwork signed then I can't share it - the reason is not relevant unless I have the power or influence in the organization to change the policy. I'm not getting fired over it and (at least at previous companies) I'd get laughed out of the room for even asking.
I'm an engineer myself. This isn't some kind of game I'm playing to pull one over on poor hapless souls - we can argue what ought to be until the cows come home but the reality is that the vast majority of hiring managers have their hands tied by company policy.
The application was developed in C# and ASP.NET and I ended up being quite impressed with how the team handled this. When developing a new feature they made a point to clean up the code they touched to make use of newer language and frameworks features. Also, from time-to-time, there were bigger efforts to clean up specific areas of the code.
This was a 13-year old code base that was in many parts in better condition than many greenfield projects I have seen.
It definitely made my choice to join the team easier.
I have worked at places with terrible existing codebases (including where I work now). I just make it my mission to do what is needed to improve the situation. That in itself can be fun and rewarding.
Also, the vast majority of commercial codebases out there are pretty awful, regardless of language or the size or apparent competency of the company. If you have a low tolerance for working with substandard code, you're going to have very limited options for employment.
Aside from legal reasons, much of this in my opinion is the traditional power dynamic between employer/employee, where the hiring side typically does a lot of due diligence and research into people being hired, and has the upper hand in the negotiation, much more than the other direction.
At least conceptually, I believe developers need to stand on equal ground, to judge and weigh their candidates (employers and clients) in the same way, including, like you say, assessing their code quality before making any commitment, to see if it's up to your standards.
There's always a "discovery phase" before hiring/being hired, where the two sides are exploring what the other has to offer, to determine whether they can be trusted with the work. You can usually poke around enough to discover, for example, what stacks their main product is using, the general level of skills and standards in UX, performance, security, etc.
Some, maybe at increasingly more places, they'd have public or open-source repositories that give a fair insight into the engineering culture. This could be similar to how developers have (or are expected to have) GitHub profiles. I'd take that as a healthy sign of developer-led best practices and transparency in the company.
---
I'd also like to add that the majority of codebases in the wild are bloated, complex spaghetti monoliths of questionable quality. It's just a reflection of limited time, budget, average skill sets, and the real world being practically chaotic. Knowing how to consistently improve the situation is part of being a valuable developer/team.
- How is the physical space, crowding, noise level, workstation quality? How many hours a week do you spend in meetings? How to decision makers think about focus vs. collaboration?
- What is the process by which a proposed code change gets to production, and how long does it take? Code review? Linters? Unit tests? Integration tests? Human QA? CI/CD?
- What is oncall like? How many alerts per shift? Signal to noise ratio? How do you manage incidents? What are postmortems like? Are they about accountability, system hardening, or trying to balance both?
- What are some of the debugging/observability/operational tools you've developed for your product? What are the stories behind them?
- How do decision makers think about tech debt vs. feature velocity? What if any official support is there for getting tech debt items worked on?
- Can I fix & try things on my own initiative in addition to meeting assigned tasks, or must every work hour be dictated by the process/PM? Is an architect telling me exactly how my code has to be structured or am I making my own decisions?
- Where do deadlines come from? How real are they? What happens when a project is looking like it won't meet its deadline?
- What would happen to the business if your team disappeared? What are your current projects and why do they matter?
[1]: https://en.wikipedia.org/wiki/Tragedy_of_the_commons
you have to establish a cultural habit of tidying up a little when you're in there. often accompanied by a 'wow thats much better, thanks for doing that'.
more importantly you have to foster a sense of ownership. a common issue with the worst organizations I've worked with is fear and lack of understanding. the code isn't something we're shaping together - its just some large and awful monstrosity that bites you every time you get near it. every time you start pulling at a thread the whole thing unravels.
so you restrict your scope to as narrow a window as possible, and make the smallest changes you can to fix the bug or add the feature.
its the difference between living in a pleasant little village or a squalid favela.
This is what I'm talking about. Not just "Hey can I see your codebase? Oh, you don't have 100% test coverage and I've seen some variable names that don't make sense, no thanks bye", which I feel is how some people have interpreted my post but I probably could have made that more clear.
I feel like most of these problems can probably be sussed out in other ways. Ask the developers about things that typically lead to a better codebase: do they do code review, testing, QA, etc.
People don't have photographic memories. They aren't going to go home and write this stuff out.
Granted, there are areas where code is perhaps too sensitive for even a quick look. But I think those are the exception.
London based, dealing with Laravel / Vue, fullstack.
If there's no github public code / no code can be provided I ask following things:
- are you following standards (PSR2 for PHP, anything for JS); do you apply linting that makes the standard mandatory
- do you have naming standards
- do you have CI pipeline
- how much of the codebase is unit / feature tested
- how much time within sprint do you spend on fixing existing code
- how much of the job would be working on existing code vs new code
In the end people lie and I picked up a job where some of the things ended diverging from what I was told at the interview
I don't ask to see it, but I've found it effective to ask a simple question: "So, How's your build system?". The engineers at an effective company where everything is in order, will just have this puzzled look on their face and say "it's fine", not really understand just how terrible things could be.
However, for those companies that have huge problems with their stack, the kind of places where builds and configurations break on a regular basis, the kinds of places where you spend half your work hours fighting against configurations and setups, well those interviewers start having steam come out of their ears. After asking this, One interviewer admitted their build system was a hot mess.
I can usually convince people why and how to resolve technical debt. Convincing a shitbag to pay a fucking invoice is much harder.