Hacker News new | ask | show | jobs
by hnuser847 1469 days ago
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?

1 comments

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.

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.

> 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.

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?