Ask HN: How to advocate for prospective employers to show us their codebases?
63 comments
While this makes sense to some degree, it sounds like an easy way to filter candidates based on how difficult it may be to work with them in the future. It really depends on how this is approached. Someone that drops an ultimatum during the interview process would be a hard pass for me. Now, if it were phrased as a request, maybe. It also depends on how they handle no. Either way, not hiring the candidate if there is disagreement on this sounds like a win for both sides. They likely are seeking a different work culture than the company has.
This just goes to show the power asymmetry. It is almost like an euphemism: easy to work with = obedient worker.
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 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.
to add to what I said - puzzle-solving in an interview process is usually mandatory when it exists, in other words, an ultimatum (usually not framed as such, the implication is implicit).
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.
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.
thanks for your comment.
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.
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.
NDAs tend to be pretty invasive (they can sue at your expense whenever, you're presumed guilty if any of your IP looks like theirs no matter how novel it actually is, ...). Those clauses might not be used often, but if not then why include them in the contract?
With such a high potential cost, you'd want to buy something important. I don't think code quality matters that much. It's probably crap, it's probably fixable, and you'll probably get accolades for tracking down thorny issues and for sweeping changes that make it better. If you accidentally hit upon a company not using version control and not willing to change then in such rare cases you can grab another job in a couple weeks.
Unless some extraordinary scenario applies where you need each prospective job to have as high of a chance of success as possible (H1B quasi-slavery and whatnot), I don't think I'd bother even asking about code health.
With such a high potential cost, you'd want to buy something important. I don't think code quality matters that much. It's probably crap, it's probably fixable, and you'll probably get accolades for tracking down thorny issues and for sweeping changes that make it better. If you accidentally hit upon a company not using version control and not willing to change then in such rare cases you can grab another job in a couple weeks.
Unless some extraordinary scenario applies where you need each prospective job to have as high of a chance of success as possible (H1B quasi-slavery and whatnot), I don't think I'd bother even asking about code health.
Second up this post as it is basically what I started writing.
Want to add that one is signing NDA with a company - fun part is you never know who buys that company later so it might be nice people now and in a year some shady law firm takes over or some owner goes under and thinks up shady ways to earn something.
Want to add that one is signing NDA with a company - fun part is you never know who buys that company later so it might be nice people now and in a year some shady law firm takes over or some owner goes under and thinks up shady ways to earn something.
I understand what you are saying, but a request/demand like that would be a hard pass for me as a manager. I’ve worked at companies that require a high level of security clearance and we wouldn’t be able to show you anything before you are cleared. No NDA will fix that. What I’ve done before is to show cases or examples of fake code/work tasks that looks like production examples but are very different. This is for the candidate to get a feel of what they will work with.
I totally understand regarding the security clearance.
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.
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.
I have a hard time imagining that if their code base is awful, they'll present you with awful fake code that accurately represents that.
Thanks for the clarification. Ultimately I think a developer (and other employees) should be able to work with any task and (in this case) the status of the code shouldn’t determine if you want the job or not.
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.
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.
Just because you "should be able to" doesn't mean you'll want to. If the job is going to be unpleasant because the code base is steaming dumpster pile of garbage, that would be nice to know. Maybe you'll appreciate that kind of challenge, maybe not.
These are good points... I certainly value these factors as well.
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.
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.
I can understand motivation to read some code samples from prospective employers, but not for the examples that the OP mentioned.
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.
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.
>Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious. -- Fred Brooks.
>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.
>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.
I already have multi-year NDAs long enough to still cover me after I've switched jobs twice. The last thing I need in my life is to be under 2 previous employer NDAs, a 3rd NDA for current employer and rack up a 2..4..10 more NDAs while interviewing. Rinse&repeat when I look for a job again in 3-8 years.
You can do this at smaller companies if you’re a strong candidate. Startups understand that they need to offer something that Google/Meta/whoever can’t, and they often will be very flexible during the interview/courtship process.
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.
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.
do you necessarily need to see whole codebase? or like ancillary tools: run this linter for me, show me your API footprint across the dependencies you use, give me a sense of your cloud stack. test coverage. total lines or at least ratios between programming languages.
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'
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'
no - I wouldn't need to see whole codebase.
These are wonderful suggestions!
These are wonderful suggestions!
I think you might be in the minority on the NDA thing. I don't want to get sued by some dumb dog walking service because I copied their website color scheme and signed an NDA with them.
I agree, signing NDAs left and right for random companies isn’t something I’d do, that’s too risky. If the interview falls through, I would prefer to disappear from the company’s databases (GDPR is great for this).
I do wonder if the real purpose of the 'ridiculous and demeaning puzzles' is more psychological assessment than skill testing in many or most cases.
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?"
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?"
I don't know how much you'd be able to get just from looking at a code base. Most codebases suck in some way, and it's easy to read code and judge - but what is more important is how it's dealt with. eg How good is the CI? What is the team attitude to technical debt? You won't get that from reading the code base.
How about this instead? Ask to briefly shadow some of the team as they do their normal work. You will hopefully get a much more real impression of what working there is like.
I once had an interview last several hours, and in the middle they sat me down with one of the existing workers for a 45 mins chat. The guy talked about watching movies on shift - it was an honest chat.
ps. I work for an employer where almost all our code is open source, so we would find this an easy question :-)
How about this instead? Ask to briefly shadow some of the team as they do their normal work. You will hopefully get a much more real impression of what working there is like.
I once had an interview last several hours, and in the middle they sat me down with one of the existing workers for a 45 mins chat. The guy talked about watching movies on shift - it was an honest chat.
ps. I work for an employer where almost all our code is open source, so we would find this an easy question :-)
I don't really need to see the code but there are some proxy questions.
Two of Joel questions cover example downsides (slow builds, bad tooling), post is from year 2000 - so in theory asking about source control might be silly but if company is not using GIT in 2022 I would slowly (not to make any sudden moves) try to find my way out of the interview room because there is seriously something wrong there.
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Two of Joel questions cover example downsides (slow builds, bad tooling), post is from year 2000 - so in theory asking about source control might be silly but if company is not using GIT in 2022 I would slowly (not to make any sudden moves) try to find my way out of the interview room because there is seriously something wrong there.
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
> 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.
This 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.
This 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.
The market is in favor of developers and has been for a while. Companies don't seem to adjust interviewing based on the market, just their acceptance threshold.
There are engineers that don’t actually do engineering at many companies and they accrue many years of experience. Very common in defense companies in the US.
Not limited to defense or government projects. A lot of startups are building engineering playgrounds where the goal is engineering and complexity. In there too you have a lot of engineers that accrue years of experience building unnecessary complexity (and worse, get promoted into management).
The truth is, most codebases are terrible. In any company that's been around for more than a year, you're likely to find most (or all) of the following:
* 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?
* 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?
On top of that, you’re presumably being considered for hire in order to solve business problems. It’s called “work” for a reason. A top-notch engineer is capable of embracing messy situations, analyzing them deeply, and working with others to make them incrementally better.
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 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.
Using the same logic, shouldn't a proclaimed top-notch company be able to embrace engineers w/ less than stellar skills? Who may have some "messiness" in how they work?
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.
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.
> shouldn't a proclaimed top-notch company be able to embrace engineers w/ less than stellar skills?
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.
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.
And is a worker obligated to work at a company that doesn't meet their (the worker's) 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 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?
Getting access to source code (as part of the interviewing process) will probably be very difficult as noted in many comments here. Also - what code would you be given access to? (some parts? a file? a whole repo? all of which could be cherry picked to show the company in a positive light.)
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...
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...
It's a reasonable question, but frequently it's quite a complex answer. Given you are likely just one of many applicants I think it may just accelerate most employers turning you down.
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.
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.
That this would potentially exclude someone from a hiring process is a concern, yeah. It's definitely a big ask relative to what is the norm.
I'm trying to get a sense of whether or not _any_ companies would be willing to do this.
I'm trying to get a sense of whether or not _any_ companies would be willing to do this.
As a hiring manager I show the source code of our product (some easy modules that show the general architecture) to every candidate.
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.
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.
I love this. It's very simple and fair. "Show me you can code. Yes, if you show me."
That's what we effectively sometimes. We were asked by a company to work on their codebase, add some additional features. In order to give a good effort estimation, we asked to looked at this Qt C++ codebase. I went to their office and look through carefully. The code was good and we could make a good offer.
In other cases we saw bad codebases, and asked for 10x more. Which they paid. And it really was 10x more the effort, as it turned out.
"We" is not a single employee, but a contracting company. So our leverage is better, compared to a lone wolf.
In other cases we saw bad codebases, and asked for 10x more. Which they paid. And it really was 10x more the effort, as it turned out.
"We" is not a single employee, but a contracting company. So our leverage is better, compared to a lone wolf.
As part of my phone interview at Google in 2015, I was given a piece of real code to read, with all the comments removed, and asked to figure out what it did. Was actually a fun little exercise.
Yea this is how I currently do interviewing.
Give the candidate a real piece of code, ask them what it does, ask them to improve the code, and then ask them to add a new feature to the code.
Give the candidate a real piece of code, ask them what it does, ask them to improve the code, and then ask them to add a new feature to the code.
If I had done this at a previous company, it would've been a hard pass. The stack would've been considered modern 10 years ago. And was still using many of the same tooling and versioning from that era.
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!)
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!)
[deleted]
Debugging or improving a snippet of production code is probably a fine interview challenge, at least for small software companies. Maybe a hiring manager would give a challenge like this (in place of "demeaning puzzle") if you asked at an early step of the interview process.
[deleted](1)
If there was any collective bargaining in software development then YES, it’s an easy ask.
If you’re considering a tiny startup desperate for developers then YES, it’s an easy ask.
It will not work in any other environments because of the power imbalance.
If you’re considering a tiny startup desperate for developers then YES, it’s an easy ask.
It will not work in any other environments because of the power imbalance.
> still be met with these ridiculous and demeaning puzzles
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'.
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'.
But you do realize that they also weed out effective engineers who aren’t good at pointless puzzles, and that leetcode.com and dozens of other sources exist entirely to help people beat this system, right? They don’t measure useful skills. They’re a game that some people are good at beating and others aren’t, and whether that person is an effective engineer is largely unrelated to their skill at that game.
This is exactly right. Puzzles have one solution, programming problems have a solution space. It's like judging an artist by asking them about art.
And it’s (often comically, always depressingly) necessary for this exact reason. In a recent interview my company conducted, the candidate clearly submitted code they had not written as if it were their own. One might be surprised at how well folks can talk, that cannot actually write relatively trivial code.
How did you know they didn't write it?
Just work for companies that default to open-sourcing everything. Easier said than done, but that's the best guarantee.
Funny you should ask. With my current employer, after the interview, I asked to see the code. My future manager took me upstairs to the location where the team was usually sitting. Surprised to see me, team leader was happy to oblige. I pulled up a chair, sat next to him and (while manager was standing by, watching), asked him to click through the codebase where I should be working if they hired me. I spent at least 20 minutes. When I was happy, I shook his hand and thanked him for showing me the code. I was happy with what I saw, accepted the offer and currently work there.
Tldr: ask to see the code. Interview them, its a two-way street.
Tldr: ask to see the code. Interview them, its a two-way street.
Nice! That's great to hear. Sounds like a very collaborative and supportive working environment.
allowing interview candidates to look at the code is never gonna happen. Your best bet would be to try to meet some of the current employees socially, and ask them about their tools and processes to get a sense of what the workflow is like. most people would be pretty willing to talk about that if you bought them a beer or something.
How about simply asking questions like "how long does it take to compile the codebase locally?"
Never gonna happen.
I wouldn't screen for code quality, but for attitude. Every codebase is some level of crap. The older, the larger it is, usually the crappier. This is fixable, however, if they let you. The problem usually arises when the focus isn't on maintainability, the team doesn't want to improve their workflows, or the feature pressure is just too high.
Observe your interviewers: is the interview a questions-answers style process, or are you having a conversation? Do they come over as enthusiastic or rather as close to burnout? Those are tell tale signs of how it will be to work with them.
Observe your interviewers: is the interview a questions-answers style process, or are you having a conversation? Do they come over as enthusiastic or rather as close to burnout? Those are tell tale signs of how it will be to work with them.
Just look for open source
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