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.
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?
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
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.
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".
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)."
It's not about being viewed as a person. It's about being viewed as a professional.
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.
Learnability is totally ignored.
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
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.
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.
- 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.
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.
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.
"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"
How did you pivot after this?
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.
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.
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.
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.
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.
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.
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.
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.
The union is ensuring that no company can ruin it for everyone.
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.
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.
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-...
I finished the 7th on-site interview. After I left NYC and flew back home, they wanted a 8th ( phone screen ) interview because one the interviewers lost the results.
On the one hand, this space’s modus operandi is more data is always better.
On the other hand, they have to trade and make decisions in a fast paced environment with imperfect information.
yeah, no. You dodged a bullet with that one.
It's a huge risk on the other side as well. Not to mention that management usually gets to control the narrative and not the employees.
This is going to become more and more common though. In fund management, there has been a huge move towards "professionalisation"...which, ofc, means doing lots of pointless exams that select for the wrong thing. MBAs are the same. It is very hard to solve because the system selects for people who will play into this self-image (in my experience, this isn't solvable...you can either handle the risk of being wrong or you can't).
This also overlaps with a lot of the issues that a lot of companies are having with hiring. A company which frames hiring as a risk rather than opportunity and has these very long, negative process of hiring (be real, the point is to uncover "weakness", not learn more about someone) is going to fail to hire people of different backgrounds. The amazing thing about the "candidate shortage" is that it isn't more severe. Companies are so bad at hiring, it is surprising they end up making any decisions at all.
I read your comment and I was thinking in my head...wow, five seems like a lot, and then I realised that even these places I liked went pretty hard...I think they call this conditioning.
I didn't get either job btw, the work was trivial but I get terrible interview nerves so tanked both of them...in both cases, I also had a 6-hour take home...the results of which were largely ignored. Neither company is ever fully staffed...ofc.
If I talk to HR on Monday, take a phone screen with an engineer on Wednesday, and come on-site (or Zoom now) with 4 engineers next Monday, that’s 2 rounds and 5 interviews (or 3 and 6 if you count HR)
My experience has been that if you clear the engineering phone screen the company asks you to go through all the rest of the (4-6) interviews, even if your performance in one or more of them has been sub-par. And at least here in India the post-screen interviews are spread out over several days to 2-3 weeks - there is no "onsite" as such, even over Zoom.
The best teams embrace and level up their low performers and make the whole team better.
The delta can’t be too big.
The problem is management are often too busy or overwhelmed with other stuff to observe and provide feedback until someone's passed the probation period then releasing them becomes a bureaucratic nightmare - and when the new hire's not getting feedback, you can be sure not a lot of the rest of the team are.
I've never understood this given that the hiring is so often at will.
Honestly, I don't have a good solution to the problem.
There's a quality-distribution of both books and films.
There are only so many good books. And a percentage of films end up poorly made.
Sufficiently low-quality books tend not to get made into films. The ones that succeed are notable --- there's nothing but upside.
A good book can be made into either a good or a bad film. If it's a good film, then yay, but if it's a bad film, people are aware of it (through the book's quality and popularity). This is a perception illusion called Berkson's Paradox. It's an illusion because what awareness fails to account for are all the bad films made from bad books.
Hannah Fry of Numberphile does a much better job than I of explaining this: https://youtube.com/watch?v=FUD8h9JpEVQ
In the interviewing / performance case, you have good vs. bad interviewees, and good vs. bad performers.
Someonehone who interviews poorly but performs well is a positive exception. Someon who interviews well and performs well meets expectations. It's the good interviewer/bad performer who stands out. But it's the poor-interviewer/poor-performer who is missed by this assessment.
In the past I would never have been interested in a contract-to-hire. These days though if the company and role is right, and this an option to short-cut a ridiculous interview process, I might spring for it.
When I was an actuary we used to do “intern to hire” for unemployed recent grads, but I can’t imagine leaving a full time position for a contract-to-hire position. I think for me personally the opportunity would have to be really interesting and the comp upon converting to FTE would need to be at least double my previous comp (meaning the contracted rate would probably be something like 4x my implied hourly).
I've see that work before, but it was some time ago. The company also had a very large test department with separate management and kept to a strongly enforced waterfall-esque design routine.
Of course, it used to be a lot harder to ship out version 1.01 of the software.
I just assume it was a different world as this was in the days of US manufacturing, very limited set of software tools, high importance placed on domain knowledge as opposed to toolset, longer average stays at employer, lower wages for programmers. Probably not applicable to modern times.
The company doesn’t have to prove that the employee was failing. It’s perfectly legal for a company to fire an employee because they the employee likes the wrong football team.
The employee or people pursuing legal action on behalf of multiple employees has to prove that the company fires the employee(s) because they were a member of a protected class.
Assuming there are no incriminating emails stating that that was the reason, the only realistic way to do that is to show a pattern.
If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
They do if the employee sues claiming age discrimination, for example. At least, they have to defend the accusation to show it’s not discrimination. When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
> If an employee decides to sue, whether you had them on a documented performance improvement plan for 6 months or 6 days isn’t going to be the deciding factor.
It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
They don't have to show anything. The employee has to prove that it's age discrimination.
>When someone has been at the company for 25 years like in the parent’s example, and they get fired abruptly without notice for liking the wrong football team, it’s likely the stated reason is untrue and inviting a challenge.
Without a pattern of discrimination this isn't a problem. If there is pattern of discrimination then it is. However, if that's the case it doesn't matter how much documentation they have.
>It certainly helps show that the company isn’t discriminating arbitrarily, and gave the employee notice and a chance to improve the situation.
You can't discriminate arbitrarily. Discrimination in this context means firing someone because they are part of a protected class.
>gave the employee notice and a chance to improve the situation.
Whether you gave someone the chance to correct the situation or not isn't relevant.
>BTW actual legal action isn’t necessary for firing to be getting harder. The fear of legal action is all you need, and that is in fact going up.
The number of charges filed with the EEOC has gone down over the last 20 years https://www.eeoc.gov/statistics/charge-statistics-charges-fi...
https://www.natlawreview.com/article/eeoc-roundup-part-i-10-...
"At the same time, FY2020 saw the lowest number of charges received from workers in more than two decades. The agency received 67,448 charges—continuing the steady downward trend since 2017 in the numbers of discrimination charges filed with the EEOC."
Yes that’s a compelling data point for decreasing legal actions (and it’s interesting, thanks for including it), but not all actions and not all fears end up in front of the EEOC, right? This data point alone is likely due to decreasing union membership over the last 20 years, but is also explained by the increasing prevalence of mandatory arbitration clauses. What it doesn’t explain is why HR departments nationwide are increasing efforts to educate employees about anti-harassment policies. If they are legally in the clear, why is that happening? Twenty or thirty years ago it was hardly a thing, today it’s the norm.
> They don’t have to show anything. The employee has to prove that it’s age discrimination.
You are right about the legal burden of proof in court, absolutely. Court isn’t the only possible outcome of a discrimination claim, though, and the one specific example you gave is a defense against a discrimination claim that would not hold up in court (firing a long-time employee for claiming to not like the right football team).
I agree with everything you’re saying about what is required in court, and what are the legal rights for all employers in the US, not just tech companies. That’s just not exactly what I was talking about.
Instead I think companies, especially large companies where small numbers of employees aren’t a massive proportion of spending, should try to see the potential for upside more. Especially in a world where everyone does a similar interviewing process, a candidate who performs poorly at those interviews could be cheap and an excellent hire who is undervalued by the market because of their poor interviewing skills.
In the real world, you cannot remove risk. You can manage it, but you cannot remove it. Asking candidates to go through 6 interviews before making a decision and not telling them when a decision will be made signals a risk adverse culture that cannot make decisions.