Ask HN: How to advocate for prospective employers to show us their codebases?
Sometimes a new job or contract will come with the discovery that the codebases on which we are asked to work are not what we were expecting, to put it lightly.
Such as,
* saturated with anti-patterns to the point that it's a massively negative impact on productivity
* excessively long compile / build times due to lack of maintenance and/or things just not being built well
* severely outdated tooling and versioning
etc.
While this can be a workable situation sometimes, an opportunity to contribute in a meaningful, positive way, in others it can be a tedious slog.
A developer can ask questions during the interview process about these things, which can sometimes illuminate these issues.
If an organization's developers are active in open source contributions, that can be a helpful signal as to the quality of a codebase.
And, it occurred to me that there's a big double standard in hiring around this. It seems like the software development process, generally speaking, is built on what is essentially a lack of trust in engineers - we can come in with over 10 years of verifiable experience, talk eloquently about that and our abilities, and still be met with these ridiculous and demeaning puzzles.
Why should we not be able to look at the code at a place we are thinking about working at? It's a CORE part of the job. To be blind to that doesn't feel right to me.
If/when I decide to look for a different position, I'm considering to ask employers if they would be willing to let me sign an NDA so that I can take a look at the code on which I'll be working. Or at least some portion of it.
I'm curious how this idea lands for people reading this post. I can envision a world where this is standard practice in hiring.
I'm curious to also hear reasons as to why this couldn't work in practice.
EDIT: changed non-intentional ultimatum-esque language
63 comments
[ 5.4 ms ] story [ 145 ms ] threadThis is called a "power imbalance". So long as it's possible to recruit developers despite all these things, they will continue. Unless you manage to cartelize people into refusing to work under those conditions.
I definitely wouldn't phrase it as an ultimatum in the hiring process.
I would say something like, "I'd like to understand what I'll be working with. Would you be up for letting me sign an NDA so that I can view the codebases on which you'll be having me contribute?"
If there's pushback on that and they are asking me to do a puzzle, I might then frame it as follows:
"I understand that you need a strong signal about the skill of engineers you hire. I also need a strong signal about the technical elements where I'll be spending the vast majority of my time. How can I gauge this without looking at some of your code?"
And just go from there, depending on their answer.
Perhaps I'll edit to reflect that.
this is the double standard.
just as, through their actions and words, a company is saying, "we need you to do Y in order to move forward", the engineer can also communicate that "I need you to do X in order to move forward." both needs are equally valid.
the way this would be presented and communicated about in the interview process definitely matters - if a prospective employee presents this need in an antagonistic way, that can definitely be a flag.
this need can be shared in a collaborative, kind, and curious fashion. that's how I would work to frame it.
I am sure you mean well and you don't do this maliciously, but the end result is still this oppressive machine like system.
Your comment hits me hard because it just shows the covert way we perpetuate this uncaring system.
I think OP's idea is brilliant (putting aside concerns of copyright). It is a evidence based approach to determine a lot of things from the engineering culture.
I was once rejected from an interview because I was asking "too many questions about how the work is done" this led the interviewer believe that I was "too focused on that and probably wasn't a good team player". Reading between the lines, it seemed he just wanted to hire another drone.
I really wish I could escape from this industry sooner. I frankly hate this.
I updated my comment in terms of framing it as an ultimatum - that's not what I would say in the interview process.
Showing examples of fake code seems like a possibly great middle-ground here. As long as that code is an accurate reflection.
Personally I value other factors such as work/life-balance, coworkers, work-benefits and salary higher than the individual task I’m completing on a day to day basis.
And agree with you, to a point, that an engineer "should" be able to work with any task or codebase. We aren't primary care doctors in a community clinic who are obligated to treat every person who comes through the door.
I know myself pretty well. I know the kinds of environments in which I am most productive. I know the kinds of environments that I find to be a tedious and mentally exhausting slog. I prefer to avoid those. Some codebases are just awful to touch. I think it's OK to have some boundaries around that.
If seeing the codebase is an important part of your decision (ie not just knowing what stack/libraries are in use) you may wish to apply for an open source oriented company.
I'm trying to get a sense of whether or not _any_ companies would be willing to do this.
Some of the code was the worst I've ever seen. 50 classes in a single file, 10,000 lines long, almost impossible to navigate, due to needless OO "lasagna" layers.
(They sure had lots of unit tests though!)
That's to weed out people who did a 'bootcamp' or watched one youtube video and decided to quit flipping burgers and call themselves a 'senior engineer'.
It helps candidates to know where they’d be getting into and also serves as a starting point to very interesting conversations with them.
It helps that I work for an open source company so our code is public anyway.
show me a random file that exists in every codebase but isn't sensitive, like the entrypoint
show me your jenkins / CI, how long do they take, how often do tests flap
screenshot of datadog / sentry
all that said, in the case of ML, I'm guessing even the dependency graph is giving away some hard-earned information like 'this implementation of this algorithm works best for our domain'
These are wonderful suggestions!
* Legacy code that was written by people who left long ago and nobody wants to touch
* Code written in "uncool" languages, frameworks, and libraries that nobody wants to touch
* Code that was written by various offshore contractors
* Non-deterministic test suites that randomly fail and that engineers learn to skip/ignore rather than address
* Long build times
* Weird, bespoke code that was written for "fun" rather than using an established library or framework
* Microservice hell - impossible to tell what the codebase actually does since the true business logic is distributed across so many different services, and only an old-timer will be able to tell you how they all connect together * Severe lack of internal documentation
Given the above, when trying to select an employer, I think it's more important to carefully evaluate the people you'll be working with:
* Are they pragmatic or idealistic?
* Are they chasing fad technologies or are they comfortable using established frameworks that get the job done?
* What do they value more highly, delivering useful software or developing byzantine processes for everything?
* What percentage of the workforce is full-time vs contractors?
* What's the average years of experience of the engineers? Are there any adults in the room?
* Do people know the vision of the product? Do they what they're building and why they're building it?
While I can empathize with the desire only to work in neat and tidy situations, people who have such requirements are often insufferable, and are in my view deserving of a significantly lower salary because they can only effectively contribute in a very narrow range of situations.
While I get why asking to view a codebase could come across as sounding like someone only wants to work on neat and tidy solutions, I don't hear it this way.
It's very normal and human to have preferences. It's OK for a prospective employee to ask questions about the working environment. There are a number of valid reasons to try and gain more in-depth signal on technical aspects of the company that don't mean someone is a snowflake.
There are a lot of ways to gauge this kind of signal without viewing a proprietary codebase, as others have mentioned in this thread. The questions posed in the comment you replied to are some great examples of how to do this - I think these get to the core of the matter more effectively than looking at code.
The relationship is that the employee works for the company, not the other way around. The company isn't obligated to employ anyone who doesn't meet their needs.
I do not see the employer-employee relationship as a one-way street and would refuse to work at a company with this kind of orientation. It has never been a problem to find organizations with a different orientation.
There exists no axiom that says an employee is obligated to work at a company. For workers at a sufficient level of skill, resources, and privileges, the working relationship at a core level is centralized on the needs for both entities; there is a mutuality in regards to getting needs met.
Of course there are organizations that basically exploit and abuse their employees; many of us have the privilege and experience to be discerning such that we can completely avoid companies like that. For lesser-paying jobs, a worker's needs are still completely valid and almost always taken into consideration by both parties.
For instance, we usually require a paycheck, and we often have well-defined, quantitative needs around this. I am not going to work somewhere that pays me $0.15 per hour, to use an extreme edge case.
Some other common employee needs:
* to work somewhere with a good work-life balance.
* challenging and non-tedious work
* to be around people who aren't sociopaths.
* to work at an organization that isn't paralyzed by micro-managing pseudoprocesses.
* to work at place that doesn't require the installation of spyware or middle-managementware on our devices.
The list goes on.
How about you? Do you not have any needs in regards to where and how you are employed?
I interviewed with the CTO at a series A, and he was enthusiastically talking about how good their CI and developer productivity was. I asked him to show me, and he happily solved an actual UI bug in front of me to show off the system. Left a very positive impression.
Hiring managers at big companies probably wouldn’t risk doing this, because they don’t know whether it’s allowed. Although maybe they would if it’s something they’re proud of and they have a bit of an anti-establishment streak.
Tldr: ask to see the code. Interview them, its a two-way street.
For me, "demeaning" does not have an emotional component in that I don't take this personally and that I don't feel much of an emotional "charge" around this... definitely nothing that is "directed" towards an organization like this.
And I made no claims about what tasks are "too lowly" for me to do, that's an orthogonal issue to the question at hand. I'll happily do simple, repetitive, potentially grueling tasks if necessary.
I'm thinking about our limited time and how this industry seems to have a unique approach to hiring. It's very challenging to apply to multiple jobs that all come with some form of code challenge and lengthy interviews, while also working full-time and taking care of a family. How do we increase the signal about where we are thinking of working?
Other folks in this thread have offered some great suggestions to this question that don't necessarily involve signing an NDA.
That code would also have to be vetted in case there's anything sensitive in it security-wise..? Also, source code in itself wouldn't tell you about the processes that are in place or not (how easy it is to deploy code, what's the review process like, etc.)
On the other hand, you should ask questions to learn as much as you can about the development practices. Getting answers to the Pragmatic Engineer Test [0] (based on the classic Joel Test [1], which is useful as well) will probably tell you a lot. Learning that code isn't tested (and that there are no plans to add that, or worse, testing is not considered valuable in general), and/or that code isn't versioned, would be obviously informative.
Finally, from personal experience, I'll add that as a freelancer, you typically get more leeway re: asking to see code. Specifically, if a client comes to you to help them with a project, it's much easier to ask to see the existing code to understand what the current state of it is, and to give an accurate assessment of how much work will be required.
[0] https://blog.pragmaticengineer.com/pragmatic-engineer-test/
[1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Granted, there is the problem of academic cheating in CS so for people coming right out of college into the job market, so it's likely an acceptable filter for screening out people who haven't ever really written their own code from scratch, but otherwise. for people with proven track records in the industry?
Maybe the thinking is: "We've got this mess of a codebase, it's poorly documented, if it ever got out how bad it is we'd be very embarrassed, and we want compliant team players who won't shake up the boat or demand we overhaul the whole thing, as we care a lot more about revenue than code quality, and this thing does work, sort of, most of the time, and we sure don't want anyone writing memos about massive security holes to upper management... now, will you jump through these degrading hoops like a good little poodle or not?"
There are some terrible software patterns that someone might not want to work with, but such things can be found in every team of every company. My experience is that good engineers will gradually come to own whatever legacy they have inherited and either clean those up or rewrite them until they are satisfied. So for the purpose of not wanting to work with tech debt, asking to see the codebase seems futile.
But a codebase is also a reflection of culture, and it's reasonable to want to understand what culture you will be getting into. For example, if every other code comment contains a juvenile joke and that's the sort of thing that will offend you, that might not be a place you want to work. Cleaning up code is much easier than cleaning up culture.
>I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -- Linus Torvalds
So really, why ask for just the code? Why not ask for a copy of their database as well? That's even more important. It has all the relations and structure, the customer data, the data points they use to judge success, etc.
I think you can imagine plenty of reasons why they'd say no to that. And the reasons regarding proprietary code, while not as strong, are not all that different.
Of course, it would be nice if they had something to show. A lot of companies do some work on open source modules that they use, so they should at least be able to show that.
But that's not necessarily indicative of their entire legacy codebase, nevermind their data structures. And many companies have some nice new code that they're working on, but still have to support lots of old legacy code as well. So you really need to be able to deal with that anyway.