Companies don't want to do job training anymore. Instead of a general background and attitude check, they need to know if the candidate has all of the individual skills that will be used on the job.
I had a kind of career crisis/breakdown, where I realised no one gave a shit about anything except my utility as a walking set of tech keywords. Accepting that it wasn't working for me was one of the best things I've done for my career.
It's that I firmly believe that there's more to software dev than just knowing a 'stack'. And even then, fair enough if they were curious about my .NET skills. But them asking about specific versions of .NET core really woke me up into how much of a commodity labourer they were trying to turn me into.
Many software engineers have accepted that they have to continually learn and will do so.
This process though, makes it impossible to know what to learn with an impossible random and unknown credential set. It's not the same as something like elevator attendants having an obsoleted skillset. It's a combination of not having time in a lifetime to even try to specialize in the random employer chosen skillset. When instead, employers should expect a good engineer to adapt quickly and employers should also commit to training staff.
At the risk of suggesting you might be dating yourself, I think this is an outdated model. It's simply no longer realistic. I personally believe that having personal expectations of what my adversaries or those outside of my control "should" do will inevitably result in sadness on my part.
Corporations will aim to do what they must to increase profits (given, by definition). Any additional assumptions from that are liable to be faulty. Perhaps you are used to the times when they needed to train staff but that's simply a symptom of the circumstances as opposed to a duty.
- going on $JOB_BOARD
- sending out CV & Cover letter
- talking to recruiter
- going to 3 interviews
- rinse and repeat
Wasn't working. I was not in demand. I had to constantly reach out to people, just to get interviews at places I didn't really want to work for. And even then they'd usually reject me.
It was a wake up call that I was on the fast track to nowhere, and something had to change.
Ended up specialising in an industry and doing contract work. I'm not super successful yet, but there's a lot more interest in me. My work days are much less frustrating and I'm earning more.
I am genuinely asking. Why is this objectionable?
Why do people find it so horrible that their labour is a commodity? To me that just tells me I should treat my labour like a merchant treats his goods. Always be checking the market to ensure you have something worth selling and while you might sign long term deals, periodically check for the best price to ensure you are getting it.
Why is it important to you that your employer view you as a person?
Because we, generally speaking, are people and not robots ;)
That being said, I agree with your point : people would have less issues if they just felt happy about whatever makes logical sense. That's just way too hard to live by for most people.
The answer to the question as written is...of course people want the entity that has outsize influence on 40 hours of their week to view them as a person instead of a mindless cog in a machine. People get treated better than cogs. Workers want their working hours to be as pleasant as possible, which is much more likely if your employer sees you as a person.
Is that really surprising to you?
Needs can include a nice workplace and you can negotiate specific details about what that means to you. I did not mean to say that it needs to be money.
You're not describing an employee, you're describing a consultant. Not everyone wants to be a consultant, particularly since most people don't get any training in it before they have responsibilities. If proper entrepreneurship was a subject at school, then maybe people would be willing to be their own business, but that's not what the system creates (or wants).
Fair, I can see why this might bother people. I don't think job security is a thing (career security perhaps), but I can get why its absence would be disturbing.
> expectation to be wading through the job hire swamp every couple of years.
The high level of turnover in this industry indicates that people at least tolerate it. The only people I know who make it 24 months in a role are chained by stock options.
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
It's not about being viewed as a person. It's about being viewed as a professional.
Good organizations hire talented and bright people with mastery of CS and SWE fundamentals. Bad organizations think "oh we use Java, better hire Java programmers". Really bad organizations think "oh we use JUnit, Spring Boot and IntelliJ, better hire people with experience in JUnit, Spring Boot and IntelliJ"
One of the strongest signals of how good an engineering organization or a tech team is how few specific technologies they list in their job ads.
I'm not even an exceptionally talented programmer: just a competent one. Of course there are real differences between languages that matter, but at the end of the day ifs are ifs, ints are ints, functions are functions, etc.
Relevant old joke: https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...
That said: there are some reasonable scenarios when you want to hire someone with prior experience; for example as a first or second hire it's probably a good idea in most cases, or if you really need someone who can hit the ground running.
Case in point: a Stripe job listing I picked at random
https://stripe.com/jobs/listing/backend-api-engineer-core-mo...
No single language is named! And this specific sentence is a really great sign (unsurprisingly)
“Languages can be learned: we care much more about your general engineering skill than knowledge of a particular language or framework.”
I think that in the specific case of Stripe, they specifically mostly use Ruby (from answers I found online). I may be wrong, but I assume that not mentioning Ruby is a way to attract Python/Go/C/etc. developers that might otherwise think that since they don’t code in Ruby, they shouldn’t apply.
Your main point (re: Java) remains of course.
"We mainly use [language X], but you don't need experience in [language X] for us to consider your application" - this is a totally normal thing I've seen in many job postings.
Stripe is sometimes more explicit about it:
https://stripe.com/jobs/listing/infrastructure-engineer-ruby...
"Our most popular language in the company today is Ruby, and we are building a new Ruby services practice in support of this."
... but that job is also an openly Ruby-centric job.
You can't just go around telling people that: you are going to make hiring harder once everyone figures it out!
When you get a referral for a 10x and you're meeting at Blue Bottle you need an ice breaker; clueless community-college tier HR asking for versions of frameworks makes for an excellent one!
It doesn't matter :-) such organizations aren't good at finding out if someone is "talented and bright people with mastery of CS and SWE" in any case
Learnability is totally ignored.
It is terrible for inexperienced developers eager to learn on the job as is common in other industries or was in ours in the past.
It's terrible you're an experienced developer that is able to pick technologies quickly, or just wants a proper work-life balance.
It is terrible for developers who are deeply familiar with the technology but expect to work with a team of professionals, rather than with "walking set of tech keywords".
Software engineering is at a schizophrenic point where it is very hard to categorize in either of traditional "blue collar" vocational job (given people seem to be employed close to very little formal schooling) or as a "white collar" professional job (given some roles need a CS degree level understanding of the fundamentals).
Some roles are more the other than the other.
I'd say listing a very specific tech stack signals the employer is looking for "blue collar" "commoditized" labour.
White collar "professional" types probably feel treating their contribution as "commoditized labour" is a category error.
The majority of useful education comes from mentorship and on-the-job experience. Sure, you can get a formal education, and sure it helps, but it doesn't make you a useful software engineer. It just gives you a foundation to build upon through mentorship and experience.
In GP's case, the arbitrariness originates from their potential employer not taking the effort to really evaluate GP's relevant skills in software engineering, but instead resorting to lazily ticking boxes on a checklist. And what's on the checklist isn't even particularly relevant.
What I imagine this does to GP's view of the world (based on what it would do to mine) is: "I believe I am competent because I've built up a set of subtle skills in software engineering over many years, and this is what I take pride in. But from an employment point of view, this is wasted time: I should instead have focused on optimizing the checklist (and I only found this out after years in the industry)."
If what you mean is that it can be rewarding (intrinsically and extrinsically) to think about skill, craftsmanship, and other ways to make your labor a great value add, sure. Most of us benefit by thinking about that.
If you're really asking about why keywordification is a problem, well... keywordification of job roles indicates a way in which companies are quite possibly struggling to actually model the roles they're hiring for and identify what makes make an individual productive within them.
This happens on at least two levels:
1) Technological. Engineering decisions are sometimes "we have a specific problem, specific tech is the solution to our problem, therefore we need expertise in specific tech." In that case, the keywords regarding that tech are meaningful. But for non-trivial use cases, engineering problems are very, very rarely just that, they're commonly the aggregation of off-the-shelf + consideration of how to mix them with what tradeoffs + in-house custom solutions embedded in an organization attempting to understand and model its domain problems and fit/reshape all those solutions to those models. This is not exactly a keyword-driven process. Keywords represent the shallow end of the pool.
2) Human. While labor clearly is something bought and sold on the market, even from a point of view of a value system which is OK thinking of humans primarily as industrial inputs, it turns out that's a significantly leaky abstraction and most of us have all kinds of "compiler flags" or other inputs of our own that make us more or less productive. Some might consider this to be too warm and fuzzy; they might find it comforting that it can be approached from as a-humane and manipulative point of view as one might approach tweaking a database to get it to perform better: https://www.youtube.com/watch?v=HkFztAgK-8U
As for whether it's OK to think of humans primarily as inputs to any process on a moral level... like Terry Pratchett's character Granny Weatherwax said “Sin, young man, is when you treat people like things. Including yourself. That’s what sin is.” What are the consequences when social institutions consideration human beings primarily as inputs to institutional purposes? Generally, individual life, liberty, and pursuit of happiness become valued less, and individual suffering is more freely disregarded. Not super desirable under my value system. YMMV.
How did you pivot after this?
It's a contrived example of course (particularly if the end goal was just to check the "knows feature X from C# 8" box!) and I wasn't at those interviews so I've no way to know what their intent was. I'm occasionally on the other side of the interviewing table though so I'm just trying to reason through why this might come up. FWIW I hate the "what isn't in a linux inode" type questions, or situations designed to fuck with the interviewees.
"No, I'm not familiar with this, but I have done [market themselves, mention relevant experience, ask relevant questions] and I'm confident I can get the job done"
First probe is if the candidate doesn't have slightest clue what version they were using, that's a big red flag. This is more common than you would believe.
Second probe, candidate knows, but they only used a 25 year old version (also more common than you would believe when it comes to c++), this can be a warning flag that they are not interested in learning new things. But doesn't have to be if it was company policy, which is also interesting if they were in position to change this.
Third probe, ask follow up questions on differences since version N-1, this shows if candidate is staying up to date with latest trends or not.
Probationary periods could work but it's a coordination problem. Such periods are the norm in Europe (coz it's very hard to fire someone) but for an at-will place like the US, given that the industry doesn't really do probationary periods in general, any employer who starts doing it would be at a disadvantage.
In the sense of offering signing bonuses for term lengths that get repo’d if the contract length is broken.
While I agree interviewing has gotten ridiculous with all the leetcoding and ten rounds of interviews and FAANG cargo-culting and whatnot, one small advantage - assuming I'm not desperate for a paycheck - is that it gives me, as a prospective employee, time to consider and withdraw my application if I see too many red flags or I just prefer the devil I know.
A short interview process with a probation period on the other hand is a big roll of the dice. Maybe I'm not able to ramp up on time, or make a silly mistake due to unfamiliarity with the codebase or underlying business logic. Maybe I don't get on with the team or manager. Maybe I'm going to be dumped into a doomed death march project on day 1. I could find myself unemployed a month later with an embarrassing gap in the resume. Perhaps on the other hand a better interview process (not longer, just have properly trained people and constantly improve the process with feedback) would save us all that pain.
All the while, productivity suffers as the remaining team falls further behind due to short-staffing and being pulled away from their real jobs to interview.
> In general, people leave their jobs because they don’t like their boss, don’t see opportunities for promotion or growth, or are offered a better gig (and often higher pay); these reasons have held steady for years.
And if it is about money, then this is called paying competitively.
But lastly, recognize that if everyone is training employees you're still not really losing out unless you're only hiring entry level employees. Sure, you might be training someone that leaves, but so does your competitor. But if you're only hiring junior engineers then you're probably doing something wrong that's much bigger.
Out of curiosity, what sort of "non-monetary" benefits were you thinking about? There's usually not a reliable way to turn (small amounts of) money into the sorts of things that really build loyalty.
If an employer does do training, it means they'll probably continue to do more training over time, which helps the employee become more valuable.
If the employer doesn't do training, yes they may be able to allocate the training budget to salary, but they are not going to spend anything training you or letting you work on projects to increase your skills while you're there, unless they absolutely must.
I think people also have some human perception of how they're being treated, and prefer to work for people that invest in them.
Sometimes they leave. By that time they've used what they've learned and passed some of it on to the next person.
I don't know what it is but I feel like people have forgotten just like basic truths about how humans work. Maybe it's because managerialism has infected everything.
Even still, it’s obvious that comp alone isn’t enough to retain employees. Even FAANG companies, which pay extremely well, have pretty low retention numbers. Facebook does best here, at an average job length of only 2.02 years. If comp was enough, people would stay there longer. This implies that people are changing jobs for reasons aside from “this other company will pay more”.
Even if some of them genuinely get promoted before they’re ready and wash out, you’re not really that much worse off than if you’d lost them before. Besides, there’s always the risk that your new hire is unprepared too, which is a much harder thing to quantify.
Losing people who are experts within the domain of the software they're maintaining because you refuse to invest in them is going to cost you thousands of dollars... the only question is whether that's tens or hundreds times that amount... and in some cases it can cause you to lose your entire business.
Basically there’s two types of efficiency, investment efficiency and allocative efficiency. (There may also be other types I don’t know about.)
Investment efficiency means people are incentivized to make positive-expected-value investments. Think about how people are incentivized to invest in their house, e.g. preventative maintenance, because if the expected value is positive then they will recoup that value when they sell the house. If you’re renting you don’t have this with respect to where you live - water damage or no, not really the renter’s problem. Investment efficiency is maximized by private property, where you know that no one will take your property without your consent.
Allocative efficiency means things go to whoever is willing/able to pay the most for them. Renting does have this property - if both of us want to rent a house, and I’m willing to pay more, in most cases I’ll end up getting the house. This is why gentrification can cause displacement - when wealthier people come into a city and are able to outbid the current renters, they win and the current renters lose. Allocative efficiency is maximized by auctions and things like them, where the good goes to whoever is willing to pay the most.
Bringing it back to your comment, job training isn’t worth it because our careers as programmers are dominated by allocative efficiency, not investment efficiency. If you can train a programmer create $50,000/year more value in general (i.e. it’s not training that would only be useful to your company), they can now get paid about that much more from any of your competitors, and you will have to pay them about that much more to stop them from leaving. So you gain nothing from giving them general-skills training.
Another way of solving this problem is with sectoral bargaining. If you have a sector-wide union, they can make all companies start training simultaneously, or assume some of the costs themselves. It’s a win-win for the industry and for the programmers, but it doesn’t happen nearly as much as it could because of that coordination problem.
The union is ensuring that no company can ruin it for everyone.
But it makes Reginald the investor angry that his ROI isn't exactly 20% each quarter, so they jettison apprenticeships and start cooking the books to make that possible.
At least a few years ago, Google made it a point that the interview process was generic, not specific to any position or team. More like an undergraduate admissions process.
https://clairehu.com/2014/02/18/a-little-bit-of-slope-makes-...