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.
This a hundred times over. I still remember in 2020 multiple places asking me "I see you've used .NET core, what *version* have you used?".
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.
> where I realised no one gave a shit about anything except my utility as a walking set of tech keywords.
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 selecting candidates based on tech stack is almost universally the sign of incompetent tech management. Anybody who understands software, knows that intelligence and master of fundamentals trumps tech stack experience without exception. Linus Torvalds would unquestionably become a better Ruby on Rails developer within four weeks than 90% of people with 10 YoE in it.
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've been hired as both a Ruby on Rails and Go developer without prior experience, and managed just fine in both case. Of course there's a bit of ramp-up time, but it's not that bad.
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.
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.
On the other hand, it would be nice to know the core languages in play. I have no interest in working in Java anymore, I avoid job listings for companies that would expect me to write Java. I don't want to have to go through recruiter screens etc before I can ask someone who will know what language I would be spending the next year of my life working with
Our solution to this is that we are clear that we're looking for Haskell programmers (as in that is what they should expect to do) but we have very modest requirements in terms of prior knowledge. I made sure to relay to HR that almost nothing is required in terms of prior knowledge (language-wise) and that we should expect to teach Haskell to people instead.
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.
Not to pick on Stripe, but why not say this explicitly?
"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.
> 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"
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!
This makes a lot of sense. If a person has good fundamentals and understanding of engineering and CS, then they should be able to master any tech stack. I think in software development, we are in a weird position. In other engineering fields, it is expected to have a base line knowledge and the ability to learn into new processes. Most software companies seem to not want hire engineers who can do that.
The answer to a charitable interpretation of your question: most tech workers don't mind exchanging their labor for money, of course.
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.
Not a mindless cog, but more as a merchant or even a labour supplying Lambda function. Just simply acknowledge that my employer and I are trading, the arrangement may end at any point for business reasons, and likely will end in a few years as our needs diverge.
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.
A screwed hiring system is something most companies appear to be able to afford, given how many have one. When that same experience is flipped around to the employee, they can't afford it and it's a disaster. Few employees want zero job security and an expectation to be wading through the job hire swamp every couple of years.
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.
But not all of us want to trade at that level of granularity. 'Do you have any mechanical engineering jobs' not 'Do you have any ceramic ball bearing housing design jobs'.
Because a Company expecting a "walking set of tech keywords" is a terrible deal for everyone but charlatans.
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".
I guess this is how I think of it. I enjoy the fruits of modern society, the airplanes and fast food and nice phones. But to make that happen, you need specialization, you need people know get really good at flying planes then just do that, and people who get good at making fast food and iphones and everything else. And inside that, you need people who specialize at every part of the supply chain, and what you end up with is people who have spent basically their whole lives fixing bugs in webservers used to sell analytics software to businesses etc. etc. and it becomes so abstract and you’re so disconnected from the feeling that you’re actually helping anyone or worth anything to society that it doesn’t really matter that intellectually you know the whole system would collapse if you don’t have people doing jobs like yours. And you should have friends outside of work, but many of us don’t really, at least not to the extent that way like, and even then work is literally most of your waking day most days of the week, and the knowledge that not even your coworkers or superiors or anyone else really cares about you in this grand societal project called modern civilization that you’re basically dedicating your life to maintaining, I can see how that would get to someone.
Dear god, that was beautiful but also depressing to read. I think this is it, exactly. I also think that it explains a large part of why so much software is bad. Specialization is a powerful thing, but without a unifying concept of the end goal, it's easy to become trapped by local maxima.
In short, employers have some degree of power over you, and if you perceive people who wield power over you as wielding that power arbitrarily, that is nearly universally experienced as frustrating.
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)."
Great response. This is why I ended up not becoming a teacher, despite everyone and their brother telling me that that's my calling (I still hear this at work constantly from people I train). I could have absolutely dedicated my life to something with low pay. What I would not do is accept an environment where I was not treated as a professional. As far as I can tell, the modern American education system treats its educators like crap and hamstrings them every step of the way. No thanks.
Because people have brains, can learn new things and technologists don't need experience with particular technology to be successful using or working on it.
"I am genuinely asking. Why is this objectionable?"
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.
More than anything else software engineering most closely resembles a trade.
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.
IMO, because the different .NET Core versions the commenter talks about aren’t that different and one can easily learn another version if they are already well-versed in one if them.
Also I am wondering: if management eventually decides (advised by external consultants of course) to switch to a newer version, then what do they plan to do? Hiring a new team?
Because the buzzwords are never even coherent. "Puppet or Ansible" - well no, those are not even slightly the same thing, which one are you using? GCP or AWS or Azure - same thing. Which one are you using, not what are you imagining?
This would all be fine, but no one writes ads saying what they actually need or what they're trying to do.
Minimum four slice toaster with proven experience to deliver results and work autonomously in a fast-paced family kitchen. Ability to cook eggs a plus. Must comply with government product safety laws.
> 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.
> Why is this objectionable? [to reduce an employee to "utility as a walking set of tech keywords"]
> Why is it important to you that your employer view you as a person?
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.
It’s not about humanism but mutual investment. I am investing my (very limited) time into your company to make you profit, you can invest in training me or helping me get up to speed on your specific needs.
But that is just trade and you can negotiate for those things. The employer benefits from getting you up to speed in the same way that someone might offer to send a truck to a store to get something delivered faster.
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.
Looks like I am on a similar path to you but you are a couple of steps ahead of me. Is there a place I can contact you with a few questions. I'd really appreciate it.
Is it possible the interviewer was asking this question because they wanted to get a sense of if you were aware of which version was being used? And as follow on, were you part of the decision to update or not update, and your thoughts on the trade offs in that kind of scenario? Just a possibility. Certainly if the recruiter is asking you that, that’s a bad sign (although recruiters are often very detached from the thinking of the teams they’re hiring for).
Yeah it could be a lazy way for an interviewer to check a requirements box that says ".NET Core 3.1 experience". But there is a chance that this is a way to determine whether any upcoming questions are relevant - like if you haven't used .NET Core 3.x, it's probably pointless to ask a question relating to some feature introduced in C# 8.0.
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.
Asking what version of a tool was used, actually reveals a lot about the candidate. It's not about knowing if you know the exact same version as the company.
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.
The fact that they ask this question does show some bias but it may not be as much as you think. I can interview a person and be interested in finding out how much he/she fits like a glove for the tech stack and still put more focus on other qualities. Moreover, I expect a capable dev to not be too judgmental/unconfident and just answer something along the lines:
"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"
I think this is a problem for the greater .NET community in general. I've participated in dozens of interviews where the "technical" interview is them asking obscure .NET or C# related questions like your some kind of technical glossary. What's worse is these questions are likely related to the one or two instances it's ever used in their entire codebase(s).
It's not that I wanted them to love me for who I am as a human or anything.
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.
I think the bigger issue here is that this process has made it too random and dilutive of the candidate pool.
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.
> 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.
People change jobs at the drop of a hat for reasons that are well within companies' control. It's not like people want all that stress and hassle, they do it because they're incentivized to do so.
Sometimes. Other times they are just sampling what's out there to see what suits them the best, or playing the comp boost game until even their best face forward isn't able to garner a higher offer.
The former happens, I’m not convinced that it’s a common occurrence. Changing jobs is genuinely stressful, I don’t think people do it lightly. The latter is usually something the company could fix, but won’t.
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”.
It’s not just about absolute comp. If google will pay you more, then maybe you leave facebook. That’s not because google pays more than facebook, just that it’s easier to get a “promotion” by taking a hire role elsewhere than it is to get an actual promotion. It doesn’t mean you don’t pay market wages, but it does mean you don’t pay that person their market wage.
That’s exactly something companies have under their control. If people are leaving because it is seen as the sure route to a promotion, then perhaps providing clear advancement opportunities internal would reduce this phenomenon and help keep your high performing talent.
The present employer and prospective employer have a different perspective on the individual. It's entirely possible, and indeed somewhat common, that individuals are hired to levels to new employers beyond what they would be able to justify promotion at their existing employer. The only way to eliminate this is prolonged and comprehensive interview process, which is what TFA is railing against.
I disagree that this is the only way to eliminate this problem. Companies could loosen promotion criteria to be more in line with what external candidates bring. Ultimately the cost of lost knowledge and backfilling is quite high, and could easily justify faster promotion cycles on a monetary basis alone.
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.
Incredible that you're the first person I've seen mention a second-order effect in this conversation.
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.
That works if this is a "one time game" (game theory) as opposed to a repeated game.
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.
Not necessarily. It's not easy to find a boss who you genuinely trust to consider your best interests, for example.
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.
So the answer is to not spend the money at all? How much are you costing your company by putting candidates through 8 hours of interviews only to reject them. Rinse. Repeat.
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.
Professions mandate training minimums per year in order to maintain credentialled status. They're low, sure, but they at least create a need for ongoing professional education.
I literally said it isn't all about money. Most people leave because managers[0]
> 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.
That works when you're employing a bunch of Wordpress monkeys who do nothing all day but mess with CSS and install plugins. Not so much when you've got a mature SAAS product, parts of the system are tricky to work with, and stakeholders are breathing down your neck to implement new features so you don't have time to cross-train your teams.
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.
Yep. Apprenticeships solved this problem in the past (and of course created many others). Actually it’s almost a fun little exercise in economics.
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.
>Yep. Apprenticeships solved this problem in the past (and of course created many others). Actually it’s almost a fun little exercise in economics.
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.
So, in this hypothetical, the sector-wide union is preventing individuals who learn to create an additional $50K/yr in value from realizing the increase in pay which would otherwise accrue to them?
In return for wasting training on employees that will leave for other companies, the company is getting its employees trained for free by other companies in the same way. In aggregate everyone wins because employees now get training.
The union is ensuring that no company can ruin it for everyone.
Yeah, or at least they aren’t able to capture the entire $50k/year in value. It kind of sounds bad but it’s a trade and there has to be something in it for both sides for it to happen.
You say that and I’ve seen several companies in practice echo what you’re saying. However, I fail to understand why they don’t simply make better use of contracts and probationary periods to solve that specific problem.
The problem of a probationary period is that it pushes all the risk to the employee.
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.
In a world where short, high-risk interviews dominated, you could just go roll the dice again. It would be a negative signal (why is @foo interviewing after only 60 days?), but nowhere near as bad as “why is @foo still interviewing after 6 months in this job market?!”.
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 reality nobody knows what skills will be needed for the position. Quite often not even the people who do the job. You can let them write down what skills are needed for the job, hire somebody who checks all boxes, and it could still be a catastrophic failure.
If that's true, then the interview process would focus more on skills. From what I hear, faang companies are all about the leetcode on the Whiteboard oh, and they don't seem to ask specific questions about domain knowledge. In fact, you often don't know which department or project you're going to be put on when you get hired by one of those companies. And apparently the interviewers don't know either.
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.
