12 ms·

Ask HN: Do you ask to see the codebase before taking a job?

• gshdg 7y ago
  No, because the quality of the existing code isn't what affects my interest in the job. The vast majority of software out there has mediocre structure at best. Your responsibility is to improve it gradually, leaving each function or module you touch a little bit better than you found it. The 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.
  • world32 7y ago
    > 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.
    • duncan-donuts 7y ago
      > 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. 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.
      • Aeolun 7y ago
        > 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. :(
  • deleted 7y ago
    [deleted]
  • gitgud 7y ago
    > leaving each function or module you touch a little bit better than you found it. 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...
    • Aeolun 7y ago
      Sometimes this has been really hard when the campground was already spotless.
    • yen223 7y ago
      The problem is that someone's definition of "cleaner" can be wildly different from yours. Sometimes even justifiably so.
      • gitgud 7y ago
        Yes people can disagree on what "cleaner" code means. But generally people can agree on badly designed code eg; bad naming, deeply nested logic, bad structure, tight coupling, no separation of concerns...
      • JohnFen 7y ago
        That's the reason that all companies should have in-house coding standards. There are many different legitimate variations on "clean code", so the important thing is that one variation is chosen and used consistently by all devs. Which variation is chosen is less important.
• remyp 7y ago
  I’m always surprised when candidates ask for this. I can see why they would want to, but it presents problems for the company: 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.
  • world32 7y ago
    It doesn't necessarily mean they have puritanical standards. But for me it would offer a glimpse into what its like to be a developer at a company. Like, does the company tell developers to just "make it work" in the quickest amount of time possible or does it let them come up with a proper, maintainable solution thats not going to cause headaches for future developers? 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.
  • odyssey7 7y ago
    The code base is a reflection of the values that are at play in the company's development process. It's a kick-the-tires defense against puffery, which is something a recruiter is perfectly allowed to use to get you to sign a contract. 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?
• jerriep 7y ago
  At my previous company, I asked to have a look at the code base before joining. The reason was that this was a system that has been in development for the past 13 years and I wanted to get an idea of how well they handle tech-debt on such an old code base. 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.
  • naushniki 7y ago
    Thanks for your explanation. I think the real question here is to what do you pay attention when you inspect codebase of your potential employer and what conclusions can you make from it. Your comment answers that. I also think the fact that you were able to make those conclusions gives you additional credit in the eyes of the potential employer.
• yowlingcat 7y ago
  The easiest way to accomplish this, practically, is to do contract-to-hire. Do a couple of pull requests and take the temperature of what it's like to work there, and you'll figure out pretty quickly whether it's for you or not. Of course, many companies are averse to this for a variety of reasons -- at the end of the day, there can be agency problems if there isn't a base level of good faith commitment from both parties.
• JohnFen 7y ago
  I never have, and I probably never will. I'd be surprised if a potential employer would agree to doing so (why would they? It's additional risk and expense for no gain.) 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.
• lioeters 7y ago
  In my experience, for most companies and projects, you'd have a hard time earning the trust to have much in-depth review of existing codebases, before getting hired. 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.
• closeparen 7y ago
  I've been compiling a mental list of things I want to know about a potential team. The code itself is not one of them - too sensitive to get access to, too large and context-dependent to evaluate from an outside perspective. But I do have a bunch: - 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?
  • rebelrexx858 7y ago
    I also like to ask what tool does the team use that the interviewer personally doesn't like, a different way around, whats the worst part of your job.
• shortoncash 7y ago
  I work at a place where the culture is definitely "everybody should tidy this up" and it never changes, or it changes very slowly. What I'm finding though is that there's no real defense against this kind of culture other than to be really tight about hiring. So, to your point, if you came to my company asking to look at source, it'd be a good thing -- particularly since so few people actually do it.
  • fredley 7y ago
    If the responsibility lies with everybody, nobody will do it[1]. There must be some rule or process whereby the job of tidying up something becomes a specific person's job - be it if they are committing changes to the same file, or whatever. [1]: https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons
    • convolvatron 7y ago
      not necessarily. if we're all working on a code base and reviewing each others work, and we all value cleanliness, things can reach an ok steady state. 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.
      • world32 7y ago
        You expressed what I was trying to get at so perfectly and so much better than I ever did. 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.
• ioddly 7y ago
  I've done this once ever, I was being asked to build an extremely technically difficult proof of concept so I asked for access and it was granted. I had already worked for the client previously so there was some trust, and they were thinking of open sourcing the project once it was farther along anyway. I wouldn't expect to have it happen again. 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.
• jcrben 7y ago
  I think it's surprising that people are saying the code is too sensitive to view. We live in a world in which an increasingly large portion of code is open-source. Is it really that big of a deal if a prospective hire gets a glance at your CRUD web app code? 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.
• eithed 7y ago
  Yes - I want to see exactly what you're talking about. So far, there were 2 places where I interviewed at (out of roughly 50) that could provide this information. 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
• thorwasdfasdf 7y ago
  Messy codebase is one thing, but messed up build/configuration system is much worse. 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.
• stephenr 7y ago
  No. In general I’m less worried about bad code (more often than not I’m contracted to fix said bad code) as I am a shit working arrangement. I can usually convince people why and how to resolve technical debt. Convincing a shitbag to pay a fucking invoice is much harder.