But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted. One might argue that if everyone put more fish in the pond, then we'd all be better off (true), but we have a standard collective action problem where the free riders benefit at the expense of the fish growers.
I see two (partial) ways out of this trap.
1. Pay more than everyone around you. (Obviously, not generally viable.)
2. Make the culture of your company so awesome that people will want to stay, even if you can't pay the most. Make mentoring/growth a central strategy at every level so people will see a path to grow.
I'd be curious to hear other possibilities.
Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.
So these companies put all this effort into raising a better developer, and then refuse to pay them what they're now worth and basically force them to go elsewhere.
It's not "what if they go elsewhere" under that situation, it's "when".
I'd argue that you don't even have to "pay more than everyone around you". Simply coming close to parity is enough to stop most people from going through the pain of a job search. But these companies don't even get that close.
The last time I switched jobs, I got a 40% pay increase. That's ridiculous. I even told the company I was underpaid and they asked if I could wait a year for a raise. I didn't even answer the question. I just walked away and started looking for a job.
They weren't surprised when I found one and quit.
And a couple weeks before I left, they put in a job ad for 7 developers, offering what I was making at my new job for each of them. I've been at this new job as a senior developer for 8 years now.
Could I make more? Almost certainly. But they gave me decent raises and have a good culture (almost zero overtime in 8 years) and benefits, and I don't feel like leaving.
And I was NOT poorly compensated before. I was already in the 99th percentile for individual income.
The harder I push on comp the more I get each time.
I am not going to lie and say that it didn't take years to build to this point in terms of skill, work record, professional network, and interview ability. It took three FAANG companies bidding against each other.
Meanwhile I get offered nothing in terms of growth from every employer I have ever worked for ever. Literally never happened my entire career. Just this time after I already had an undisclosed offer in hand I got a promotion with no meaningful compensation increase. It was the first promotion of my 15 year career!
Sure they were willing to match, but who wants to try and soak blood from a stone.
I've never tried it myself, but it's supposed to be common knowledge that perhaps more than half the time a company is forced into granting you a raise to match an offer you have in hand, they're only doing it long enough to arrange replacing you. There are certainly many reported exceptions to this, but why take a chance with a company that's already shown they don't respect you?
I believe no one in my management chain could have done significantly better. They had their budget and even if they had moved things around in my favor it would have just been a different level of inadequate.
Structurally the entire industry is biased towards preventing you from achieving what I call equilibrium. Equilibrium is where you can't leave your current job for a >10% raise.
I believe it's just a cost saving measure (assuming the ability to pay exists which it may not) and the industry has decided that the average wage suppression is more valuable then the cost of the turn over it creates. I'm not going to pass judgement on whether they are right or wrong.
Ability to pay is a big factor. Most of my prior employers could only offer a fraction of what I currently make.
If employers can't afford market salaries, they should think very hard about the issue and see if they can't address it in other way, or accept that they're going to deserve and get no loyalty from most of their employees.
To each and his own, but bay area engineers pissing about making ONLY 300K has always come off as being a bunch of spoilt brats - especially considering the vast majority just gem/npm/pip install this and that and glue all the code together. Of course the market deserves to pay accordingly but I think it's just a big bubble that's going to crash soon - since there is a huge mismatch between demand and supply of CRUD glue programmers (which most programmers are).
My guess is that once Lambda School, Make School, ISAs all become mainstream and the pool of CRUD glue programmers matches the demand all salaries will come crashing down. I think overall it's a good thing for society in general (and especially the tech towns).
ps: Pardon my tone. I work in the space industry. Maybe I have an axe to grind ;)
I think discussing compensation frankly and openly is very important. People have no idea what is possible. Two people on the same team at the same company can have wildly different compensation. My goal with this alt is to get people to take the biggest slice of the pie they can for themselves and avoid wasting their precious time doing lousy work for lousy money.
I have wasted a lot of time and life opportunities working for less then what I am capable of getting. I wish my future self had been around to tell me to push harder and be more mindful and efficient with my time.
I don't think CRUD glue programmers are at the top of the market right now. You could flood the market with them and it might not move compensation for people in my space. Even so, that is just another argument for pushing hard right now. Strike while the iron is hot. No one knows how long this will last.
Might cost me money, but I don’t feel bad about that, since I still get my moneys worth.
I think your entire attitude is wrong. Not in the sense of "you're being mean"; rather, in the sense of your orientation toward engineer pay. Any money that doesn't go to salary will generally go to the owners of the business. If engineers can get more, why shouldn't they? Imagine someone saying professional sports stars make too much money and should be perfectly happy to make $1 million per year. What you're actually arguing for is that even-richer people (the team owners) should make EVEN MORE money than they already do.
Seriously? Why the hate?
300k is Tier 1 (FAANG) and 2 companies. They don't just do CRUD. Those that do CRUD probably work on the SETI/Infra/Tooling division for the BigCos and even some of these "Tool-Devs" created amazing OSS tools. Do you suggest they should be treated as 2nd class citizens and get paid half of the "product" people and creating an old-time rift?
I've seen a few Bootcampers that get a job in Tier 1 and 2 companies but they have "solid" background/previous experience (hardcore Math, Stats, Data Scientist switching to SWE, greybeard embedded software engineers), just not up to date skill set.
This whole "salaries" will crash down demise has been around forever and it hasn't happened yet just like any other "demise" prediction.
I'd suggest people not to hate the situation: our sector/field is getting paid serious money, why the envy/jealousy/negativity?
Do you like the situation where hi-tech industry as a cutthroat, no-union, rampant ageism, low-paying wage?
Think of the bigger picture here...
- agreed, lots of people can some problems the naive way but you need to be at a deeper level of understanding and experience to know what will and wont work before you build it
I know what CRUD is but what exactly are they doing?
Building web-app to map network/machines?
I'm not speaking toward your argument of a bubble bursting, but engineering isn't going anywhere. And where else would an entry level engineer start than at the bottom, npm installing the package that solves their problem? It's using these concepts every day that builds good engineers who think of tomorrow's solutions, and can architect it both technically and socially. That is the line between software development and computer science.
Engineers paid under 120k that whine aren't doing anything beyond their immediate usefulness, i.e. 'just doing their jobs.' The engineers that get paid 300k are usually the ones running the show, and writing significantly less / no code.
Engineers getting paid $300K could easily be the stereotypical r/cscareerquestions “learn LeetCode and work for a FAANG” type graduating from college.
Yeah, $300k in the Bay Area isn’t that much. But if you work for a Tier 1/2 company for a few years, it can have a drastic impact on your future employment prospects and salary levels. Furthermore, the street cred can open many doors that otherwise would remain closed to you.
The assumption here is that technical screenings actually work. As many here have pointed out, technical interviews today are highly capricious and pretty have no correlation with actual technical qualifications. "Street cred" and even superb interview performance don't seem to matter anymore.
Most small companies I’ve worked for, I’ve had to go back and forth between every layer of the stack - currently including the infrastructure set up. You just don’t get your hands dirty with multiple parts of the stack at a large company.
Consider the scaling factor for salaries; My salary is on the high end in my area, but would be on the low end of a living wage in the Bay Area.
My salary is in the neighborhood of 120k; I'm a senior-level engineer with almost a decade of experience...
So think about the trade offs. If you’re young and single, the tradeoff between a one bedroom in a major city anywhere not on the west coast and the west coast and the difference in the salary you can make is well worth it.
In most major cities a junior developer will make $60K and can probably find an apartment for $900/month in a decent part of town. If they work on the west coast and get $250K and find an apartment for $2400K/month, that’s a tradeoff worth making.
10-15 years into your career, you may already be married with kids. That $120K he’s making can easily buy a 3000 square foot house in the burbs, brand new build, great school system and close to work for $350K. This is from personal experience (not the salary, the price of the house). Now that tradeoff between $150K and $300K-$400K doesn’t look so appealing when you can’t live nearly the same lifestyle on the West Coast that you could live on much less money
If he’s like me, he’s probably built a local network where any door he wants to open locally is probably already open to him.
In my case, I’m 45, but because of $bad_life_decisions, I only started taking my software development career seriously a decade ago. But I do have a great local network, skills that match what the market demands and the house in the burbs with the wife, the white picket fence and 2.1 kids.
I don’t really need new doors opened to me. As soon as the youngest graduates and I’m willing to travel, I am already in the position of being a high earning “consultant”. Not bragging, I have been working over 20 years, I should be able to consult somebody
I've seen quite a few people only focus on the $300k aspect in HackerNews (and made negative remarks) without thinking about the trajectory.
In my case, I’m 45, why would I move to the west coast for $300K when I can just stay in $major_city and work for a consulting when my younger son graduates and can make $180K-200K+ and still have the same lifestyle?
And then go back to being just a developer anytime I wanted to and still live comfortably?
People who advanced in their career at Bay Area can make 500k or more (IC, not management), solving challenges that did not exist in the first place too (that alone might potentially put you in top 1-5%?). There are more startup opportunities (whether IPO or just the technical challenges, that's up to you) with higher chances of success.
Different people have different goals.
It’s not like I go to work everyday hating software development and hating what I have been doing since I was 12 years old. My wife works for the government and we have guaranteed access to health care whether she works or quits tomorrow.
I can have technical challenges and jump from opportunity to opportunity in two years once my youngest graduates.
Outside of the west coast/HN bubble, people retire comfortably all the time with a million in the bank, I paid off house, and social security.
If you're a single? none.
Married couple with no child? none.
Married couple wanting more children? yes, it matters.
Parents who want their kids to enjoy life? yes, it matters.
Parents who need to take care both in-laws and kids? absolutely, it matters a lot.
2 mills can get you a Duplex (closer to center) /House (further away) in the suburb of Vancouver/Toronto (Canada) with probably 100-200k left. Certainly not enough for retirement. In Seattle (USA), I suppose it depends on the area of your chosen.
How long do you have to work to reach the point of no-mortgage (nice house), kids done college paid by parents, and $2 mills for retirement?
But this is just what might be one dimension of the discussion: financial => lifestyle.
> I can have technical challenges and jump from opportunity to opportunity in two years once my youngest graduates.
We both live in different cities. I don't know your city as well as you do but where I live, there's definitely a ceiling to that technical challenges. Now before we go further with examples... I live in a city that certainly have huge hi-tech ecosystems and quite well known internationally.
I don't see Facebook/Google/Uber/Netflix/AirBnB anywhere nearby. My coworker would love to do impactful ML work. There's zero companies in my city that does ML meaningfully (more than just gluing OSS solutions or calling 3rd-party APIs). I personally would love to work on tackling scaling challenges. These opportunities just don't exist here.
The companies here are quite good compare to major cities out there, but certainly there's a virtual ceiling/limit due to a mix of VC, culture, talent, etc.
Just to wrap things up and to put things into perspective, I'm not a workaholic or ambitious person. I see those challenges as opportunity to invest my skill to stay relevant for years to come so I can take my foot off the pedal a bit. Otherwise, I'd be just an Engineer like everybody else in this city...
That was kind of the point of my replies. I live in metro Atlanta. Not exactly small town America. We just bought a house in the burbs two years ago - 5 bedrooms, 3-1/2 bath almost 3000 square feet, brand new build for less than $350K.
And somehow kids manage to “enjoy life” where the average household income in the US is $60K a year.
Let’s talk about a stereotypical couple. Someone brought up that they were making $120K in a low cost city and they were in their early 30s. Let’s also say the spouse was grossing $50K (about average for a college educated person in the US).
According to paycheckcity.com. The lower earning spouse would bring home $3400 a month. The higher earning spouse would bring home a little over $6000 after maxing our his 401K (pretax) at $19K a year for retirement. Many couples I know in that situation live completely off the higher earners income. That’s what I would have done if I got married at the average age of around 30.
If they were just hitting their stride at 30 with no kids. That $350K-$400K 5 bedroom house could be paid off in around 10-12 years.
If the developer just put $2083 a month (that includes the $1583/month in his 401K) in an S&P Index fund that historically earned 11% a year, they would have 2.1 million in today’s dollars adjusted for inflation (2.9%) by the time he was 52.
Getting the kids through college? Let’s add some variables. The wife could take a year or two off when they had kids and the house would still be paid off by the time they graduated from college and they could put her income toward cash flowing the kids through college. I also didn’t take into account that hopefully they will get more than inflation adjusted wages.
While the numbers for income I quoted above were theoretical, the fact that I have plenty of opportunities to work for a consulting company after my youngest graduates in two years and I’m willing to travel isn’t. I live in the same city as the world’s busiest airport. Getting a direct flight to almost anywhere isn’t a problem. Even Amazon is hiring AWS consultants who live in most major cities.
I personally would love to work on tackling scaling challenges. These opportunities just don't exist here
Even if the challenges don’t exist where I live, one or two of my friends/former coworkers work remotely. As I said above, I’m willing to travel.
But I know people, like my former manager who is in his late 50s, that wanted and did just the opposite, he changed jobs, self demoted to a developer and is doing your basic Microsoft/Azure full stack development. Once you have “enough”, you can get off the hedonic treadmill and make different life choices, you can take a pay cut to have a less stressful life, a better work life balance, etc.
I didn’t make nearly the same “good life choices” as the idealized couple I wrote about above but even I can say no to consulting companies that would pay me more than I am making now because I just really don’t want the headache at this point in life.
One final point. My parents are in their 70s, they retired in their mid 50s in the small town south with less than a million in the bank. My mom was a teacher (with a pension) and my dad was a factory worker (no pension). They aren’t struggling. They had 5 years left on their 30 year mortgage when they retired - they were paying $600/month for their mortgage.
I'm referring to million sctive users of messaging app.
There is more to it than this.
Did we have millions of users? No. The rules were complicated, and most processing happened once a month. There is a central exchange that both sides go through.
I’ve had three jobs in healthcare. While the scale of users weren’t anything crazy. The business requirements were complex.
My background has always been in Enterprise software (healthcare, insurance, BI, etc, almost a decade). At some point I felt that translating complex biz reqs are no longer interesting.
I find dealing with scalability (and hopefully build my own system library) is more interesting and challenging that the Enterprise market.
Consistent Hashing algorithms, Distributed Systems, System programming, build your own programming languages, maybe build my own messaging/background processing?
My salary is in the neighborhood of 120k; I'm a senior-level engineer with almost a decade of experience, involved in some of the high-level planning tasks you describe.
As for CRUD glue...hard call about long term labor market. There's a lot of slip-shod working being done to hold up other slip-shod work. I think there's a good analogy in "unregulated construction." You can hire anybody off the street to build you a shed. If you have money to throw at it, though, you still might be willing to pay 15x to hire a well-vetted professional who will make something both beautiful and lasting.
Hidden information is your friend in any negotiation, but especially here, since the hiring folks also know how variable industry salary ranges are. You want to put the first move in their court - decline to give your current salary at all costs, and ideally also avoid offering up your preferred compensation number until they've made a first offer.
The only point where quoting your current salary makes sense is if the company offers less than you are currently making, and you are in such a bad situation at your current where you'd be willing to absorb the pain of changing jobs for no additional money.
A better strategy is to really research competitive wages and anchor high by honestly saying what you want. If they can’t come close, then walk away. If they ask you to compromise, tell them you’re not going to negotiate against yourself by stating any specific compromises, that you arrived at what you stated by considering what you’re worth, and that you’re happy to consider any kind of offer they would like to make, but that to accept an offer you have to believe it is competitive for the value you can add.
Any arguments about salaries at different cohorts of companies, or salary bands based on years of experience, just outright ignore and tell them if it’s a dealbreaker, you understand but aren’t going to compromise just because of their pay bands or random assertions about market analysis.
If you still decline to discuss a range of expectations at that point, they will usually just drop interest in you and decline to interview you further, assuming that you might just be fishing for a high offer to use to negotiate somewhere else, or that you want way more than they could possibly offer, etc.
This is not just IT, this is the entire job market. The reason is because jobs are "sticky" — it's a pain to apply for jobs, arrange interviews, deal with the possibility of getting rejected. If you're successful you also have to deal with possibility of leaving colleagues that may be friends, the risk that the new position is less stimulating, or having to move house or deal with a new commute.
There is a very real salary range between "low enough that I'll think about applying for other jobs" and "so low I'll actually start applying for jobs". Employers are aware of this and are paying salaries accordingly. It sucks for everyone in that salary band but — ethics and long-term viability aside — it's still the rational economic choice for employers. Every now and again someone will quit and get their deserved 40% increase, but many will delay leaving for years, or simply put up with it indefinitely.
edit: Side-note: if you happen to find interviewing and changing jobs more tolerable than most then congratulations! — You've won the job-market pain-of-change-vs-salary arbitrage game and will enjoy above-average year-on-year salary increases.
At a growing company, if you're a growing individual, there's room for you to rise.
At a stagnant or declining company, if you're outperforming your boss, there's a strong incentive for your boss to want to keep you down to keep his/her job.
In a growing company, your boss might be happy to get your promoted to his/her level. Instead of subordinate, now you're a potential ally on the same level. I think in a healthy environment almost anyone would see that as appealing. In a stagnant company, that could be mean your boss loses the job. Almost anyone would see that as unappealing.
I don't think that's the case at all. I think it's just that typical corporate culture (in the US at least) is not accustomed to giving large internal raises to employees based on increases in that employee's market value.
Most companies base their annual compensation on giving people a few percentage points for cost of living adjustment, then a few more percentage points based on performance. They standardize those numbers so they can say, 'you did average, you get 4%' 'you did great this year, you get 6.5%'.
Many, many companies don't factor in at all that employee value on the market can increase much, much faster than 2-8% per year. Even companies making money hand over fist. The usual way of approaching annual raises is wildly unsuited for compensating talent that is in high demand.
Only once has this gone badly for me, but it went really bad. Tried to mentor a guy, two years later he’s our boss and everybody hates him. Like we go out for coffee to talk about how much we hate him.
Ladder climber extraordinaire. Gotta learn to watch out for those, but in this case he only connived in private and nobody caught on but one and he left.
This is gold. It's just a specific application of, "You shouldn't fight market forces, if you can help it."
Simply coming close to parody
Though, this started me thinking on what "parody bits" would be.
Can confirm. I just got a 54% raise by switching companies. It's absurd. I think a lot of companies just get complacent and don't keep up with the pace of developer salaries, then start leaking talent until it becomes a problem.
From what I've noticed, companies really want to avoid raising salary of an employee in a meaningful way, because it means they will have to increase pay of others also
So 10% increase of salary of 1 employee would eventually equal 10% in crease for the whole team or company, which gets expensive.
This seems to be why they really really hate giving out meaningful raise. They'd rather lose an employee and suffer the consequences, than give 10% raise to one and inevitably end up raising salary for the entire team/company.
And yet, they want to higher senior devs, who obviously left old company to seek higher pay.
As far as I can tell, management that can see beyond the idea that your current payscale is what you should be payed is pretty rare. There's just something about anchoring on a price once it's negotiated.
This is a very US-centric perspective. At least in Germany, the situation is somehwat different. Here, changing companies too regularly, often bears a social stigma.
There's nothing curious or special about the IT industry. It's the same effect as you getting gas at the local gas station rather than driving a few miles to the cheaper station.
All "Senior X," right?
CEO: What happens if we don’t and they stay?"
If you increase the skillset of your employees you get back something along the way, so it's not just money wasted but also collecting a lot of interest. Also you become attractive for employees who want to grow. It's easy for the beancounters to count all the wasted money but it's not so easy to evaluate the real productivity that such employees give back. Maybe if companies were allowed to trade employees like cattle that mindset would change.
Either way - if you trained/grown someone to become much more valuable for other companies and still can't create enough value working for you... Then you have a different problem.
If my six person startup has issues squeezing as much value out of my Dev than FANG companies with all their support structure and research into this, this is only to be expected, imo.
So yeah, it's a problem, one on the list of many problems most companies have though, so it's oversimplified to simply say:"Let's just pay for expensive training and hope they stay."
Yes, you can foster a culture, build a sense of loyalty etc.
but at some point in time even the most loyal employee feels underpaid if he's paid below market because the company can't afford someone at the stage they've reached by working there. I've seen this play out too often to ignore the counter argument.
The incentives of the company and the worker often simply don't align when it comes to career growth.
Let’s imagine that I work a job for three years, and a company spends $30,000 training me over that time period, when I then leave because that training helped me reach a better career position.
If they hadn’t paid for that benefit, I would have left after only two years — because the need to transfer for career advancement would happen sooner. This would save them $20,000-30,000 depending on how you count.
So what’s the net difference?
In scenario 1, they received a ROI of 1 year of improved labor, and 1 year of doubly improved labor. Additionally, the fixed costs of hiring are amortized over three years instead of two, and so decrease by 33%.
So for $30,000 they decreased my hiring costs by 33% and received two years of increased quality labor — say 5-10% productivity. Hiring an engineer is 25-50% of their yearly salary, so they’re saving 8-15% of my salary over three years. The productivity of an engineer is going to be like twice their salary, just to pay overhead and profit. So we’re looking at a boost of 10-20% my salary in their revenues.
So they’re looking at ~15-25% of my salary as the return for spending $10k/year. Naively, it seems like that pays off in many cases: it just requires you operate in a trust based manner.
That depends on whether employees will switch just to get training, and not just for a bigger salary. If not, then training you will just increase your market value, making you more likely to switch.
This is in my opinion (because of the infrastructure) easier to do for FANG than for the startup.
All kinds. From your mentioned international work contracts and payments over structuring the work/code so that in can easier be distributed worldwide,using standardized hardware and software configurations so that adminstration/updating can be done automatically etc.
It's quite simple, you lay them off. I've seen it happen more than once.
This fact is clearly expressed in the UK contractor market which seems to consistently pay a 2x premium over salaried employees. Whilst some of this premium may be based on skills I'd wager a lot of it is buying the right to end employment at short notice (either due to poor performance, or simply in response to changing business requirements making the role obsolete).
No boss is gonna fight for someone who is getting the stink eye already. The lay-off lets then fire with cause without actually doing it. Kinda cowardly, but I’ve worked at places that cut proactively and things got even more toxic. Conversations speculating about who will get laid off next shouldn’t be a weekly thing. It’s paralyzing.
With no work experience, I was hired as a junior dev with a $40k salary, which I gladly accepted. A senior dev mentored me throughout the year and it was fantastic.
Coming up on my 1-year anniversary with the company, I was thoroughly enjoying my job, the people, and the culture. I was hoping to get a raise up to at least $60k, though, since I was significantly more valuable to the company than I was when I first joined. They offered me $50k.
I started applying for other jobs and got an offer for $90k and I accepted it. I still talk with my mentor from my previous job. He's pissed that his company won't pay enough to keep the developers he mentors.
I do find mentorship to be invaluable and hope to have a mentor again in the future, though. I am forever grateful to my mentor from my previous job for the foundation he provided. He instilled good habits and philosophies in me that pleasantly surprised some of my new co-workers and we've even implemented some improvements based on what I learned from him.
If you train someone at work and level them up-- they're not in class 8 hours a day not contributing. They are working on a project.
All software mentorship is based around the idea of growing skills while meaningfully contributing to a project. Actually it's much harder to train someone without a project. I have never once in my career seen a scenario where a person isn't contributing and just learning skills.
After said project is done a trained person might leave. But an untrained employee might leave as well-- for a place that offers meaningful mentorship.
There's absolutely a trap if the now bigger fish stays in your pond for a while and the even bigger management shark decides you can be replaced by him for much less money. As I detail in another subthread in this discussion.
Given the near absolute absence, at least in the US, of rewarding employees who have become much more valuable because of the experience they've gained in doing very real work, you're absolutely right that it needs to be tied to a real project, what you should generally do is complicated even before you factor in the vastly increased probability of it getting you fired. Is the greater productivity your company enjoys for a short period of time worth the shorter tenure of the mentee in it?
> But an untrained employee might leave as well-- for a place that offers meaningful mentorship.
How many of these places exist in the real world?
I've never seen a scenario where a trained employee replaces a more senior one. I'm not saying it doesn't happen, but it's just not something I've seen in my career (e-commerce, a food delivery startup gone global and now a consultancy).
Also, I've seen people take jobs that promise mentorship multiple times. I've seen multiple people take entry level apprenticeships that offer rigorous software development training. I've also seen multiple mid and senior level devs leave for jobs that offer meaningful mentorship in management and offer clear career growth options.
So I guess it really just comes down to this: mentoring others can be a trap if the industry or company makes it a trap. It's up to a company to embrace mentorship and training and ensure it works for both mentor and mentee.
But the more I reflect on this thread, the more certain I become that mentorship is important and cost-effective for any industry.
A company that can't justify training and mentorship is either two things: financially poor or culturally rotten.
This is American capitalism, for all it's good and bad, this is a company first society we live in. A company that can't plan to have enough money to train employees is irresponsible. A company that won't train employees is pernicious. Either way, count me out. In the competition of employers I'll take the one that invests in me, and as I've said earlier, I've seen others follow suit.
This isn't some hippy dippy stuff. I don't want a company to cradle me. A company that can't or won't see the value in training its employees to be more effect in the industry its in has to be a special type of near-sighted. For a variety of reasons this is hardly a death knell for them. Plenty of places consider you a liability and glorified typist, they do just fine, but the rot is there and even if it won't kill them, they are a company diminished.
The question is why would someone leave your company once you train them? If someone is more valuable on the open market than you are paying them, pay them market rates. HR compensation policies need to be in line with the market, not the old “we have a policy of not giving more than 5% raises”.
I’ve been working in development for a $long_time but I restarted my career about 10 year ago and my rise is about the same as you would see from someone just graduating from college 12 years ago. Out of the four job changes I had, two were partially because the next company was willing to offer me $25K more (not talking crazy west coast salaries here).
One other went out of business and the other because they decided “they didn’t want to be a software company” and they just wanted report writers a year and a half after I was hired as the dev lead.
You don’t have to pay the most, but don’t pay so much under the market that everytime the employee sees a random job posting or a recruiter call they know they can make signifactly more just by picking up the phone/responding to an email.
2. Make mentoring/growth a central strategy at every level so people will see a path to grow.
I'd be curious to hear other possibilities.
That helps. But why would I spend a year a two “growing” at your company, when I could both “grow” and make a lot more money some place else?
I’m at a happy place where I work now, and I am decently compensated compared to the market, but even now if someone was willing to pay me $25K more, all other things being equal (work life balance, no travel, short commute), I would jump ship. But the only realistic way I could make significantly more is by going into management (not interested) or being a consultant (not interested right now).
Invest in an employee, give them meaningful and interesting work, and the resources to grow, and you will generate a lot of value that doesn't show up on the books: loyalty.
From the financial perspective, it is almost always cheaper to get more out of a current employee than to go into the market and find someone new.
IMO there are two types of companies: those that know how to develop talent, and those that only know how to import it. The former are often the ones that have a long bright future and create a big impact on the world.
> by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.
This only holds true in a zero-sum game, which the economy is not. Improving the skills of employees actually makes the entire pond bigger.
Not only is this a self-fulfilling prophecy, if you don't invest in your employees, the level of waste is larger.
I recently posted an article on LinkedIn about this very topic: https://www.linkedin.com/pulse/most-common-web-dev-hiring-mi...
Note: I shamelessly plug one of my new-developer friends at the end.
In the long-run, yes. The issue is that most companies optimize for short-term. Managers and executives can receive significant bonuses for keeping their costs down, and by the time the disadvantages of that approach (i.e. people leaving) become obvious, they too have bailed for the next gig.
When you are the one adding the fish to the pond. You know exactly what type of fish it is as it grows. Whereas the fish that you catch may be a catfish rather than a sockeye. The free rider problem is a real thing, but so is the market for lemons.
Most good employees don't quit for at better job unless there's a dysfunctional workplace. Partly they don't know if there's better jobs, and partly it's just a lot of effort, but mostly because other companies don't know they're good employees. The labor market is a market for lemons. If you own a $2000 car that drives OK you don't sell it because other people won't believe it's any good.
I have been following hackernews for 15 years. 20 years since I saw an stallman interview in local pc magazine, blown away by the intensity of the man. I am an artist. I love to read plt stuff and haskell lisp code, I cried over sussman lectures.. It expands my mind, finding ways to express my thoughts so that common people in my world can understand me better, for their sake. I dont write programs, a lot of the code feels unmusical, not ergonomic, my musical background made me aware of how unmusical a keyboard feels like. Learning functional programming has made me aware how most people use imperative chain rule sequences to generate their thought patterns. I would love to work with inspired people just building new ways to express thoughts. But I quietly read and try to translate visions and feelings into code. Writting linear sentences is becoming a drag. It feels as if the time is ripe to raise our conversations to a more constructive functional level. It is happening. It is a slow progress. I can't see myself working in IT because of business deadline material oriented approach. So I continue to quietly read plt stuff. I do not want to understand anything because the other is usually limited to a smaller temporal frame. I read code and apply different real life variables to it and see how the interactions develop within my interaction space. How would you mentor me? /rant
Good culture is good, but no culture fits all personalities.
In the end you probably have to accept that some portion of mentees will leave and try to minimize the rate.
What I would be afraid of that grown up juniors may get stuck in their learning environment and remain junior for way too long.
Setup: Bring on promising “apprentice” and have 3 year roadmap to reaching “solid individual contributor” status
- year 1: pay at market rate for standard recent college grad but payout 60% in year 1, 10% in year 2, 10% in year 3, 10% in year 4, 10% in year 5
- year 2: beginning of year give merit raise to full salary amount based on market rates but payout 75% in year 2, 5% in year 3, 10% in year 4, 10% in year 5
- year 3: beginning of year give merit raise to full salary but payout 90% in year 3, 5% in year 4, 5% in year 5
- beginning in year 4 get merit raise and receive 100% of salary cash that year as well as the 10% from year 1 and 5% from year 2
- year 5: includes 10% from year 1, 10% from year 2, 5% from year 3
If you can’t keep your employee after that, it’s on you, but they’ve def stuck around long enough to pay you back in productivity
(edit: I realize my math is a bit off but I’m on a cellphone on the move, you’re gonna have to mentally fix the math, but you get the idea)
I think this only goes so far. There are better companies and worse companies, sure, but even the best companies have their issues and after enough time, most people want to move on. People also change, and what seems awesome to a fresh graduate may not be great for someone older, so it's always hard to keep everyone happy.
Pay, however, seems to be a motivator that keeps a lot of people in place (certainly not everyone, but a lot). I know plenty of talented people who feel trapped at their jobs because their jobs pay very well. It's common enough that there's a term for it, "golden handcuffs".
While a developer is being mentored and improving, they’re still contributing to the company for the same salary even though their market value is rising.
Eventually, without a raise in salary, they’ll move to a company that pays market value. So developers aren’t free riders because the aforementioned; the new companies are free riders because they pay market rates.
Edit: it may be a free rider issue if the mentorship / training is orthogonal to their tasks. For example, if Starbucks started to offer their baristas CS classes, it’d be a free ride for employees. But what are perks classified as?
This is why company culture is so important. You may not be able to compete on financial compensation right away, but if you have a culture thats great, enables people to learn and grow and work with other great folks, its very attractive as compared to simply throwing more money.
Not to mention: many folks _want_ that kind of mentorship and culture. They desperately want to learn from smart, experienced developers.
If they get far I have a good reference or referral in my future. In the meantime I can offload some of my troubles onto them and worry about other things.
To put it another way, if you think good software requires vigilance, and you worry that there’s a shortage of it, these people aren’t competition. They’re allies.
"What if you don't, and they stay?"
You provide the tools for everyone to improve.
The problem I've seen is that this is rarely true. We've had a big set of grads we've trained that quit for a 20% pay rise, or a project that they happen to like better. Many regretted it but it didnt stop the next guys from doing the same. I'm really burnt out over teaching green newbies again and again.
I mentor the juniors and intermediates on my team (and others in the company), but I also consider the activity to be a sort of mentorship for myself, in an abstract way. By mentoring, I'm frequently discovering better ways to teach and better ways to learn. I also seek their feedback about designs and code on the spot and those conversations that I have, with people who aren't encumbered by a lengthy career in technology, help me keep a sort of "beginner's mind," as it were.
The primary motivators that most people appear to have when they talk about mentorship, i.e., tangible benefits to the company, on-boarding, leveling up juniors, etc... are the side-effects to me. The primary motivator that I have when I mentor others is instead the learning and growth, career and otherwise, that I get to experience that would otherwise be off limits to me.
There is a huge difference between devs that do development for the money and devs that do development because it's engineering. Nothing wrong with this, but it's not a recipe for becoming great developers.
Would you want to work with code monkeys that do whatever they are told to keep/get job or craftsmen that care about what they do?
All of the above is IMHO of course.
Yes I started programming in the mid 80s in my bedroom. But I keep up to date strictly for the money.
Would you rely on someone that started their tech career thinking about pay instead of engineering challenges, problems and solutions?
Thinking otherwise is why gullible developers will work 60+ hours per week while the owners get rich.
Or give them projects they're more keen to work on?
So you can a) hire someone who needs training and then train them, or you can b) hire someone who is productive since day 1.
The people in a) cannot expect the same salary as b). Otherwise, there would be no point in incurring the costs of training them.
Unfortunately, once you train them, someone can snatch them as people in b). You incur the loss, someone else benefits.
Yes, it costs money to train people. Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that.
That's too early. You made an investment, that investment has to break even. With your suggestion, it would never break even.
As far as I know, the company was started in 2003. The founder wrote a custom IDE, VM and compiler. This was the only company that used it.
He hired a bunch of people from a well known but not well regarded private for profit college and paid them below market rates. Of course developers on this proprietary platform were completely useless anywhere else.
By the time I came aboard in 2008 and the rest of the “adult supervision” - a new CTO and developers - they were in the process of transitioning to C#.
Once the bottom fell out of the market with the 2008 recession, they laid off most of the developers working on the proprietary stuff who hadn’t learned C# on their own. They also forced the founder out. They kept me around because I was the only person who both knew C# and knew enough C++/MFC to maintain the old system.
You pay them market when they need to be trained, you pay them market when they move up the skill food chain.
Some of HN works in areas that are harder than the bog-standard CRUD app. So, do you give up on hiring junior developers at all? I believe our whole industry suffers if we come to that conclusion.
It's a failure of the organization to not utilize entry levels from the first week. At any company. After all, the FAANGs of the world have a different bar of entry.
People keep talking about this like you're literally training people how to program. That's BS. Every org has refactor work, tests to write, processes to improve, tasks to research, low hanging fruit bugs to tackle, systems to blueprint, all sorts of stuff that's a strain on the more sr. staff that's been pushed aside but needs to be addressed. You can strategically bring entry levels up in a way that's a net gain in any environment.
That doesn't mean that we shouldn't hire junior developers - in fact, it's our duty as an industry to hire and mentor. However, it is with open eyes knowing that junior developers are not cost efficient in many areas for the first year.
But we go back to the original statement: "With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level."
If you have $320,000, and can have 3 junior developers or two senior developers with the same budget, the 3 junior developers will be a net loss for the first year. They can be productive, but you have to compare on budget.
But I find that as a bizarre set of work that you call out.
* Refactor work is often the largest need from senior developers. Learning how to refactor safely is a separate skill that is not a skill junior developers have without instruction and feedback.
* My senior developers write tests as they develop. If there is test debt, it means sitting down with a copy of Michael Feathers and that is definitely not an introductory text. Trying to write tests for code that wasn't written with unit tests in mind requires a set of skills that many senior developers don't have, much less junior developers.
* I'm curious what processes you see that junior developers can improve.
* Researching tasks can be something useful, but what are these tasks that aren't done while a senior developer needs a break?
* Low hanging fruit bugs are likely the most obvious thing for junior developers, but a highly cohesive team that is writing tests has fewer bugs that are low hanging fruit.
* What systems can a junior developer blueprint? A senior developer understands patterns and quickly solves the problem.
* Refactor - Sitting down with a jr. dev for 15-30 minutes at a time going over the scope for something that is about a day or two of work. Done this many times. We're not talking high-level architecture work, just tech debt the team has let slip away.
* Great. I've never been in a situation where there wasn't lack of coverage though. Focus on things that are somewhat repeatable in nature. The point is doing tests is a great way to learn how the system operates, and basic unit tests cornering edge cases are easily repeatable patterns. Validate w/ PRs, you don't need to hand hold the entire way. No books needed, tons of other tests in your suite serve as guidance.
* Build/deploy system issues. 3rd party integrations. Better approaches to update dependencies. A better approach to documenting an API, automating code documentation, etc. Some particular lack that isn't crucial to operations but is fine letting a cheaper resource tackle as a research task.
* Can blueprint anything that lacks proper documentation. If they can do research for their CS degree they can research and document your system. Yes, you will be giving them little tidbits along the way on how to properly debug or set things up.
AFA 2 seniors vs. 3 juniors, totally dependent on your team structure and the work that needs to be done. If you run as tight a ship as you imply the sr. devs will be a better bet every time from a value basis - but that's rarely the real world. I wouldn't add more than 1 junior at a time to a team of < 6 devs.
Lastly, addressing "that junior developer will take 3-4x the time to handle the same task as a senior engineer". Well duh, don't give juniors the same work as your seniors. The whole point of hiring lower level staff is you have work that is better suited for lower level staff, or rather, work that is too costly to give your sr. staff. This whole it's our duty to train the next generation... you're running a business, not a charity. And then you get caught up in this cancerous notion of people being in debt to you because you don't know how to properly utilize them.
If he leaves prematurely, the loss is realized and the gain never happens. If he stays for long enough time, he is a net gain.
In this regard, unfortunately, we are using a proprietary platform and there is no chance to learn anything until you have access to the bits and docs. Due to that, fresh hires are completely useless to be utilized in any way, until they learn at least basics.
But all the same, any company should be able to make any dev useful from pretty much the very beginning. Whether it's rote refactoring work, research tasks that are too time consuming for more sr. folks, tasks that are in the domain of data entry that can be automated with simple scripts, low-hanging fruit bugs, etc. It's a failure of the org not to properly utilize the abilities of a smart person who knows how to program.
That's a fun game. Most people can argue endlessly about who is responsible for what and then you get to disclose where the money (and how much) is actually coming in. It necessarily constrains the management to a whole new slew of in-fighting and disclosure control. Never gonna happen.
how do you determine the value they bring to the company? Presumably it must be a % of the revenue or valuation growth but I cannot come up how you derive the value.
If this person goes out the door, you're going to be paying their replacement roughly the same as what they'll negotiate elsewhere... and on top of that, you have to deal with the cost of turnover. You basically just lost a ton of $$ by letting them walk. This is not hard. Just run the thought experiment of what it would cost to find a suitable replacement.
See? Looking just for one's interests works both ways.
Pay them cheap during training. After they’re trained, pay a premium to the ones you want to keep. Let the rest go to a competitor. It’s simple.
If you can’t afford that, that’s a problem with your business, not the employees.
We are not trying to have cheap labor. We are trying to have more labor. However, the experienced people are limited resource, so the next step is to find inexperienced ones and train them.
However, that doesn't work that way so easily. If you train someone for 6-12 months (during that time the trainee not only isn't making you any money, but other people, who otherwise would, are not either), you are investing into these people. If they leave before you break even, you are at loss. If you would pay them market rate as soon as they finish training, you would never break even.
That's why some companies insist on contract, that the trainee will stay with the company for specified time, if they take the training.
What I say at interview: “I love building things. I’ve been interested in computers since the mid 80s when I was writing 65C02 assembly language on an Apple //e. I guess you could say that I have always been a computer geek. I’m still amazed after all of this time that I get paid for doing something that I enjoy this much. On my way to work everyday and while I am working out I’m listening to $list_of_tech_podcasts. I try to spend at least 1 hour a day outside of work just keeping up with technology.”
Any developer with a modicum of emotional intelligence can get pass behavioral interview questions because really, the interviewerer doesn’t expect much from computer geeks and most developers.
How would you know that I am really just in it for the money? I’ve been on the interviewer and interviewee side of the table just as long or longer than most people who interview me. I’ve been through $big_company “how to interview candidates” training. Of course I know the answers you’re looking for.
Oh and the old geek who likes to continuously learn helps to answer the question am I keeping up with technology and why I am not in management.
They're training full-time? They're not even doing junior-level work? Why are you paying them a salary then?
> other people, who otherwise would, are not either
Senior folks are getting valuable experience of mentoring and growing people too.
And that's the reason why the wage ramp up is slower, even after finishing the training.
If you already have a bond/contract system in place and employees are still leaving, then IMO you're still paying them too little. If they are happy to pay 20-40% of their annual pay just to leave the company, it means they can make 50-100% more elsewhere. Loyalty is worth something but it's not worth passing up a pay raise that high.
Right now, we directly outline the plan: for now, you will be getting less, once you start working on the client work, your pay will ramp up, depending how much weight you can pull.
You don't, if they leave too early. That's the point.
> hire developers who are productive from day one
That's very rare, true. It was meant to illustrate one extreme. But there is still a huge difference between both ends of the market.
At least that’s always the answer over at r/cscareerquestions
If you decreased a) wages during their initial training to cover the costs and be able to break even with b)-like wages at the end of the training, you wouldn't be able to hire anyone as a) at all.
But this "someone" includes the current employer.
I take the world how it is; including human behavior. On the other hand, you assume someone owes you a training and a then immediately a wage that is the same as someone's who came with all the skills needed.
By that metric isn't Amazon the worst company there is?
And I guess people are grateful for training, but not if they're effectively paying 17% of their pay for that training indefinitely. They'd be idiots to take that deal.
I understand the psychology around not putting more resources into your existing staff -- it's basically "why buy the cow when you're getting the milk for free?" -- but as long as this "5% per year is a great raise!" crap is going around, no one a) upper-mid-level or lower; with b) market value; and c) corresponding self-esteem; is going to stay in a specific job more than 2-3 years. There's no reason to expect anything else. If this is going to change, companies are going to have to start working hard to curb the "impulse buy" psychology at work in racing to get $BUZZWORDY_CANDIDATE_X.
Despite this, there is great personal value in mentoring people. You learn a lot and establish a supportive substructure within the community. It's better to have your mentees move around. That way, they can throw you an escape line if you need it.
People who stay at one company for too long end up with a rusty skillset and a heavily distorted perspective on how things operate. Companies may not notice it, but their cheapness is probably a much better thing for the goose than it is for the gander. Circulation is healthy.
It can suck to run a business - sometimes there's no good solution. I'd suggest more contracting for necessary-but-non-critical skills, but contracting's a jungle too.
And if someone is too junior based on our initial phone call, I just direct them elsewhere and hit then up two years later when those guys have mentored them. Way easier.
Otherwise said, at-will employment doesn't incentivize intensely investing in growing people.
There also might be some relevant variations in corporate cultures around the world, what you say rings true for the US, but the author is in Estonia.
The relationships I've formed with people have always been more valuable than the relationships I've had with companies.
Also, maybe the employee is worth the 20% pay bump after you’ve trained them? It sounds like you’re letting another company enjoy the fruits of your labor at a relatively cheap price.
Are you picking and choosing or are you farming?
Currently we grow engineering skill in (often) high cost institutions with limited capacity such as traditional universities. Moocs and bootcamps are alternatives which try to address the scalability, cost, and time commitment barriers of traditional education.
The question is should there continue to be a strong dichotomy between organizations who consume the output of these growth channels and the growth organizations, or should software development companies create programs of structured education and growth that have a low barrier to entry?
As others have mentioned startups who can hunt/find/pick people with relevant, high quality skills have the advantage of not paying the time and organizational cost of training.
Personally I think that large organizations should be taking more hands-on approaches that take all, or nearly all comers, and then provide training for the kinds of skills they need.
If you look at military funding for medical educations (for example) you'll see that the organization can be very generous in terms of time and training cost as long as a candidate ends up with the skillset they need. You might not go in wanting to be a urologist, but you can end up highly skilled and very well paid if you're willing to meet the needs of the organization.
In this mercenary environment, loyalty doesn't go very far, so, for retention after mentoring, I assume one would have to pair mentoring/training with substantial growth in compensation. Besides all the non-monetary attractions.
It breeds distrust, discontent, and disloyalty.
The best people don’t like this and leave. They company is left with people who can’t land outside offers. And the company ends up needing to pay market rate anyway to replace the good people who left.
We had an inexperienced junior dev come in with an “amazing offer.” This signaled to management that he must be amazing, so they offered a promotion to team lead to keep him. Half the team quit within a month, then he proceeded to run everything into the ground.
There was a certain amount of shadenfreude watching that play out.
I didn't get affected by the layoffs but after about 5 rounds where some of my friends/acquaintances got the boot, I saw the writing on the wall and actively started looking outside. Because it's way more comfortable to be laid off when you have an offer in hand. That's when I realized how underpaid I was. Since then, I made it a professional goal for myself to switch jobs every 2-3 years so that I don't leave money on the table, as the only loyalty I have is to myself and to my family.
Every company, after a while, will start paying you less if you don't climb the corporate ladder to go into management. They will pay you as less as possible considering the risk of you leaving, slowly transition you into working on the old stuff while the new hires will get the green projects. Ok, I'm generalizing but nobody can deny that newcomers are always treated better.
But mentoring transcends companies. I still have great professional relationships with past direct reports working in other places and more often than not they still ask for advice when it comes to their overall careers.
And this is why companies continuously lobby to keep the current H1-B system in place.
1) Every decent size company spends for providing resources like books, learning portals etc. for their employee to grow their skills. There is an entire industry running which caters to provide companies learning tools, for example - safari online books etc. Mentoring is also used a buzzword in these companies. There is a difference between providing tools & books vs creating an environment where people can grow. Mentoring is very inter-personal. Unless companies create incentives for senior engineers to help mentor other engineers there won't be any real change to the way things are now.
2) If your teams or Orgs are always battling to meet the next deadline, how will mentorship happen? You can't expect people to put more than 40 hours of work and expect them to personally mentor other engineers(They still do btw).
5% of time is set aside for training. Works out a little over a half-day every fortnight - every fortnight, after lunch on Friday, drop the code and hit the books, pet projects, videos, experiments, whatever clearly makes you a better software engineer. If you don't spend that time on your own training, questions are asked. Nobody has been fired for not training yet, but if we get someone who simply refuses to, I could see it going that way; when we hire someone, we're not just hiring that person today - we're hiring that person next year, and we're banking on that person next year being better at this.
There is CapEx for books. We have PluralSight licences. New starters' agreed objectives include reading and thence using "Effective C++"; I will come by your desk every so often to chat about parts of it. We have short presentations every fortnight (the time of which doesn't even come out of the 5% training time) on technical topics. Once you've covered the basics, the company starts contributing towards conference attending.
The last senior dev who got internally promoted currently has an allowance of 50% of his time for helping more junior devs understand things. Fifty percent! The intention is to get his senior dev knowledge and experience out of his head and into the heads of five other people; growing ourselves five more senior devs.
I got all this by asking for it. Grow your own. Everyone wins. The company wins, the employees win. Just had to ask; if you ask, and your company isn't interested in improving, isn't interested in producing better products, faster and cheaper... well, is that really the company for you? :)
I am pretty senior and I like mentoring people. But the incentives are generally the other way: If as an IC I transfer my experience to new people I almost get no credit. The manager of the group gets credit for building a good team but I have to justify my salary compared to the people I mentored. So sometimes I wonder if it would be smarter to keep knowledge to myself so I can look better.
But if your culture involves ranking and paying people only relative to each other, I can understand the need to protect yourself. And everybody loses :( The company loses, you lose, the potential mentees lose :(
I like metrics based on how much time the other person has and expects to waste not being able to do anything productive, which strongly suggests you should give him at least two things he can be doing, an obvious second one being reading documentation or otherwise researching necessary stuff he doesn't yet know. After a certain number of hours it's worth an interruption.
And there's the reverse effect that teaching someone else forces you to better learn the subject, so you should gain some extra productivity from this.
Delivered four senior developers in order to accelerate our team's velocity...
that's what my resume says.
Which implies it was only valuable to future companies you worked for. Those that actually believe in mentoring, which seems to be rare based on what others are saying and my own experiences.
However, that's not to say training people up shouldn't be done! I've seen some wonderful developers grow from junior to senior and it's always great to see it happen. Just make sure the organisation is in a position to do it well, otherwise you're doing both them and the juniors a disservice.
Eventually the environment became frustrating enough that I had to move on. Great people, really friendly environment, and even a product I believed in, but it felt so bad to keep having to read through awful, giant, bug-ridden code reviews with the same old rookie mistakes. I only had enough influence within my own team to slow the rate of bad code entering master, but it still came alarmingly fast. I think nobody from my team is still at that company. I really hope management has turned it around since.
EDIT: non-phone spelling
The average is basically zero.
Talking people through things at the edge of their capabilities and discussing the architecture etc that they need to know; that's just doing the actual job, surely.
It's basically 4 conversations and that's it.
My experiences are almost entirely UK based, outside big name or hip companies.
So basically you have to somehow spot right person to spend time with, and it is hard. At least guys that don't want to be mentored are not time sinks.
The counter argument here can be that I possibly may not have mentored the person in the right way using the right motivation, but methods I tried were (ranked in succession):
1.) Showing by example but asking to come up with own examples
2.) Templating examples
3.) Listing out steps
4.) Finally just directly asking to do x, y, and z
Utilizing data patience time boxing.
This is definitely a difficult problem I don’t particularly have an efficient solution to, my best answer is just find someone to mentor who will execute
As far as I know, most interview processes are designed to hire potential. For example, if you can't learn fundamental algorithms in a reasonable amount of prep time to prepare for the interview, but someone else could... Which talent has the most likely potential?
I'd even go and claim that the current interview processes are biased against senior talent. Someone who already knows they are qualified won't be motivated to go and practice fundamental algos that they haven't needed for real work in years. They'll expect their own track record and knowledge to be recognized on it's own. But, the interviews won't care about that. And they might instead hire a junior with more time and motivation on their hand, which decided to spend all evenings for the last two months doing leet code questions.
Similarly, many companies seem to favor new grads, which they can quickly brain wash into their existing engineering culture. They think, these new grads really strive, instead of challenging the status quo, they internalize our processes and work hard to deliver, even if we're being unreasonable. Eventually, this creates a lack of perspective in the entire company. Hiring more external senior talent would help get more perspectives, and prevent this silo of opinion that hurts innovation over time.
Senior devs who are good at mentoring also ought to be good at learning new stuff. They'll also be learning some things from the mentees, at least some of them will know stuff they don't know because our field is so vast.
Once the mentees catch up? If you've inculcated a learning culture, these new senior devs will be learning new things right along with the old ones.
On the other hand, if the company is so overloaded that they really would like for you to put in 100 hours of real work a week.... And if they stick all the developers in an open office, forget about it.
Have been thinking of starting a "farm team" to develop green programmers. Have a meetup once or twice a week, work on a focused project together, do mutual code review. Read the classics (e.g. the MMM) as homework.
Perhaps give out some Amazon gift cards for good work. When a participant levels up, move them to a paid role.
I had the pleasure to meet him when he came to Mexico and he talked about the idea of "pairing" a very junior Engineer (from Mexico) with a very senior one from top companies in the USA to grow them, even covering the English language teaching.
The theory sounds very good but man, at least I was afraid that he was overestimating what "Junior dev" means down here in Mexico (from my experience hiring in MX and US, MX-Senior = US-Mid-Level, MX-Mid-Level = US-Junior).
Still, it is a good project if done successfully.
Let me think about it a bit.