There is a huge pool of exceptional junior engineers
workweave.dev234 points by mooreds 2 days ago
234 points by mooreds 2 days ago
When I hire juniors, I try to give them problems that I know they likely won't be able to solve in the interview because I want to see how they think about things. The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI. I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board. For us, it usually takes about year to get them to the point that they can contribute without some form of handholding. However, that also mostly holds true for seniors coming to us from other industries.
> The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI. I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
I started browsing spaces like /r/cscareerquestions and joined a few Discords to get a sense for what young devs are being exposed to these days. It's all very toxic and cynical.
I've noticed an inverse correlation between how much someone is immersed in Reddit, Twitter, and Discords and how well they function in a business environment. The Reddit toxicity seems to taint young people into thinking that their employer is their enemy and that they have to approach the workplace like they're going into battle with evil managers. I've had some success getting people to chill out and drop the Reddit vibes, but some young people are so hopelessly immersed in the alternate reality that they see in social media that it's hard to shake them free.
>It's all very toxic and cynical
You're commenting on a blog post by a B2B SaaS company that sells AI engineer stack ranking with a cute ball of yarn mascot and you're wondering why they're cynical?
Haha good catch. I wondered why the article leaned into AI so heavily in the second half
>seems to taint young people into thinking that their employer is their enemy
Is this not true to a first approximation though? I mean you do have to "hide your power level" in some way, but the fact that the employer isn't your friend or family is a good working model to keep in the back of your mind. It's a prisoner's dilemma type situation, and defect/defect seems to be the equilibrium we've converged at.
It's true for many companies, but to be successful it helps to act as though it isn't.
Senior leadership sincerely believes that they are a force for good even when they are doing things to harm their workers, their customers, or society at large. It's human nature to feel that way, and to contradict that is to offend them and risk getting labeled as "hopelessly immersed in Reddit toxicity".
And the easiest way to keep up the act is to fool yourself, because most of us aren't good at faking it. Find the best in senior leadership and emphasize it to yourself; find win-win opportunities (or make them!). Maybe it's even true that the company is a force for good! (I genuinely believe this about all my past employers in varying amounts, but I've been choosy and have made sacrifices.)
But be stern about never putting yourself in a position where you can be taken advantage of, because senior leadership, being weak humans like all of us, will succumb to temptation.
> It's true for many companies, but to be successful it helps to act as though it isn't.
"lie through your teeth 8 hours a day to people you see at least 5 days a week"
That is true, but the problem is that nearly everyone believes it. Every dictator and revolutionary thinks they are doing good.
I can understand what you are suggesting, but the balancing act of assuming they are acting for the best and also ensuring you do not let yourself get taken advantage of is very difficult.
To add clarity, that's caused by social programming not human nature.
I disagree. The tendency towards self justification is a universal human trait. Even if some may overcome that tendency, it is still qualifies as “human nature”.
This is germane because while labor and capital may perceive each other as the “enemy” and may in fact act counter to each other’s interests, nearly everyone perceives their own actions as justified.
To the extent that there is “social programming” involved which could conceivably change (unlike “human nature”), it has to do with the acts themselves, not the strong impulse to believe that your own acts are justified.
The way I explain it is that your company is not your friend, but that doesn’t make them your enemy.
The trap is when they see everything as a false dichotomy between friend and enemy. Enemies are something you avoid or even work against. When someone starts seeing their employer as the enemy and they don’t want to do things that help out their enemy, they trick themselves into poor performance out of spite.
Which leads to performance management and eventually firing if they don’t get a handle on it. This makes them even angrier, confirming their belief that their company is out to get them, leading to deeper spiraling into spite and poor performance.
Breaking someone out of that mentality is hard but everyone is so much happier once you’ve cracked them out of the “friend or enemy” dichotomous thinking.
> The way I explain it is that your company is not your friend, but that doesn’t make them your enemy.
Or to hijack Bryan Cantrill, do not make the mistake of anthropomorphizing your employer.
They are not your enemy, you are far too small for them to care.
In your world, is there such a thing as a bad employer?
Something like the analogue to the “Reddit-infused worker” archetype, where leadership is inappropriately cynical about their workers and see them as “the enemy”?
> In your world, is there such a thing as a bad employer?
Of course. If you don’t see that, you’re missing the point.
In your world, is there such a thing as a bad employee? Or do you assume all employees are inherently good and do appropriate work for their pay and don’t need constant performance management to simply do their job?
In my posts I’m not talking about all juniors. I’m talking about a problematic subset. You seem to be assuming I’m generalizing to all of them. I am not. This is a phenomenon specific to a subset of juniors that is unfortunately a repeated pattern where they all share some very common and obvious characteristics. I’ve spent a lot of time trying to break them out of that mindset and have them join their much happier peers, but to be honest once someone is that deep into the cynical mindset it’s hard to wake them out of it.
> In your world, is there such a thing as a bad employee?
Of course — I implied as much via the “inappropriately cynical“ characterization.
The tension between capital and labor is inescapable and ancient.
I didn’t think you were generalizing to all juniors. Rather, what caught my interest was that before this last message I perceived the perspective of capital in your words.
I wouldn't call the categories calcified in a conflict-oriented prescriptive ideology dating to the 19th century to be "ancient", but I suppose YMMV.
There’s a big difference between somebody not being your friend and somebody being your enemy. I’ve had a similar experience with a sub par employee, who at some point admitted that he wasn’t doing his best at work because he was "only there to exchange his time for money, not make any meaningful contributions".
That guy was absolutely immersed in internet culture, making him less self-aware and very unpleasant to work with.
> "only there to exchange his time for money, not make any meaningful contributions"
I sometimes wish companies were more open to accepting these roles, instead of the up or out model.
There is in many teams a lot of busywork that for various reasons can't be automated (or new incoming busywork that takes over when the older one gets automated).
If an employee is content with just handling this kind of lower level busywork and go home at 4:30pm in exchange of not pursuing raises and promotions, there's nothing wrong with that. That work still needs to get done, so rather than getting a never ending stream of junior new hires constantly having to get trained, I'd be fine with having someone who is happy to stay at that level and take it easy.
Up or out generally stops once someone reaches engineer or sr engineer. Most of the time a jr engineer is going to need substantial mentoring and support. Them never moving beyond that point likely results in a net negative gain if you need another person always available to provide that for their entire time there if it goes beyond 1-2 years.
> I sometimes wish companies were more open to accepting these roles, instead of the up or out model.
But companies live or die by talent / passion density. If you try to only hire talented / passionate people, then many of them will still just be fit for grunt work so grunt work still gets done. If you on the other hand hire for grunt work you wont find much talent at all so company fails after a while.
Companies require different attributes in various roles. Those attributes extend far beyond passion and talent. The trouble with hiring based on those two attributes alone is that you're setting up a culture where the people who do the necessary grunt work are failed hires and where the employee themself feels held back. In otherwords, you are setting up a toxic workplace.
I never saw a company hire grunt programmers separately though, and when you suggest that they should people also get angry at you here. So what do you want really? Do you want to have to pass the same tests as these roles, or do you want to pass grunt tests and have a different role? You can only have one of those.
Yes. if the work is installing software and being on pager duty then we can really stop pretending that identifying O(nlog(n))is relevant. And if the job is to write a compiler optimizer, it's pretty important you know the basics of CS (like decidability).
smashing these two together and pretending they are the same has been a huge source of cognitive dissonance in the industry and serves no one.
I mean with as many 'who do these simple Google bugs last for years' posts we see on HN, how much of the grind and grunt work is getting done? If everyone thinks they are a superstar then anything that's not an A+ project ends up on a 'killed by Google list'.
As bad as big non-tech companies are at things I quite often see they are better at providing fixes and updates for the little hidden pieces in the background because they have people that aren't fighting their way up the ladder.
This mindset existed well before reddit; hell, it existed well before the Internet.
Some people simply show up at work solely to put food on the table, doing the minimum amount of work so as not to get fired.
Showing up to work and actually doing their job, even if it’s the minimum, would be an upgrade over the Reddit toxic mindset I was describing about.
The problematic juniors show up to their jobs determined to be uncooperative, sow discontent among coworkers, stonewall progress in meetings, and think they’re just going to job-hop to the next company before the performance management catches up to them. They see the jobs or even the concept of working to live in general as a scam and feel like they’re winning some deep cultural war if they collect paychecks while making life difficult for their manager.
Have companies given any of these young people a reason to think differently?
“I have altered the deal, pray I don’t alter it further” has been the majority of my career and my peers. Very few people(as a percentage of population) actually have had enough leverage at any point to not have to eat shit if their company says so.
This is the type of toxic, cynical attitude GP is talking about. It doesn’t have to be this way, and you approaching it with this expectation is possibly creating a self-fulfilling prophecy.
When you look at the quality and the dog eat dog mentality of many CEOs out there do you expect any different? If you can look at modern capitalism without a cynical eye it's very likely you've lived a pretty privileged life.
CEOs are also employees. This is a weird thing where you have invented enemies in your head you’ve never talked to.
Yeah capitalism is sad in a lot of ways - particular the modes of possible value. But we are actually talking about working in hierarchical management organizations which have existed forever and have nothing to do exclusively with capitalism.
Thats not reality though.
I didn't get laid off 3 times because I have a bad attitude. I got laid off because:
1) it was cheaper for the company to move the software department over seas
2) The business got sold to Amazon and as part of that process they had to downsize
3) Company collapsed due to leadership failure
I had a good attitude until I saw how disposable I was to these companies. You're an asset until you aren't.
Product finished? downsizing. Financial crisis that doesn't effect our industry? downsizing. Company about to IPO? downsizing.
Companies have no loyalty, you shouldn't either.
And? Part of the toxicity is coming from a misunderstanding that for some reason the company is morally obligated to keep offering you employment ad infinitum.
If the work runs out, find another job. Nothing wrong with that.
It is not toxicity if they are expressing pragmatic reality of how employment works. It is just being respectful and direct.
I didn’t really approach it that way. The companies did to me. My experience with companies has been entirely that unless the money is already in my pocket, I should expect them to renege on the deal.
At this point it’s in the corporations court. If you have managed to generate a relationship with your labor force where they are no longer lying flat, but actively trying to cause sabotage like you described then I think you(the companies in question, not you in particular) share some of the onus on how we got here
Edit: and to be clear I’ve been working in tech for over a decade, this is not a perspective from a new grad with only the internet as their source of information. The younger generation has seen their older siblings and cousins getting fucked over more and more each year and we’re reaching the point of societal unrest where a large group of people no longer think the “deal” society is offering them is worth it
Who would've thought that decades of wage repression that fell especially badly on the young would lead to a surly and uncooperative workforce.
Programmers are incredibly well paid.
Just the existence of the Bay Area tech antitrust suit and the pittance of a settlement should tell you otherwise. Who knows how sky high developer salaries would be if those companies hadn’t conspired to lower salaries during such a strong and low-interest-rate economy.
A subset are paid incredibly well. For arbitrary lines im going to put that at 250k+/year in comp by year 2-3 of your career.
Another large cohort is paid pretty well with salaries from 110k-150k by that same point who have effectively no negotiation power and are given “take it or leave it” deals with the only leverage being to find another job
And even for the incredibly well paid ones, as the other commentator noted, there’s documented proof of organized wage suppression by the corporations
Not in comparison to the value they provide.
A grocery store I worked at tracked finances and they were available to all employees. The grocery store made $270 per worker per hour. New hires were paid less than 1/10 of the value they provided.
I can only imagine how much more exploitative tech is
Try measuring how much house a median junior programmer salary will buy and compare it to how much house a median wage of the 1950s would buy.
The results will surprise you.
I mean ... if a junior can stonewall a progress on a meeting then seniors there somehow horribly failed the meeting moderation. I have literally never seen that, because you can just make meeting without them the next time
Second, I seriously doubt juniors ability to "sow discontent" among more experienced seniors. They can latch on existing discontent, but juniors are too low on hierarchy and seniors have too much of opinions for juniors to have much power there.
In some sense this is the standard gambit of wage labor. If you want people to act like they have skin in the game, then they must have that. Tech is notable as a field for incentivizing overperformance and mission-driven-ness.
Only in places with SV like culture.
In many countries being a developer is a plain office job just like everything else, and everyone that doesn't want to move into management after reaching seniority is seen as a failure.
The mindset exists because historically commercial entities have often been horrendously abusive to their workers. Dickens, anyone?
The flip side is the terror of an entrepreneur seeing their enterprise struggle.
That is the antidote the toxic attitude.
Go into business yourself for a bit and see the world from an entirely different angle. If you don't make it and come back to employment (most likely) you will be a much humbled and more enlightened person.
I mean really no, and yes I've been on both sides. Owners have skin in the game. That's why when Musk says we should work 80+ hours a week he should be summarily ignored. He stands to gain billions while the rank and file stand to gain ulcers and an investor class that fights against them getting health insurance.
The number of absolutely toxic business owners is insane.
The number of absolutely toxic employees is also insane. Are businesses justified to treat employees as if all of them were that toxic? Should not employees then not treat their employers as if all of them are toxic?
I think it’s important to distinguish between human leadership and the capitalist entities they work within.
I’ve worked for multiple small businesses, led by wonderful humans, which ran out of money. When those businesses went under, it tore their leaders apart to let workers go — but those leaders were still constrained in how the could act by economic realities.
There are both leaders and workers who are too cynical about each other. But it makes sense to be guarded with every company, even if I think it’s debatable how best to act — and how we might dream of improving matters at the macroeconomic level.
I don't disagree about the number of absolutely toxic business owners and I've worked for a few of them.
But there are some real bad employees too that don't understand how the world works.
Maybe the toxic business owners should work in the coal mines for a bit?
You don't solve the problem by "humbling the workers".
The solution is rewarding people when a company is successful and more importantly not punishing hard workers. Right now people are under the impression that slacking and working hard will be equally rewarded, because that is the truth. Hard workers also get laid off so that CEOs can make a few extra bucks.
This mindset is completely sane. Sorry but if you work 40+ hours a week and barely can afford a vacation there is no reason for me to work hard. Especially not if I see managers with new cars every year.
> Sorry but if you work 40+ hours a week and barely can afford a vacation
Software developers are relatively highly paid. When they start acting like they’re minimum wage workers flipping burgers at a dead-end job, they’re missing the big picture. That’s the problem I’m trying to communicate.
This is a generalization. Salary in Europe is different to salary in the USA for example. I earn median wage currently. Also lots of non degree having devs out there that aren't 6 figure earners.
That's the tradeoff you're making for universal health care and generous public benefits.
I don't know why you come up with an ideological statement like that.
The management culture, anti software/nerd mindset among the population and eastern European competition in the offshoring market have a much bigger impact.
E.g. even though Germany is practicing mercantilist beggar thy neighbour export surplus policies, the country has failed to become an exporter of software or be known for quality software. Anyone who wants to work in the software industry is better off leaving the Eurozone and going to Switzerland where they get paid more in addition to the things you claim are the cause.
I've had the same experience -- employees who do the minimum and then whine when (one case) asked for a raise or he'd quit and I said sgtm; and (a different person) I chose to mentor and promote other people on the team. Some people can't wrap their minds around the idea that our interests aren't always aligned, but sometimes they are and also why would I invest in someone who doesn't invest here. Mentoring and promoting people is one of the best pieces of my job, but my time is finite and I want to also spend it productively :shrug:
It’s not that simple. Even if you take the cynical view that the company is your adversary, the other people who work at the company (including founders, investors and execs) are actually playing a career-long collaborative game rather than a one-off prisoners dilemma.
That's only true for the young. As they get older, or the exit grows large enough, some people smell that last iteration and defect hard.
> the fact that the employer isn't your friend or family is a good working model to keep in the back of your mind.
That's completely different than being your enemy.
What you want to avoid are work environments where most workers are focused on gaming internal politics to get ahead. Those environments are soul destroying.
But that's not all work environments. And most work environments are some mix of internal politics and wanting to actually create good and useful products.
Executives are almost solely focused on financial rewards.
Employees (middle management and down) are explicitly structured to use salaries (to reduce costs/earnings from going to them).
Salary is generally a flat monetary incentive, and bonuses aren't big enough typically. You make more money by promotion up a rigid hierarchy: so that is the true motivation.
And that is politics.
If you have salaries, you have politics, and a downward trend towards more of them.
Engineering workers are often idealistic, which is a different set of motivations to exploit by management for monetary advantage. But idealism/creation leads to turf wars and emotional investment in "your code", which is another entire axis of politics.
> Executives are almost solely focused on financial rewards.
This is not true at all. Far more important in upper management is ego - they will lose money to improve their legacy or beat a competitor.
> If you have salaries, you have politics, and a downward trend towards more of them
Nobody said politics do not exist.
So let’s take what you said at face value - management is paying for jobs but they are looking to cut costs, etc.
Is that arrangement something you can use to benefit your life for a season? Or an inherent war zone?
No. opposition is not the right model
It’s just business. You have something they want, they have something you want. Try to take advantage of places where your incentives aligned and watch out when they are not.
> >seems to taint young people into thinking that their employer is their enemy
> Is this not true to a first approximation though?
No, not at all. The company wants the employee to do well so that the team does well and the company overall does well. If the company was "the enemy", they company would be wishing for the employee to fail, which is not why they spent a lot of time and money to hire you in the first place.
Now, of course the company isn't your friend (or family) either. The employer doesn't exist in the friend-enemy axis, they're just an employer which is a different type of relationship.
Also, who is "the company"? People in upper management and HR, i.e. those who see you as a number on a spreadsheet but don't ever interact with you personally.
But most of your interaction is with your first and second level managers who are specific people. One would certainly be well advised to cultivate a professional friendship with them. Not only will you do better, but work will be a lot more pleasant.
> The company wants the employee to do well
> Also, who is "the company"?
The company doesn't "want" anything other than to become a bigger pile of money — it's an amoral abstract construction, lacking human wetware and all its messy idiosyncrasies. I think I'd express similar sentiments in a slightly different way: the company benefits when it gets maximum value for minimum outlay over the lifetime of the employment relationship.
That model allows for companies which act in ways wildly counter to the interests of their workers. For example, the private equity firms asset-stripping Toys 'r' Us and KMart mostly "cared" that the workers at a given retail facility not quit before they could be let go.
Sometimes it is, sometimes not.
In 2009 I worked for a really chill company with small but nice management. The owner/CEO wanted to turn it into a worker-owned co-op.
But one of my coworkers was so stuck in the "management is evil" mindset that he became hard to work with. (Although he also radicalized politically; I think he went from SNP to UKIP.)
Yeah, a lot of Reddit seems to be people wallowing in their own unhappiness.
As far as the attitude toward employers, I kinda get it. A lot of these kids were sold the idea that college will mean a solid, lasting career and, pre-pandemic, a lot of companies were trying to sell themselves as a “family” and throwing cheap benefits around (ie. free food, beer, etc) only to yank most of that back during/after the pandemic.
It also doesn’t help that, inside US, it sometimes just feels like we’re trying to scam each other constantly. All of this is breeding a ton of cynicism.
> lot of companies were trying to sell themselves as a “family”
Has your company actually done this?
When I was doing mentoring I heard this complaint all the time, but literally no one (juniors on first jobs in this case) could point to an instance of their employer saying it. They had all picked it up from Reddit as something the archetypical company did, and they felt obligated to punish their company for it.
Similar problem happens with take-homes: About 90% of the take-home interview problems people shared in the #interviewing channel were entirely reasonable, short, and clearly not real work. Yet many had picked up this idea that take-home problems were unfair because they were “a week of unpaid labor” or that companies were using them as a tool to extract free work from candidates. So they tried protest the concept of take-homes and stated they would refuse to do them in protest. Of course, when they actually received one for a job they wanted they would abandon that mentality and do the problem, and in many cases they preferred that to doing in-person interviews. Yet the mentality remained that take-homes were evil exploitation and they must rally against it because they read so many Reddit comments about it being “unpaid labor”.
>Has your company actually done this?
Ive worked for plenty of companies that pretended that they cared about the human resources and not one that has ever been upfront about the fact that they will lay you off for a bump in the stock price without blinking.
>Similar problem happens with take-homes: About 90% of the take-home interview problems people shared in the #interviewing channel were entirely reasonable, short, and clearly not real work. Yet many had picked up this idea that take-home problems were unfair because they were “a week of unpaid labor”
It's largely been my experience that a lot of companies think an 8 hour take home is actually 2.
They tend to be badly constructed and full of ambiguities that require you to read the mind of the test setter.
Of course the people who set them dont know this and they never test their tests. My experience on the other side of the hiring desk is that rank amateur shit is the norm.
The "unpaid labor" thing happened to me once, I think. It was a company that wanted somebody to build an X. Take home was "build an X". Not common, doesnt happen to juniors, but it happens.
Corporate America could clean up its act or Gen Z could force itself to grin and bear it with a smile it like you seem to want. I wont hold my breath for either to happen.
As someone approaching 50 years old, "workplace like they're going into battle with evil managers", not sure where you are located, but in southern europe countries it has always been like this, regardless of the job.
That is why many countries still have a strong union culture, everyone gets exploited to the bones and they should be happy to have a job if at all.
It is quite depressing sadly, but that is what happens when many managers lack business education and see employees as replacable cogs without rights.
> The Reddit toxicity seems to taint young people into thinking that their employer is their enemy and that they have to approach the workplace like they're going into battle with evil managers
What you’re saying is very true unfortunately and is going to be a real problem. It not only affects how you view your employers and companies but also your peers. If you’re exposed to extreme views even before you start your first job, what happens when you eventually start your first job?
> If you’re exposed to extreme views even before you start your first job, what happens when you eventually start your first job?
You are less likely to be taken advantage of?
Cynicism usually doesn't help you, no matter how trendy it might be to be a cynic.
The more likely outcome is that you'll (intentionally or unconsciously) perform poorly, have a bad attitude, and always act like your employer is out to get you. Your managers will notice this and not like working with you. Eventually you'll get managed out or fired, and then your cynical opinion will be reinforced by this experience, even though it was avoidable.
I'm not saying you should think your company is your friend or your family (they're not!), and I'm not saying you should work uncompensated overtime, or buy into the whole company "mission" and "values" and stuff. But do go in with a healthy attitude, get your work done to the best of your ability, and act professionally and, sure, be friendly toward your coworkers, and develop relationships with them and your managers (professional ones, not personal ones, if that's not your thing). If your management still treats you poorly, then yes, absolutely, get out of there. But going in with a bad attitude isn't going to set anyone up for success.
The more likely outcome is going to be that these people will be left behind. If you came in with extreme views like say for things like DEI, would you be able to work that well with a female manager or a black coworker? If you came in with extreme views about lofty wage expectations or not working extra as a salaried employee, how likely are you to be hired or be put up for promotion? Keep in mind, we are not talking about reasonable takes, we are talking about extreme views that are formed solely through online spaces and not personal experiences.
> or not working extra as a salaried employee
Getting paid to work is a normal expectation…
> not working extra as a salaried employee
This is not an extreme view :/
> Keep in mind, we are not talking about reasonable takes, we are talking about extreme views that are formed solely through online spaces
You’re taking it out of context. I’m not talking about a 996 culture or regular overtime, I’m talking about ocasional extra push to make things work. Any full time salaried employee will tell you that it is completely acceptable to work extra here and there, when you are allowed to take it slow at times.
Agreed. I’m a senior dev. With rare exceptions I work 8:30 to 4:30.
My previous job gave us every other Friday off.
I get things done, do a good job and get nothing but positive feedback from my bosses.
Framing DEI skepticism as an inability to work with minority or protected groups makes me think you don’t understand the position well.
Framing some of the extreme views of DEI as DEI skepticism makes me think you don’t understand the extent of radicalization that young unemployed people are going through.
I think you may be imagining a disruptive person who can’t work with others, and then associating it with a political position.
10 years ago I'd pretty consistently run into 4chan-types as well (I was browsing 4chan as well, so I'm not immune to this).
There's definitely an aversion to treating real life and "the internet" separately in a certain cohort of people. But the kinda edge-y meanness gets really weird when it's applied to coworkers and the like.
There are also people marketing things on Reddit to young people: alt coins, option trading, sports gambling that have an incentive to say working is for suckers, your only hope is to get rich quick. I think most young people are smart enough (or cynical enough) to reject the get rich quick schemes. But the same cynicism allows them to accept the messages that tell them that things are hopeless for their generation, work is unrewarding and you are way behind.
Outrage yields clicks/revenue. So there is a financial incentive for media and influencers to fuel extreme narratives.
With that said, there are truths and lessons to be learned on the internet. I think it's possible to take that benefit without developing an overly negative outlook on everything.
It’s not media and influencers doing this, though. It’s Reddit comments and chronically online peers in their Discords.
Weirdly enough, streamers like Primeagen are actually disabusing juniors of some of these notions.
It’s the grassroots commentary sowing the seeds of discontent.
> some young people are so hopelessly immersed in the alternate reality that they see in social media that it's hard to shake them free.
One of my favorite staff/principal engineers always begins Monday's by asking people what they did on the weekend. He always talks about the things he did - farmers market, local parade, etc.
It's shocking to many of the junior engineers. They generally do "nothing".
They just don't want to tell you because they don't think it's your business.
Anyone who thinks their boss/coworkers are their friend is surely deluded. There is no loyalty in this day and age-- both from the employer and employee side.
Even asking "how was your weekend?" -- its implied that you just say good rather than sharing details of what you actually did -- they don't really care.
The employer might not be the enemy but the employer certainly is not a friend either. Also its expected of young people to spend their time off with these things as well. All this plus the constant fear of being laid off results in people simply not caring too much. Which is reasonable. Maybe the bar is simply too high for what you get?
Companies are amoral profit-seeking automata. Individuals, even those in senior leadership, have only limited capacity to act in opposition to the company's nature.
Workers can definitely forge mutually beneficial relationships with such entities but anthropomorphizing them leads to sorrow.
Corporations are the reason for lobbyism and wealth accumulation which actively damage my personal quality of life. Its only fair for me to not view them in a positive manner. They view me as an asset, I view them as necessary evil to afford housing and food. I should not anthropomorphize them, yes, but I can anthropomorphize the management and stakeholders. And if they are greedy and behave as such, its my good right to be repulsed by them.
This only applies to large monopolistic companies in an unregulated, thus nonfree market. The most companies, which actually perform the work in the country are small people, who have huge risk and not much money and generally have the company, because they like the work and want to create things. Most people are moral, otherwise we had far more crimes.
It's a simple business arrangement. Corporations give you money, you provide work.
Yes it's possible and maybe even common to be taken advantage of in a business arrangement but that doesn't negate the concept of honer. You have agreed to provide work for a set amount of money. If the other party isn't acting honorably you can leave the arrangement but otherwise you should fulfill your part of the deal as best you can.
When most parties act honorably society does well. When the concept of honer breaks down into lying, cheating and scamming as a way of life, society will collectively not do well.
As far as I'm aware, nobody ever improved the situation of society by acting dishonorably. The Reddit complainers should try forming their own Reddit society and see how it works out.
No I should fulfill my part of the deal. In no way I am obliged to do it "as best as I can". If my employer isn't happy with my work, they can let me go. My employer is essentially exploiting my workforce for their gain and unfortunately this is not compensated fairly in most cases. I'll work hard if I actually believe in the cause and am treated fair. Otherwise its minimal effort that gets the work done.
> I've had some success getting people to chill out and drop the Reddit vibes
How did these issues manifest? And what approach worked for tackling them?
> The Reddit toxicity seems to taint young people into thinking that their employer is their enemy and that they have to approach the workplace like they're going into battle with evil managers.
They aren't that wrong however. Over the last two-three years alone we've seen waves of layoffs. Layoffs from FAANGs hit the headlines, but so many more happened without hitting the news.
And the thing is young people... They adapt.
They usually don't have the cultural baggage we older people have, so they often see things for what they truly are without any rose-tinted-glasses from past better times.
Their grandparents were able to get a fairly stable job at a company, stay there until retirement and grow a family. Their grandparents were able to switch jobs IF they wanted to. On the other hand, kids nowadays know they will likely be fired at some point, irrespective of their performance, and that they need to play the game for what it is.
Can you really blame them?
It feels like a self-fulfilling prophecy, though. If you go into a new job, full of cynicism, doing the bare minimum (or less), acting like everyone there is out to get you, then you shouldn't be surprised when you're the first to go when layoffs happen (or sooner, even).
Yes, the labor market has changed, and in many ways not for the better. But layoffs are not new. I remember my dad being afraid of them back when I was a teenager in the 90s. I remember him getting hit by one of them, even, and scrambling to figure out what to do (fortunately he was re-hired by the same company, in a different group). I survived layoffs in the three following decades; yes, the most recent waves were brutal, but I wouldn't say they were anything special compared to, say, ~20 years ago.
You can recognize a company for what it is (a capitalist organization that cares more about next quarter's numbers than whether or not you still have a job), but also be a positive, professional person, who goes in and does good work every day, gets along with coworkers and managers, and doesn't play games. You can be realistic without being a toxic cynic.
> their employer is their enemy
Without significant safeguards and in the average case, the employer seeks to extract more from you than it gives back. You on the other hand, must work or you will die. This is a power dynamic that positively stimulates the growth of bad behaviour. Knowing that has nothing to do with Reddit, it is an inherent fact of this system.
> thinking that their employer is their enemy and that they have to approach the workplace like they're going into battle with evil managers.
Given how many managers are strongly steeped in the mindset that every IC is an innately lazy bastard out to scam the company out of as much money as possible for doing as little work as possible, and explicitly design their policies that way (not to mention structuring their personal conduct that way), this is probably wise.
Hopefully it can galvanize more of them to form or join unions! Labor power is a vital tool in the current age to take back some of what we have lost over the past few decades to burgeoning corporate power.
In fairness, many employers exploit their workers. Wages have been supressed for multiple decades. Rights stripped through arbitrary pay-for-play work agreements, etc.
Eventually you lose all goodwill and get a saturation of ill-will related to that exploitation, debt slavery through student loans or worse. Quite a lot of business people blind themselves to the reality.
Those that drink the kool-aid are always in the next round of layoffs, after they pulled 80 hour weeks to have a project come in on time. Its not reddit fueling this, its bad business behavior at scale unfortunately.
No one can fool everyone all the time. The deceivers are always eventually found out, and then its "we can't find anyone"...
The young listen to the stories of people who have accrued a certain amount of experience who are in their 40s now, and quite a lot of those stories are not success but rather exploitation, use and abuse, oh and now all the jobs went to AI... its a trend, and its going to get real bad because the old needed the young to take over those jobs to fuel their money-printing debt spree over the past 30 years. Demographics are destiny, and you either get slave labor, or you get movements towards letting things rot when the environment reaches a certain threshold, and is disadvantaged in the fullest sense of the term.
No offense, but in America, this is true, employer are an enemy.
Reddit is american and trusting businesses is how we continue to fail.
Like mike tysons iconicquote, everyone has a plan until they get hit in the mouth. You may have good intentions as a managsr until theres a "market correction".
In america, this business toxicity is well deserved and will only get worse.
Sure some may take defensive employee relationships to far but acting like this posture is toxic to appropriate self care is gaslighting.
I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
There were major downsides to the days when programmers were all computer nerds. Specifically, it made the career very off-putting to anybody who didn't fit that stereotype. Any time you do that, you miss out on a lot of potential talent.
Still, though. There were upsides. The passion level seemed higher. The climbing salaries attracted people solely attracted to... the climbing salaries.
I'm tired of being treated like a fucking Martian because I understand basic data structures and why sometimes you might want to use a tree or some other computer science 101 shit.
When I hire juniors, I try to give them problems
that I know they likely won't be able to solve in
the interview because I want to see how they think
about things.
I can see an upside to not telling them. If they try to bullshit their way through an answer because they think a definitive answer is expected, I guess that could be a useful data point. But it feels mean and unethical.
When I've done this as interviewer I've been pretty explicit. Like, "Hey, this is something we've been working our way through for months and we don't expect you to figure it out in ten minutes. But how might you approach this?"
I have fairly limited experience as an interviewer so I'm curious how others have approached this.
I think it's way worse now with barely any upside but salary, compared to 10, 15 or 20 years ago.
It’s 100x worse with the tech bro chest thumping and the competitive toxic behaviors inside teams.
And autonomy/ownership is now rock bottom with multidisciplinary teams. Even things made supposedly to empower devs like Agile/Scrum became tools of a managerial class that wants to decide where each pixel goes.
> Specifically, it made the career very off-putting to anybody who didn't fit that stereotype.
That wasn't it. It's just that the position wasn't so highly paid back in the day and there was way less demand, so hardly anyone was even interested.
The moment it became remotely attractive, the tech bros arrived.
Not buying this.
People with good software skills had paths to making a lot of money from the day computers became widely available.
Look at Woz in the 70s or Microsoft or the Macintosh team. From the birth of the PC revolution there was a path to getting rich from computer skills if you were in the right place at the right time.
Those were entrepreneurs, not regular engineers.
My aunt's career as an IT engineer started in the 80s. She went into this field because it was a new niche to explore and hardly anyone knew their way around it.
Her role was to take part in digitalisation of the bank she was working in and by "digitalisation" I mean first putting the equipment together.
You said it. Such mixed feelings.
The reality is there was a sweet spot - when the industry got less toxic and started attracting visible minorities, and you started getting some diversity of thought AND passion.
Then the money got too good and it started attracting the personalities that 10 years earlier would've become finance bros and caused the 2008 crash. And they fucked it all up.
Interesting - I see the appeal of this approach. Equally, I do the opposite - I give easy problems which can be solved quickly. I find people either can do them pretty quickly, or not at all.
I used to ask harder problems, like you, but found two failure modes: either smart people who panic and can't think straight in an interview, or people who can do high level thinking but then can't swap two variables in actual code.
That said, thinking back on my recent hires, I'm not sure this method has yielded any improvements.
> That said, thinking back on my recent hires, I'm not sure this method has yielded any improvements.
I've been involved in hiring panels across several companies with very different interview strategies. Before going into this I leaned heavily toward your style: Easy questions that act as a simple filter for people who can't program.
Looking back, I have to admit the simple question approach wasn't as good as I thought it would be. The companies who gave more difficult questions and pushed candidates toward harder and harder interview problems with the expectation that they would hit a wall at some point really did sort candidates better. I know there's a widespread belief that difficult interview questions are prone to too many false negatives due to anxiety in interviews and people who freeze up. However, when we tried interview do-overs or alternate take-home problems as a fallback for these candidates we didn't really see any improvement. I can think of a few candidates who we talked ourselves into giving a pass because we assumed interview anxiety was obscuring some real skill, but we got it wrong in both cases.
I still don't know the correct answer, but these days I'm leaning more toward the interview formats where the questions get hard enough that the candidate is really challenged as opposed to the simple ones like FizzBuzz where it's just a quick filter. Note that I've worked in domains where algorithmic problem solving is something we actually do, so finding interview problems that match problems we've actually solved in production is possible, not just rote LeetCode stuff.
> simple ones like FizzBuzz where it's just a quick filter
I stumbled across a thread in r/cscareerquestions or maybe r/cscareers a while ago where several people argued that fizzbuzz was too hard because: "no-one is using the modulus operator in day to day work, so it's not something one should be expected to remember."
I found it very funny and draining at the same time.
The technical question I have start easy and get progressively harder as we go deeper. I think thats a good strategy - everyone I interview should be able to get started, even if they're feeling anxious, and if they cannot then we can both save time.
Then as it gets harder the interviewee is familiar with it, and I find that often people with less CS experience are still able to work through it even though they don't know the terminology. And we have a grading based on how much hinting we needed to give, which is very helpful guidance to me as an interviewer.
The problem I usually pose is a slimmed down version of one I actually tackled, so it doesn't feel like an arbitrary test that has no real application. Which again, very helpful for when I need to write a rejection email, as I can say where the candidate didn't meet expectations, which often seems appreciated. We're encouraged to reject during the interview if it's obviously not going well, which I've done but I do find very hard.
What a refreshing level of honesty! Admitting that perhaps your new method also doesn't work. Thanks for sharing that! It's often lacking from online discourse.
(I also prefer easy-to-solve challenges. And usually bring up more complex topics during problem solving to assess candidates)
I get where you’re coming from. I’ve have experienced the “smart person who panics”.
I usually tell them upfront that I’m not looking for the correct answer and that I just want to see how they break the problem down. I also try to reiterate that it’s okay to fail (at least at my employer) and that’s the point of having a team.
Usually, that calms them down enough to get the interview going. If they don’t calm down, I’ll try to simplify the problem or give them small ideas.
We’ve also resorted to having a follow up interview with the candidate if we get the sense that they were overly nervous. I have a couple teammates that are very good at getting people to relax and we’ve had a good amount of success with letting them lead the follow up (instead of myself since I know I can come across fairly cold).
Well, the lacking passion could be explained because the most known tech companies aren't very attractive. They intentionally obfuscate any technology, restrict access and disallow experimentation.
If you want to leech on the crowd that likes tinkering, you shouldn't give them some shitty iOS/Android environment and call it a day. For the industry, tinkering has become a security problem, scary warning boxes about unverified code being run on a piece of metal. How horrible! It is old and stagnant and just not that interesting.
There are some alternative venues instead, but they have a focus elsewhere.
When I hire juniors I give them problems that focus on fundamentals.
If a junior can code vanilla JS well, they can learn React, Vue, Svelte, etc. if they can't, they will never fully understand any of them. If they can write raw CSS, that can learn Tailwind and understand how and why. If thry can explain what's happening in the browser console, they can find the entry point for most bugs.
This is pretty much how I also test seniors. Focus on the fundamentals; if those are off, nothing else matters.
When I used to interview developers, I was more interested in how they approached problem solving and working collaboratively than attaining any correct answers.
So I'd split the interview in two parts. The first bit I'd give them a set of requirements and ask them to come up with a design for it on their own. They had internet access and technical references available. It wasn't a memory test, and I'd leave the room (this probably wouldn't work well now given LLMs).
In the second part, I'd ask them to talk me through their design, and then explain we were going to change the requirements and work together on altering it to accommodate them.
The second bit was the most useful part of the interview; it's what we needed to do in the actual job, and pretty much everyone we hired in that process was good.
> a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI
Even before AI, there were issues with super-polished leetcode grinders. Their entire skillset was passing FAANG interviews via memorization of correct solutions and scripted answers.
An effective technique for identifying these cases leverages the fact that you can only have a "correct" answer memorized if optimal solutions exist. Fortunately, there are many common and relatively simple problems in computer science and software design that require reasoning from first principles because globally optimal solutions can't exist even in theory. Small changes to the problem constraints lead to wildly divergent design outcomes that are effectively not enumerable. The possible solution space is so large that you can't realistically memorize it even if the problem is relatively concise and well-understood. The pure leetcode grinders never seem to have studied problems without tidy answers.
The answers don't even matter that much, I am always more interested in the demonstrated ability to recognize and reason through the implications of constraint changes when there are no correct answers. People with solid computer science skills can usually muddle their way through it, whereas many people with immaculate leetcode skills fail the most basic versions of this.
The most important skill of juniors was demonstrating that they could effectively reason about and were motivated to dive into problems they had never seen before. These were always the juniors that could be rapidly developed into strong senior engineers, which is more or less the objective when you hire juniors.
> The answers don't even matter that much, I am always more interested in the demonstrated ability to recognize and reason through the implications of constraint changes when there are no correct answers. People with solid computer science skills can usually muddle their way through it, whereas many people with immaculate leetcode skills fail the most basic versions of this.
> The most important skill of juniors was demonstrating that they could effectively reason about and were motivated to dive into problems they had never seen before. These were always the juniors that could be rapidly developed into strong senior engineers, which is more or less the objective when you hire juniors.
I agree 100%.
This is similar to what my advisor told me my PhD thesis defense would be; your committee would probe you until you got to the limit of your knowledge (generally in your domain but not specific to your exact topic) and only then could they test how well your reasoning abilities. I think this is a great evaluation technique but it was common practice in my PhD program that, as you started getting close-ish to your defense, you'd organize some practice sessions with your peers where you could recreate that kind of environment because being able to step beyond your knowledge, especially in front of a group of gatekeepers (your thesis committee or potential employer), while maintaining a professional level of composure is difficult! And most of us couldn't quite handle it well when we would practice with each other but after a few sessions we'd feel comfortable in that state, at which point the pass/fail is, in our opinion, much more reflective of your actual reasoning abilities. As an interview tactic, especially for juniors, it's an interesting idea and I'd be curious to know how well you think it works, but I think it would take most 90th percentile candidates 2 tries to really demonstrate the kind of critical thinking and reasoning skills that you're looking for.
I find that the ability of people to understand hypotheticals is extremely diminished.
"How would you troubleshoot x"
"I havent done that before"
"Ok, but how would you approach the problem"
"I dont know sorry"
I've seen this once. I was talking to two guys that I met randomly, and I said something like "Rich people see you the way you see homeless people". One of them instantly understood what I meant, while the other one got stuck on "but I am not homeless" and even his friend couldn't explain the idea to him.
"bro trust me bro I saw it on 4chan bro people can't just make shit up on 4chan, it's like impossible bro cmon bro just trust me"
How is that not understanding a hypothetical? Seems they understand it just fine, what they're saying is they don't have the needed knowledge/confidence to answer the question.
Not understanding a hypothetical would go like this:
"How would you troubleshoot X?"
"Why, is X broken?"
"No, but imagine it was broken."
"If it's not broken why are you asking me that"
Ok, but a completely fair and honest answer is to google it. Or review internal documentation/asbuilt for the system. Or to ask your mate steve.
You don't need to understand the technical detail in the hypothetical, to extract search terms and research it.
The answer of "I dont know that system so I wouldnt know where to start" is failing the hypothetical. You have many starting points for all technical research. It means you cannot even imagine where to begin.
If you are so shocked by the appearance of technical term you don't understand, that you wont even take the first step of putting that term into google, you really shouldn't be applying for technical jobs.
The most common answer I get, if I fight the interviewee, and reposition it as a technical issue they do understand, is that they relay to me an anecdote from a time when they did complete the troubleshooting. IE, they still dont engage with the hypothetical, they just use recall.
There is a subset of companies where they test to see if you stop yourself and admit you don’t know.
It’s a question where you should preface if you don’t know, then make sure you’re game to just try.
I drop it mostly to see how people think.
People who answer with research/troubleshooting methodology, go on to be excellent employees.
People who dont attempt it, are generally unable to cope without handholding.
"In as much detail as possible, describe what is happening when I enter https://google.com into the browser and hit enter"
> I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
Well, if we assume that the share of the population of nerds is roughly constant-ish, then an expansion of the total number of developers would lead to nerds making up a smaller and smaller share.
The idea that people have different aptitudes and proclivities has become a radical concept to some these days.
Maybe.
Back in the olden days, you needed to be a hero who knows all the innards of your 8 bit machine just to produce a decently playable game that was more sophisticated than Tetris. These days even an idiot like me can hack something together in a high level language like Python or Rust. That's progress!
Similar to how everybody carries an awesome digital camera around with them today. The absolute number of photographers has increased dramatically. And even the absolute number of great photographers has increased dramatically, because constant practice helps.
But I'm fairly sure the skill and dedication of the average person engaging in photography has dropped equally as dramatically: that's how lower barriers to entry look like.
Many junior devs can often leetcode crazy algos but don't know what 'ls' or 'df' does.
I feel like it's at two ends of the extreme. Either the junior is literally better than everyone else on the team, or they know nothing.
> Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board. For us, it usually takes about year to get them to the point that they can contribute without some form of handholding.
I know that such places exist from reading HN but it always seems so counterproductive to join such a place as a fresh grad. As a beginner you need to be getting your hands dirty, getting some ownership and respobsibilities, making mistakes and decisions. Figuring stuff out, exploring tradeoffs and experiencing them firsthand.
It's like when a football player joins a big team before they're ready and spends a year or 2 on the bench. It completely stunts their development and they never reach their potential. When you look at those who reach the top, they were all playing nearly every match from a young age as an important member of their team.
Obviously I'm biased due to personal experience, as everyone is. And there naturally must be upsides to joining your company as a first job as well. But I'm very glad that in my first job I was writing production code and doing both brownfield as well as greenfield stuff by week 2.
The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI
I’m pretty senior and I memorise a bank of leetcode solutions if I’m going for an interview that is definitely leet code. It has served me well for some interviews, and will remain my top strategy. I can still solve problems on the spot when needed, and much prefer challenging non leetcode programming problems, but that is far and few between.
I don’t see how a year is an indication of something going wrong.
Year for a junior is perfectly reasonable.
Definitely making a commit to a GIT repo or opening a PR for textual change they should be able to do in first days. But doing any bigger task on their own that needs architectural understanding of our system a year is definitely good.
Great idea re: giving hard problems. Same motivation behind why we ask people about past projects and keep diving deeper and deeper. The point is to figure out if they're curious & capable of engaging on a deeper level, vs. just following a tutorial they found somewhere.
I don't think computer nerds are needed (I've worked with plenty of very good people who don't write a single line of code out of work), but I have noticed a huge uptick in people who are in the space for the money. Nothing wrong with treating work as a place for money, but the hustler mindset combined with being an annoying 22-year-old twerp is exhausting.
Please go back to fighting over finance and consulting jobs, people. Please. I know my salary is inflated thanks to the dynamics that also bring in these people, but I really would like to avoid working for people whose choice matrix is "finance or startups".
Yeah, we lost a lot of nerds with the higher status of Computer Science, or rather we got a lot of non nerds/geeks into the mix. Every year as the criteria went up at the University, I saw less of the type that had always been there.
As an EE working on energy based models[1]; good.
No one should be required to acquire a special literacy or hire an expert in a specialized literacy to use a well understood computing technique (Von Neumann and Turing).
IMO software first engineers are not much different than rent seekers. Using lexical tools based on understanding from the 1960s is hardly high tech.
For all their high minded rhetoric, SWEs are just self selecting biology driven by "FU got mine" philosophy like so many others. After 30 years in tech, it's become quite clear the majority are not much different than an ICE agent; willfully ignorant because their personal compensation banging
[1] figuring out how to store/recompute the geometry of an oscilloscope to keep it brief; too much syntax sugar involved as-is
I noticed I had an immediate bias against candidates that showed up to interviews using Windows (except for one person who was in WSL and seemed very comfortable in bash), or, not having their SSH key set up for cloning the github repo we used for our interview, or fumbling back and forth with their mouse between vscode and the browser, not using all their screen real estate, or not knowing even the most basic of keyboard shortcuts (I nearly cut an interview short once when I saw someone right click copy right click paste in vscode but I wanted to give them a fair shake so gritted my teeth and went through with the rest of the interview. They did poorly.). I never used it as a for/against factor but for me lack of interest in computers, and a lack of familiarity with the tools of our trade, is a red flag.
On the flip side, immediate green flags for me were: using linux, using keyboard shortcuts to manipulate windows / within the IDE, using an IDE other than vscode (vim/nvim or emacs are huge green flags), having custom scripts, having custom themes, or, the biggest one, self-hosting some applications. And Lo, these candidates also seem to perform the best in my experience.
> I nearly cut an interview short once when I saw someone right click copy right click paste
I like to live in the terminal, but I still sometimes do that. There are multiple clipboards, so using the mouse might sometimes do something different and sometimes I'm just tired and want to use my hands in a different position. And if I selected with the mouse its not much more effort than stopping the selection. You press down left for the selection, move for selection, at the end roll the finger over to the right mouse button without lifting, continue moving so the pointer goes over the rollover and lift the finger again once the pointer is over the copy action. This is the same amount of finger lift than just stopping the selection. Then pressing one or two keys on the keyboard are two finger movements more.
That seems pretty opinionated, and by building a monoculture, persons with high openness to experience likely won't be drawn to your workplace, and you're also leaving on the table the potential that comes from diversity (a loaded term these days, but substantively still a valid point).
Depending on the kind of work you do and your customers, this may not matter to you, but in a lot of industries, you need the diversity to be able to properly represent and empathise with your customer base, who might be from a very different social cohort than your developers. And Linux desktops, which your customers almost certainly won't be using, may also make that difficult.
People who spend a ton of time ricing their Linux desktops may be bad at setting priorities. If you expect them to continue their ricing, but not do it "on the clock", you're implicitly age-discriminating and discriminating against people with families and/or hobbies and/or "a life".
Also keep in mind that your company is likely only one of a dozen or so workplaces that these people apply to in a given month, sometimes for many months before they land a job, and they probably haven't set up their computer specifically to impress you, but rather to fit the lowest common denominator among the requirements they face from all their application processes and educational activities, and some of that will require Windows.
Some points in parent comment are absolutely valid IMO. Would you hire a carpenter who walks back and forth to his toolbox to pickup at single nail at a time and then use the hammer with both hands near the head. And when cutting a 4x4 beam will use 1-inch strokes with the handsaw (again with two hands).
Using SSH to get the project files is not a good example of a hard to learn skill they need for the job, they should just have provided a zip on a web page or so or sent it directly to the user.
So to me it seems most of the test was just "have you done these trivial things before" rather than test if they can program web apps.
It would be like the carpenter being forced to buy nails and docking them points for now knowing where the closest shop to buy nails in are and taking time to look that up. Of course it is better if some look it up quicker, but its not a core part of the job. Then when they drove there, you gave them a manual stick car, so the ones who were used to automatic fumbled around in the car, also bad look! So now you see carpenters who drove manual were much better, as your biases told you! That is not really the skill you should care about, it is very quick to tell him where it is.
I don't think your analogy is apt. Having your development environment set up and knowing how to use your tools reasonably efficiently seems like it should be a low bar to pass. We're not talking about giving someone unfamiliar tools or an unfamiliar vehicle and expecting them to perform higher level tasks. We're just watching people use their existing tools to see if they're actually familiar and comfortable with them.
I had my own reply, but using your analogy if I may: if I asked an apprentice carpenter to measure up and build some sort of structure in front of me with the tools provided, and they stumbled and made some awkward choices but the result was otherwise sound and they had other good qualities, yeah I'd consider hiring them. I think the scenario you describe though would be more equivalent to someone who flat out doesn't know how to even use a computer, which is a different case (I wouldn't hire that person).
I was thinking about basic tool use. I expect a junior engineer candidate to wield a computer way better than my mom. They are applying for a junior engineer position not and apprenticeship starting with close to zero training. I have no problem with candidates who stumble and make awkward choices during the interview, as juniors by definition lack experience and the interview process is a stressed situation.
I think we need to stop seeing "can program" as being equivalent to "is an expert computer user", because those are genuinely two different, if related and overlapping, skillsets.
There is no particular reason that an expert C++ programmer also needs to know every keyboard shortcut or be an expert at the Linux command line, if those things are not actually relevant to the job you're trying to hire them for. Just because it's been common among millennial and older programmers (like most of us) to combine the two doesn't mean we should discriminate against programmers who don't fit that mold, as long as they're actually good programmers.
You're presenting a false dichotomy, though. No one in this subthread is expecting an expert computer user. We're just expecting them to have their development environment already set up, and to be familiar and comfortable with their tools.
If they come in with a Linux laptop but aren't comfortable with the command line, that's weird. If they come in with a Mac or Windows laptop and do solid work only with GUI tools, that's fine. If the job requires being able to use specific tools (command-line or GUI or whatever), then the interview should evaluate that as well.
Then, among 200 resumes, how do you find the good programmer? If you have budget to hire one of them.
Well, first of all, most likely dozens of them, at least, are good programmers.
In fact, most likely dozens of them will be perfectly good hires for the position.
The idea that you must hire only the single best possible candidate can lead to some pretty dehumanizing treatment of applicants, when the truth is that a) there almost certainly is no "single best possible candidate", there are many people who would do a roughly equally good job there, and b) your processes are almost certainly not optimized to actually find the true single best candidate for the job, but rather the person who is best at applying and interviewing for jobs among the candidates.
All that said, for "how do you actually design a better process"...I sure as hell don't know. I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.
> I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.
No, it pretty much does mean that.
Until you can come up with concrete improvements and understand the potential flaws in those proposals as well, you can't usefully critique the existing system.
Can only a master chef tell you that your chicken is undercooked?
Can only a trained programmer tell you that it's a bug when you press the "OK" button, but your program does the "cancel" action?
Can only someone who knows exactly how to build and fix a system tell you that a specific aspect of the system is flawed?
Better example: you press the ok button, and sometimes, only sometimes, it triggers twice.
You tell your lead, they say "I know." You ask why they haven't fixed it, and they lead you down a deep rabbit hole of fundamental, unsolved issues with event bubbling, and show you the 20 different workarounds they've tried over the years. "In the end," they say, "nobody's figured out how to not get it to sometimes fire twice."
Thus hiring. Sure it looks not right to you, but, come join us in hiring and you'll see, a better way has yet to be found. At least when I run interviews it's an actual real problem rather than a leetcode thing - I always just grab something reasonably difficult I recently did for the company and convert it to an interview problem.
Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain. Of that 10, 2 were the best. Criticizing not wanting to work with the best doesn't make sense to me. Lemme put my capitalism hat on, there: we have competitors, we need to code faster than them to get clients before them. If we don't, we lose revenue and don't get another funding round, and the company dies. Also all hiring is reported back to the investors who have an expectation we get good people. Also we give equity - why wouldn't I want the best possible people on my team so that I have the highest chance of my equity paying out big?
Capitalism hat off, yup, this system is dehumanizing and not configured to deliver the greatest societal good. Alienated labor detached from the true value of the goods produced, absolutely. What can I do about that at my job? On the side I run a co-op that operates under literally the opposite principles: anyone can join, we will train you to get the skills you need to get better jobs, and no margin of the rate is siphoned away for a capitalist class.
The problem with your last paragraph, of course, is that there is no "system", no generalizable concept of "societal good", no such thing as "true value" independent of the subjective evaluations of an object by disparate parties, and no "capitalist class" that actually exists as such.
Everything is down to particular patterns of interaction among particular people, all acting on their own a priori motivations, with none of the reified abstractions you're referencing actually existing as causal agents.
I applaud your efforts with the co-op you're describing, and if you're able to make it work, scale up, and sustain itself in the long run, more power to you. But it's a bit strange to imply that in the more common scenario, it's somehow untoward for the people paying the upfront costs of your endeavors -- and indemnifying your risk exposure -- to expect a share of the proceeds in return.
> Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain.
I mean, this is fundamentally dependent on the specific position being hired for.
I'm interested in this conversation however this comment doesn't really mean anything to me. What are you saying? And so, how would you hire? If you just wanted to say, "hiring sucks," I agree. Hiring sucks.
This comment is saying "the percentage of any given 200 programmers applying for a job that are, in the end, reasonably fit to do the job depends on the job being applied for".
If the job is a mid-level C++ programmer job at an insurance company, many more of them are likely to be good fits than if it's a senior embedded systems architect job at an aerospace firm.
Yeah, seems I'd be doomed for doing interviews on my Windows laptop for the webcam and the compatibility with my bluetooth headset rather than my linux desktop. Tunnel vision and a lack of empathy are negative signals, so you could say I'd have dodged a bullet, but unfortunately in these situations I'd need the job more than the job would need me.
From my perspective, I think it shows poor judgment that you've chosen hardware where you can't get your webcam and bluetooth headset to work under Linux. Or you haven't bought a wired headset and a USB webcam that you've researched and know works properly under Linux. It sounds like the alternative you've chosen is to take interviews using an OS and development environment you're not comfortable in, which seems like a foolish choice to make.
These days it's not difficult to buy hardware with Linux in mind, even on a budget. (And if you have two computers, I feel like budget is probably not really a problem for you.)
Even if you bought with Linux in mind, there’s no guarantee what works today works tomorrow. I have a Linux box that had working HDMI audio. A recent set of updates to the audio subsystems now means that when the box boots, the HDMI devices are muted by default. It seems like something changed in the order that things are initialized and the HDMI devices aren’t present when the audio system is initialized so none of your saved settings are re-applied. Every boot now requires manually fiddling with the audio settings to reset where audio should be going and unmute the devices. If my choice when going into an interview is the box that you need to buy specific hardware for and hope that no one re-configured the audio subsystems in the last update or the box that runs an os by a company known to put explicit code paths to recreate a prior edition bug that other software relies on… I might choose the latter too, even if it is windows. Of course I’d also probably choose the latter because there’s a non zero chance the interviewer is going to want to use some conferencing software or website that doesn’t work in Linux regardless of how well matched my hardware is.
I simply don't use a headset or a webcam with my home Linux setup, because it's often been a hassle to deal with, and my work setup is separate. For screen-sharing type coding interviews, I have a perfectly functional remote SSH setup from my windows laptop, which took less time to setup than the last time I fiddled with a bad headset connection on Linux a long time ago. I find the "not using all of screen real estate" accusation to be strange as well, because usually screen-sharing is ergonomically limited to 1 screen, but people may usually work with two screens and not have developed habits to make 1 screen work.
> sometimes for many months before they land a job, and they probably haven't set up their computer specifically to impress you
I wouldn't expect them to. I would expect them to have their computer set up to program. If it's not set up for programming, then, that's ok, they just won't fit in in an environment of people who really, really enjoy programming, and most likely aren't able to program at the level we expect. This theory worked out - about 10% of candidates were the kind that program regularly, for fun, or at least to build their portfolio, and of that 10% the one we ended up hiring turned out to be phenomenal.
Like I said, the people who got furthest in the interview (solved the most problems) were the ones who had computers set up to program and were comfortable in their environment. Everyone got the same email, everyone knew they'd need to clone a repo and run node, and everyone who got the email had already passed the initial screening so I'd expect them to actually start reading our emails and taking this stage of the interview process seriously, considering it was the final stage (and the only stage involving actual programming).
> you're also leaving on the table the potential that comes from diversity (a loaded term these days, but substantively still a valid point).
Diversity comes in many forms. Someone not great at programming, or not that interested in it, I'm happy to select against. Do you have a reason I shouldn't filter these folks out? We're paying someone to code at the end of the day so I'm pretty confused at all this pushback to my bias towards "interest in computers."
The other diversity markers I don't think were selected against - I have no idea what "high openness to experience" means but we had people with all sorts of different personalities and interests that we interviewed, all sorts of backgrounds, and sure all sorts of different gender expressions, national backgrounds, refugee status, race, so on.
> People who spend a ton of time ricing their Linux desktops may be bad at setting priorities. If you expect them to continue their ricing, but not do it "on the clock", you're implicitly age-discriminating and discriminating against people with families and/or hobbies and/or "a life".
Sure, and every hiring manager that puts people through a coding interview is implicitly engaging in ableism - someone with severe mental disabilities won't be able to pass the interview. Capitalism is ableist. I agree. They also had to have right to work - something I personally don't give a shit about but the State does. What am I supposed to do about it?
Anyway interest in computing and "having a life" or hobbies or a family aren't mutually exclusive. At all the companies I've worked in, I've been surrounded by super nerds with families and other hobbies, alongside interest in computing. I've known a mom that went sailing every weekend and programmed circles around me, a married individual running a pokemon selling business and a lasercutting etsy store on the side all while having the healthiest marriage I've ever seen and personally aspire to, folks that brew beer or garden or make cheese, a hella greybeard that runs DND (and ran a campaign for the office alongside two others he was running)... all of these people I mentioned far better programmers than me, far more advanced knowledge of computers than me, and I don't do even close to that much outside of computer stuff.
So, I don't know what to say other than I guess the last few companies where I worked and ran interviews at at just had really energetic people and wanted to hire more energetic people? That's something to criticize?
You mention IDEs besides VS Code, Linux, and ricing as “green flags”. Those are not proxies for “being a good programmer” and they are not proxies for “being enthusiastic about programming”. They're just selecting for programmers who share your subjective preferences on matters that are the equivalent of “vi vs. emacs”.
The only workplaces that realistically allow people to use Linux desktops are academia and top-5%-sexiness-factor startups. The other 95% of us have to use what our boss tells us to use (and he got told by the insurance company that scammed him into cybersecurity insurance). Those of us who have families, don't spend our leisure time staring into yet another desktop computer that isn't our work machine, so how, on earth, would we be using Linux desktops?
Conversely: Imagine someone has spent an 8-hour-workday setting up their tiling window manager, so they can “improve their productivity” because now they don't need to spend 2 minutes painting all their windows into the right positions in the morning. That's an investment of time that takes (8*60)/2 = 240 days, so roughly one work-year, to amortize. What does that tell you about the time management skills of that person?
I don't say that to knock tiling window managers: If you're into it, be my guest. It's perfectly fine for reasonable people to reasonably disagree on those kinds of subjective preferences. That's what subjectivity is all about. And that's why it's valuable to hire a diverse range of people who have different viewpoints on these kinds of things.
EDIT: ...and that's what I mean by "diversity": To include both family-people and people without families. Young and old. People with an academic background and people without one. Vi-people and emacs-people. Please don't strawman me by bringing up disabled people and work permits and whatnot.
> You mention IDEs besides VS Code, Linux, and ricing as “green flags”. Those are not proxies for “being a good programmer” and they are not proxies for “being enthusiastic about programming”. They're just selecting for programmers who share your subjective preferences on matters that are the equivalent of “vi vs. emacs”.
Are you sure about that? I have a strong suspicion that there may be a measurable correlation between using IDEs and other tools that aren't currently trendy/overhyped and having a stronger-than-average foundation of experience.
Given that VSCode is the big, trendy IDE at the moment, doesn't using a different one indicate that a developer has, at minimum, invested some thought and effort into considering alternatives and making a conscious choice?
> The only workplaces that realistically allow people to use Linux desktops are academia and top-5%-sexiness-factor startups. The other 95% of us have to use what our boss tells us to use (and he got told by the insurance company that scammed him into cybersecurity insurance).
This is super ironic and shows your "us" in "the rest of us" is a tiny, marginal group, maybe "Silicon Valley programmers" or something. In most small software companies they couldn't care less what you use, the only thing they look at is perceived "speed". You could install Red Star OS and get a few pats on the back if you're closing the highest number of Jira tickets.
Hell, nowadays more and more are full remote and the devs do their work on their personal device. Or they do BYOD. Work devices are a cost center.
It's the opposite, the only places that force a particular OS are the top companies for whom compliance, fleet management and such are priorities.
Kind of funny, these mutually escalating accusations of being a member of an out-of-touch elite.
All it takes for BYOD to become difficult is having to handle personally identifiable information under the rules of the GDPR, or having some kind of professional indemnity insurance with cybersecurity provisions, perhaps having quality management certification, being in certain highly-regulated professions like law or medicine, being in the public sector, working government contracts, etc. etc. (the list goes on and on) -- I'm just finding it hard to believe that this list doesn't capture most companies.
But then again, maybe, I am a member of an out-of-touch elite.
> To include both family-people and people without families. Young and old. People with an academic background and people without one. Vi-people and emacs-people.
Well, I don't know what to tell you, you've just described my entire team, same as my previous company that had a bunch of linux/unix dweebs, so the fact that we're all really into computers hasn't hindered us from this diversity.
All my jobs have let me choose my OS, all my jobs were full of people exactly as you describe, they just all happened to be really into computers. How the family folks found time for it is a question I still ask myself to this day when I compare my knowledge to theirs, but regardless, it wasn't a hindrance.
So I maintain my confusion around selecting for this. It's just not my experience that it prevents me working with family folks, or old folks, bootcamp kids and phD ML people.
So, ok, we've come this far: How do you run interviews? What's the alternative to the way I've seen?
> And Lo, these candidates also seem to perform the best in my experience.
You mean the people you're not prejudiced against for their choice of laptop OS tend to perform better in your eyes? Interesting.
The interview has various portions, given in sequence. The ones who got the furthest (or ran out our interview to where we had to invent "new fun bits" on the fly) were the ones who I mean when I say "performed best."
The interview was implementing in live coding a prepared frontend stack. The email sent out indicated explicitly the task, that they'd be expected to share their screen and clone a repo off github, run `npm` commands, and then pair program. So those that weren't prepared for this, fussing around with ssh keys not set up or node not installed, or not knowing how to use bash or git, yeah it counted against them.
> right click copy right click paste
Remembers me of a fellow student who refused to maximize his editor window. It turned out that he moved the text cursor to the next line with the right indentation by using just a lot of spaces.
Some of these yes, some of these no. In general being a clicker is a completely fine way to weed people out. If you don’t code like time is on the line without being asked to, I will not take the risk of needing to ask you.
I’m less passionate about windows and have met some absolute wizards who use it, but in general it’s a negative indicator.
> cloning the github repo we used for our interview
Unless it's a very well-known big tech, I'm not sure I'd feel comfortable running any externally provided code during the interview. For all I know, it's RCE with potential to steal cookies and/or crypto.
It's a FOSS repo on github... you can just look at the code yourself. If we RCE you you can easily sue us lol.
So for you, how should a company determine from 200 applicants, which one will be able to do the job best? Or at least some approximation to get down to the 5 most likely to do the job best?
I think going by that, for juniors anyway, isn't great. Remotely coding during an interview isn't a great environment to start with, and you're probably seeing a lot of people unable to achieve any sort of flow because their mental capacity is devoted to the interview. Some people also won't pick up more advanced tooling until they have to start coding day after day for a living, and until they have other people to learn from. That was my situation anyway.
Copying and pasting with the context menu, sure. But using vs code or Windows entirely? That seems a little extreme.
Using vscode wasn't a red flag, using a different IDE was just a green flag. Everyone uses vscode, I wouldn't hold it against anyone for doing so, especially not a junior. But picking a different tool exhibits a unique level of interest in the job and our tools, and a different mindset. Those are pluses for me.
Nobody was rejected because they used windows. It just so happens that none of the windows folks got past problem 1 of 3 (as in, they ran out of time without solving).
Edit: I'm remembering now, one of the windows folks did get to the end of the interview, and they were the first person I recommended actually, so it's not like it was a deciding factor, just something that I'd see and go "hm" about.
That just means you insist on people like you are reject those who are a little different. Probably in a lot more areas then you are even realizing.
> Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board.
That's one reason why I prefer "fresh out of college" for juniors - if they seem bright enough that way they only have to learn, not also forget whatever nonsense they learned somewhere else.
> I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
Ah, yes, the passion thing. I'm not being sarcastic, i see this as well.
I saw the shift happening in the 2010s, and I attribute this to essentially two things:
- social media and the glamourification of computer programming (and related things)
- the startup craze of the early 2010s (everybody and their dogs wanted to develop an app or start up a company, and money was flowing left and right from more-or-less clueless investors).
In a way, I'm happy that money is tight right now, deep down I hope the computer programming/science scene goes back to people driven by passion and money rather than just money.
By giving candidates problems you know they can't solve during the interview, you give yourself the right to dismiss anyone "you don't like" by telling them they failed the test.
If that was your intention, why would you need a pretext? You're not obligated to hire anyone in particular in the first place, and apart from being accused of purposeful discrimination based on protected characteristics, you're not obligated to explain your decision criteria to anyone.
> The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI. I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
Why is this a problem, though? Imagine hiring doctors or architects with that expectation. "The problem is that no one is truly passionate about dissecting cadavers anymore".
I think our industry got hooked on being able to hire self-taught geniuses in the early days of tech. But the profession has gotten a lot more commoditized, and we just can't continue like that. Gotta hire "normal" people and teach them what they need to know. And yeah, "normal" means people who decided to learn programming because it pays well, not because they want to design compilers in their spare time.
because there are multiple abstractions in software that one is bound to come across once the software becomes complicated enough, and from that point on "passion" and "fundamentals" determine how effective they are at navigating that path
I completely understand people that are just doing it for the paycheck and that's totally fine.
However, I do feel that our team needs both types of people to be effective. People that have passion will try new things and explore possibilities more frequently. The "just a paycheck" folks tend to be a good moderating force to the "passion" people. They will generally bring focus and keep the end goal in perspective.
My goal is to avoid having too many of either. Too many "passion" people and you end up slowing progress because they're getting bogged down with everything they want to do. Too many "paycheck" people and the team/system starts to calcify (and usually accrues a ton of tech debt).
The doctors i know are definitely passionate about it. There is continuous learning, conferences, picking your specialty, and its such a time commitment the profession is part of your identity.
What people (managers?) don’t realize (or don’t want to realize) is that building software is much more complex than most other professions. Some software is easy and has been done n+1th time (like a simple crud app with a db connection). But some software is really hard and could fall more in the R&D category.
Which brings me to the following point: Earlier in my career, I was a medical student. All superiors were doctors, and though there were managers, no manager intervened in an operation. Also doctors selected their hardware and methods. No manager will ever come to a doctor and suggest that they do their work differently.
Now when it comes to software, everyone wants to chime in.
No offense, but this software engineering elitism does no favors to perceptions of the field. In reality, most other fields are complex and the phenomenon of believing something is simple because you don't understand it is widespread across fields. Dan Luu expounded on this at much greater length/with greater eloquence: https://danluu.com/cocktail-ideas/
If the medical doctor screws up they go to jail. When was the last time a software engineer went to jail because of malpractice?
Software talk is free. So everyone can chime in. Your experience holds no weight. Heck an LLM can do it too.
Hiring juniors is always great if you, somehow, have a much better filter for finding the stars than the rest of the market. But if you don't, hiring bad juniors is a disaster: No different than outsourcing bits to a bad satellite office.
So are you actually good at finding the good juniors in this very difficult environment? Can you change your hiring machinery to improve, as most traditional ways have stopped working? Because hiring a lot of juniors that don't work out sure can kill companies.
Hire one junior per team. Don’t overload your senior staff with OKRs and managerial tasks. Let mentorship and apprenticeship happen.
I guess what’s the value of the junior there? Why is that superior to just having the seniors have their heads down coding and not being pestered by a junior?
There are a lot of projects that involve very little of high level experience and a lot of grinding things. Juniors can be very good at these, and there are probably enough micro-problems that aren't critical that their brain is still being used and they're gaining skills that will help them take on more complicated tasks.
Something I last worked on with a junior engineer was our in-place backup system. I designed it and wrote the tricky part that involves DLL hell in a docker container. He wrote the "list backups", "delete backups", "create backup" CRUD API and CLI. My time was then free to put out fires or design something new.
It's not necessarily a no-brainer to hire and mentor junior engineers like the article says, but it's something you should think about. You will be surprised how much people actually know at job #1, and how quickly they can take on more complicated work that pays back your time investment in their mentorship. Plus, someone probably trained you to get you to where you are today, so there is some fairness in continuing the cycle.
What do you do when your seniors move on or retire?
Also, even seniors are usually more than happy to outsource work they've already done a million times, but that's still new to the junior ("build the Terraform to stand up this cluster" etc).
People only average a few years in a job these days. The juniors are most likely to end up as seniors somewhere else. So hiring juniors who provide negative value at the start is mostly benefiting the industry as a whole at your own personal loss. Which makes it a pretty easy thing to cut.
I know in other industries they have a kind of lock in where they provide free training under the condition that you work at the same company for a number of years. Which sounds bad but I don't see many alternatives.
Then operate as a manager, leader or company that people don't want to quit.
If people are happy, paid well, with regular cost-of-living raises at minimum, with upward mobility, helpful and useful managers and interesting problems (doesn't have to be an interesting domain. The problems themselves just need a bit to chew on) and the latitude to solve them and grow
They're not as likely to leave.
> So hiring juniors who provide negative value at the start is mostly benefiting the industry as a whole at your own personal loss. Which makes it a pretty easy thing to cut.
That's true, but why are you qualifying this with "who provide negative value at the start" in the first place? What if you hire juniors who provide positive value at the start instead?
But you too can hire seniors in the future who were juniors trained "somewhere else". This is the kind of shortsighted selfishness that's ruining most things.
Obviously it's selfishness, but it's a prisoners dilemma where the you just lose if you are the only one training the juniors who then move on to the competitors later.
So motivate them to not move on to competitors. I don't think companies should cynically take it as given that people only last N years, and will leave for greener pastures once they're trained. They're leaving for a reason, so address that reason.
I believe the reason is often not a company problem, it's a variety problem that nothing can solve.
It's a totally unavoidable problem with our industry.
People get bored working on one domain, one product and one codebase.
And most software shops have one domain, one product and one codebase.
I have quit a dev job exactly one time, when offered a salary the first one wouldn't meet (the HR person straight up told me she didn't understand why they would pay me $80k in the exit interview, this was like 6 years ago). Since the second company pays me well (with benefits), gives me yearly raises, and gives out generous performance based bonuses, I haven't looked for another job since then. And yes, job #2 is often boring.
It's pay. It's always been pay.
> It's a totally unavoidable problem with our industry.
It's the pay.
> People get bored working on one domain, one product and one codebase.
Yeah bullshit. It's the pay.
Give them decent pay increases and I'll guarantee you they won't leave.
People can leave for a lot of other reasons than money. You can't control or predict that.
I mean I agree with hiring juniors. I try to push for it as it’s how I got into this industry but it’s a bit of a prisoners dilemma right? It’s best for everyone if we all hired and trained up juniors but one could also defect and only hire seniors.
Besides most companies won’t last long enough to worry about senior talent drying up.
As an industry we can't just cut off the pipeline of future senior devs.
This is the fundamental contradiction of LLMs. The promise today is that the tooling can largely replace juniors, and honestly that may be true.
The hope behind that promise, though, is that the tech will catch up with senior devs before the pipeline dries up and that we have found a sustainable social and economic model before humans truly aren't employable at any meaningful numbers. That hope seems ill placed to me, but I guess we'll see if we develop such skilled LLM or similar tools at all.
The problem is that if everyone hops jobs every 9-18 months, it’s not worth training up juniors because the employer will never get to benefit. It seems that we’re in an unfortunate, but stable equilibrium.
This has been the state of things long before LLMs, and companies still hired and trained up juniors, only to see them leave after 18 months.
But that's fine. The junior you trained up will be more effective at their next job, and the junior your competitor trained up will be more effective when you hire them at your company. Again, that's how it's been for far longer than we've had LLMs.
Junior devs are just a time suck though. They do require more on boarding an attention than the average experienced hire, but they also bring a different view to the project. I've been surprised over the years by juniors that raise a question or idea that snowballs into a pretty fundament and impactful change, one that could have been raised before but the team just didn't look at it that way.
We also have to remember that if our juniors leave 9-18 months later, everyone else's juniors are leaving too. Churn has a cost for sure, but if I can hire someone else's junior that they put 18 months into then I am still better off.
> The problem is that if everyone hops jobs every 9-18 months, it’s not worth training up juniors because the employer will never get to benefit.
It is absolutely worth hiring and training juniors. The quality of your onboarding process and documentation will improve. Not only that but a junior will ask questions that senior engineers take for granted, such as "why are we doing X this way?" which can lead to improvements that your existing engineers might not have considered.
Finally, if junior engineers are joining your organisation and leaving every 9-18 months, you need to take a serious look at your career progression ladder and compensation. I have seen way too many companies that have an arbitrary "you cannot receive a promotion in the first X months" HR policy which is just asinine. You know who doesn't have this stupid policy? The company your junior just accepted an offer from.
If your organisation doesn't have the tools and processes to up skill junior engineers into seniors, then it doesn't have professional development for senior engineers and is just a career dead end.
You're saying the industry, or society in general will suffer. That's an externality. People and organizations optimize for their own profits, not net social benefit.
Sore, totally agree. I'm not saying I expect a corporation to care about externalized costs.
I am saying that I care about them, and individually we all should pay attention to them. In this case, I will continue to push for juniors even if my higher-ups push for us to hire seniors only and augment our workforce with LLMs for more junior-level work.
Teams are not equivalent in the big or medium org. Some teams are pushing the boundaries (for the corp), some teams are doing grunt work, some teams are doing maintenance, some teams are support for all of those etc. Example - in our company it is often a case when a junior is hired to do lab support or general support, then transitions to a QA team for example, or a junior QA is hired to a steady working team and then transitions to a team doing fire requests and more visible stuff. In the process he acquires both general seniority and a lot of hands on domain knowledge which is complex in our case. Hiring a senior often means skipping only seniority growth, while he still needs a lot time to learn the domain and local quirks. I assume that averaged over years, juniors are still valuable par cost spent. Plus, juniors are sourced from the different pool of people than seniors, meaning more opportunities for a good hire.
Because the junior grows into a senior in a couple of years and the company is better off for it
That's fine if you can compensate them accordingly to retain them, but if you're going to pay them senior level in a couple of years, why not just hire a senior level to begin with?
Because highly experienced seniors are rarely on the job market.
>The great software developers, indeed, the best people in every field, are quite simply never on the market.
>The average great software developer will apply for, total, maybe, four jobs in their entire career.
>The great college graduates get pulled into an internship by a professor with a connection to industry, then they get early offers from that company and never bother applying for any other jobs. If they leave that company, it’s often to go to a startup with a friend, or to follow a great boss to another company, or because they decided they really want to work on, say, Eclipse, because Eclipse is cool, so they look for an Eclipse job at BEA or IBM and then of course they get it because they’re brilliant. [Replace Eclipse with $HOT_TECHNOLOGY, like AI agents this year.]
>If you’re lucky, if you’re really lucky, they show up on the open job market once, when, say, their spouse decides to accept a medical internship in Anchorage and they actually send their resume out to what they think are the few places they’d like to work at in Anchorage.
>But for the most part, great developers (and this is almost a tautology) are, uh, great, (ok, it is a tautology), and, usually, prospective employers recognize their greatness quickly, which means, basically, they get to work wherever they want, so they honestly don’t send out a lot of resumes or apply for a lot of jobs.
- https://www.joelonsoftware.com/2006/09/06/finding-great-deve...
Most of the best programmers I know have worked 2-3 tech jobs. An internship or entry level job, a cushy job at a major company, and either retirement or a third job that they took because the problem was incredibly interesting and they got nerd sniped. I even saw the "medical internship" scenario happen once; a great colleague of mine had to move to France for his partner's career in medicine, so he quit his job and found something over there.
This might be true if you are looking for some top 0.5% talent to solve the cutting edge most difficult challenges in tech, but for the vast majority of companies building basic apps and saas products, there’s a large pool of talent to pick from.
Most companies aren’t Apple, Nvidia, or Google chasing the top 0.1% of “elite” talent. Outside of a few AI-focused startups, the reality is that 90% of companies are sitting on legacy codebases, still running VMs, or duct-taping CRUD apps together with APIs.
If you happen to be a superstar with a rare niche skill (like building frontier AI models), you basically skip the interview loop and get fought over with million-dollar offers. But that’s a tiny fraction of the market.
For everyone else, hiring looks a lot like dating: both sides aim for a “10,” but usually settle for a “6 or 7.” And the whole process is signaling—candidates overstate their skills, companies oversell their culture and tech stack, and the match lands somewhere in the middle.
Probably the most important non-technical skill is dealing with the egos in the industry since you will come across a lot of them.
In my experience hiring, its not just the top 0.5%, more like the top 30-50%.
I think HN's demographic skews young and commenters here vastly overestimate how many of us are constantly job hopping every 3 years.
Yeah especially as you age the healthcare policy can become as important as pay. Have known plenty of people who got most of their value from health benefits + stock plans rather than the base salary.
People aren’t fungible. The senior engineer you’ve trained for a couple years is way more effective than the one that joined yesterday.
It's a hiring pipeline. You're growing modestly underpriced internal talent that, in the upside case, has skills that front-run their salary by a bit. NB: I'm obviously not advocating for underpaying people; just noting that that good junior eng will grow fast and their salary will take time to catch up.
It's stupidly expensive though if you look at the opportunity cost of that already-onboarded senior/lead/staff eng time. And this was obviously more compelling when it was super hard to hire senior talent.
Good juniors are cheaper and faster to find. A REALLY good junior will jolt your seniors awake with professional competitiveness as the junior starts finding ways to make a name for themselves - or even just a fresh pair of eyes on the app, new ideas, more familiarity with newer paradigms and technologies.
> Let mentorship and apprenticeship happen.
There has never been an apprenticeship model where one apprentice is trained by several masters. It's always the other way around.
Said with such conviction, yet so wrong. Ask any "non mcdojo" kung-fu school if they consider training under a single master to be sufficient.
In what sense do you believe that's an "apprenticeship"?
Apprentice is:
A person who is learning a trade from a skilled employer, having agreed to work for a fixed period at low wages.
This fits the bill at leat in the MA "training programs" that I'm aware of, but again I'm not training at overseas dojos.
We hired a recent graduate with little directly relevant experience, but a passion for Capture the Flag challenges. Showed a lot of initiative and curiosity for learning new things.
Has been a great, self-motivated hire who has found problems to solve and led the effort for solving them, resulting in saving our company a lot of money.
> Hiring juniors is always great if you, somehow, have a much better filter for finding the stars than the rest of the market. But if you don't, hiring bad juniors is a disaster: No different than outsourcing bits to a bad satellite office.
This isn't some absolute innate talent thing, though; it's very much a learnable skill.
Especially because output and time-to-ROI for a new hire depends on the combination of all of these things: (a) interviewing/screening, (b) onboarding, (c) ongoing feedback.
It's not a zero-sum game, it would be entirely possible for the industry as a whole to get better across the board at those things - especially since one job's "rockstar" is often another job's unmotivated thinks-they're-the-smartest-person-in-the-room burnout, and vice versa.
Check out the bit about the hiring process, particularly about filtering for the right mindset.
As someone who has been hiring juniors recently. I disagree with pretty much all these points:
Great juniors learn fast and search for feedback. It’s easier to manage them. They want to improve and know what you think about their work.
--> Very skeptical of this comment. It's harder to manage someone that needs managed so directly, period.
Loyalty. engineers who you train from the beginning tend to stay longer. They understand your systems deeply and can mentor the next generation of junior engineers.
--> They really don't. They're looking for a foot in the door.
Higher ceiling. A motivated junior engineer often has more upside. You're getting someone at the beginning of their growth curve rather than the middle or end.
--> Maybe? Tough to tell. They often leave.
Juniors bring fresh energy to the team - they want to learn, and they have a drive to prove themselves and succeed. Their motivation can be contagious! The existing seniors in your team will enjoy working with smart and motivated developers.
--> Not always. Most just want a job and are easily discouraged. Some are like this though.
Juniors are not restricted by what they know. They haven't been trained to think "that's just how we do things." They’ll not try to reuse the same technologies from previous companies, or recreate those ‘amazing’ design patterns that were useful only in a specific context. It’s not just being AI-native, it’s about having less resistance to change.
--> This one I sort of agree with
The point on loyalty made me laugh out loud. Loyalty has been dead both ways for over 10 years now. Millenials and Gen Z openly shared salary to help each other get more money. An average tenure at a company went from 2 years to 1 year as well.
The idea that juniors are somehow more loyal is a pipe dream and a bald faced lie. Not that I blame them, employers have gotten much worse in the last 10 years as well, especially since the pull back in 2022 and most especially since AI. So neither employer nor employee is loyal anymore it’s completely a free for all now.
I guess I'm lucky in having had a chance to work for several fantastic companies that treated me wonderfully for years and years.
And we also raised up juniors, and paid them well. And our company had flat salaries, so everyone could easily figure everyone else's salary (and people didn't hide it, in fact we talked about it all the time).
Again, treat your employees well, and they'll stay. Places *do* do this. And people *do* stay loyal and even come to companies because they hear how well they treat their workers.
I count myself lucky as well. I've been in a few great places. Also stuck in tolerable places for 5-10 year stretches because it's a paycheck.
Sometimes people leave (for money or variety) but come back, because they realize other places were worse (despite the money). Sometimes they don't because they're afraid or tired. It varies. But yes, people often walk away from places that either treat them badly as a company or because they have coworkers that treat them badly. The reputation tends to stick, too, even though it doesn't often spread very far.
> Maybe? Tough to tell. They often leave.
In my experience working with juniors, the ones that look to leave are the ones that don't have their compensation appropriately adjusted as they rank up.
Pay everyone well, treat them with respect. Challenge them, and give them raises and rank-ups as they gain tenure and skill (not when it's "in the budget, and oh sorry, we can only uprank one this year, but we hired a person at the higher level, so really we can't afford it. Try again later!"), and you'll have people that stay a long time
If you're going to end up having to pay these people high salaries, why not hire a more senior person to begin with?
Because over 10 years, you'll have attrition in your seniors as they retire and you'll have juniors that have climbed the ranks and have built half the systems that are now juniors replacing them.
And treating employees with respect the whole time builds an *incredible* amount of loyalty. You also get opportunities for your existing seniors to help grow new team-members, which some of them seek out, and so on.
> The existing seniors in your team will enjoy working with smart and motivated developers.
Maybe I just suck, but as a senior I've rarely enjoyed working with junior developers, even the earnest ones who really wanted to learn. I always had a ton on my plate, and mentoring juniors didn't replace anything from that ton of work, it just added to it.
And yes, I get that mentoring juniors is useful and essential. But companies need to build that into the job, not build it on top of the job.
I’m not sure where they’re getting their data about companies not hiring juniors.
In 2021, 104,874 CS students graduated—the highest number ever [0] (1.5x more than the 4 years prior). But the job postings 2022-2025 have certainly not maintained that trajectory.
If the number of graduates keeps climbing while the total number of jobs shrinks, then naturally more new grads will struggle to find work.
Playing devil’s advocate: some “senior” folks may now be competing with juniors, since they’re willing to take lower titles or pay just to stay employed. I’m not sure how much that actually shifts the market, considering companies famously don't hire overqualified people and tech workers face age-ism risk.
[0] - https://nces.ed.gov/programs/digest/d22/tables/dt22_322.10.a...
My final stretch of employment lasted from May 2020-March 2024. My company went through mergers and acquisitions and 4 rounds of layoffs, and I managed to tenaciously hang in there (I was even "terminated" 4 times but they just kept re-hiring me!)
I was definitely competing with entry-level kids who had just graduated, even those who had just graduated from the boot camps we provided. And I was hired with no college degree, no certifications, and nothing relevant on my résumé since 1999. So yeah, I got minimum-wage treatment.
It was a fantastic, cushy WFH job. The parameters were ideal for my style. The supervisors were very, very patient and encouraging. I was a rock star, if I do say so myself, but there were plenty of competent colleagues who had plenty to contribute in the same role as me.
Eventually I earned 3 certifications and a college completion certificate, and that made zero difference. No raises, no promotions, no acknowledgements of my achievements from my employer.
So, college isn't all it's cracked up to be. Yes, seniors are competing with juniors and entry-levels. It's fierce. Be the best and do your best, and don't be reluctant to settle for a good employer.
Sadly, WFH is de facto dead unless you want to compete with Parul in Pune, Pavel in Prague, and Peter in PEI.
If anyone wants to be justified getting hired in this market and not be offshored, they will need to be in an area with a large density of tech jobs in order to find the next opportunity to land AND go into the office a couple days a week.
Genuine question: What does "PEI" mean?
A quick Google search is turning up "Prince Edward Island". Is Prince Edward Island known for being a place with a lot of remote tech workers? (Like, this doesn't _sound_ right, but I know next to nothing about Prince Edward Island :) )
Prince Edward Island sounds a _great_ place to work from home!
Source: am WFH in remote farmhouse in Scandinavia- with fibre.
No, PEI does not have a lot of remote workers. AFAIK the main provider of tech jobs there is government in various forms, and they mandate several in-office days per week.
It's just a place that is geographically disconnected from the mainland, and it rhymes.
Source: I work with some people from PEI.
>> Parul in Pune, Pavel in Prague, and Peter in PEI
Nowadays they also have a push to RTO to local offshoring center.
Managers are managers everywhere and want to see their slaves sitting in order behind their desks.
The biggest hiring hack for junior engineers is to hire the ones that have already been programming for a decade, and are called "junior" because they recently graduated university.
The junior/senior language is corporate-speak to equate everyone's value to "years of service" in industry or at a company. Obviously that's not how competency works, and if you are serious about hiring competent people, you should mostly ignore it. It's useful for listings, it is common terminology after all, but it's not semantically or descriptively useful.
This is a positive signal, but doesn't necessarily tell whether the person has intellectual capability to write "proper" code or just had some opportunity at the early age to be exposed to programming.
I have seen good and bad engineers who had been programming before graduation. Fortunately, good ones outnumber the bad ones.
Yea experience is very useful (it is very hard to exert influence without power and be the tech lead of a team unless you have some corporate experience) but at some point one needs to realize that if someone was writing Haskell at the age of 12 and they got decent scores at USACO they would make quite a decent engineer...
Along the same lines of missing good junior engineers at work, we occasionally interview stellar engineers that’ve inflated their resume a bit to get an interview, but we end up rejecting them for not having all the specific experiences our manager wants them to have even though they’re generally great and could clearly upskill where necessary. No wonder we can’t grow the team when we’re out here looking for unicorns
Employers need to get back to expecting to have to train new employees. This used to be pretty common. My first two employers after college hired a lot of people with no programming experience into programming roles. They just looked for smart people who were willing to learn, and they taught them to program.
Boot camp level skills are dead now - deeper grounding in CS is a requirement. With the 2022 hiring boom over and AI taking on some of the work, the junior market has more competitive, and will remain so in the foreseeable future.
My advice to new grads, students, and other juniors is to find any way to get real-world work experience. The pay for these roles may be lower, as higher salaries are increasingly reserved for senior-level engineers.
FOSS software is any other place to build skills and value until you land paying roles.
> My advice to new grads, students, and other juniors is to find any way to get real-world work experience. The pay for these roles may be lower, as higher salaries are increasingly reserved for senior-level engineers.
This is just sound advice in general. A good professional analogue to recommending a junior college as a stepping stone to a university.
No one cares about FOSS experience. You’re lucky if they even visit your GitHub/Lab/Berg at all and even luckier if they look at anything past your heatmap.
Fact is, if FOSS experience counted for anything, then those charged with hiring would also possess the capacity to understand that C# and Java experience are nearly 1:1. Sadly, it doesn’t and they don’t.
As someone who is very experienced primarily as a C# dev, I wouldn’t say Java is “nearly 1:1”.
At a syntax level they’re practically the same and they both use GC, but in terms of ecosystem they’re very different.
It might not seem like it to people who are just starting out at programming, but syntax is probably the easiest part of it.
Sure, I would probably be productive in Java if I had to start using it fully tomorrow, but it would take me months or years to get that same nuanced knowledge of its ecosystem to be as effective with it as I am with C#.
That's actually good news in a way because boot camps were so surface level and we didn't get a lot of actually good developers out of those programs, just lots of arguments by people defending ideas that weren't well-founded.
I was confused by why "use of AI" was a top-level requirement of this, but I see now that weave is AI-driven "engineering output measurement" company, down to the individual contributor level.
I can understand why you would have better luck hiring eager new-grads than seasoned engineers. I'm sure some IC find the weave stats useful, but it also sounds like a toxic manager's dream. I can understand why more senior engineers would steer clear.
Here are some real open-ended questions you can use to see how well a junior hire with no Industry background will do.
* Test whether they understand data types and abstraction. * You have a function returning two numbers in <your favorite language>, how will you do? * Now you need 4 items from this function called getUserInfo(), how will you return it? (Eg: username, email, location and age). * You need to share some state between two calls to this function. i.e a database connection. How will you do it? * Now imagine multiple threads / requests call this function. how will you share state?
And so on..
r/CSMajors types who have done only leetcode will fumble this kind of open ended discussion.
Similarly for networks
* Google "my IP address" from your phone?
* Is it really the IP address of your phone?
* There are more than 4 billion mobiles + computers on this planet. How are they getting unique IPs then?
* If you run your school project (likely to be django or express js app), will you be able to reach it from another phone or desktop using this IP?
* Why or why not?
These are kind of things they should be able to answer if their networking / OS etc... classes were any good.
My comment will focus only on a subset of the article: the part regarding AI.
While I agree with the sentiment that AI has changed the practice forever, and therefore it is pretty silly to forbid AI during interviews (much like it was always silly to me to forbid a candidate from googling something during an interview), I haven't really seen evidence that juniors with AI have faster onboarding times.
Onboarding, to me, is about having the new team member adopt the existing team's practices, such as learning preferred code patterns, communication channels, established frameworks, and overall just getting to truly be a part of the team (tech and non-tech team).
In that sense, AI has done very little to help. If, on one hand, AI can help us produce better documentation that will help with this process and studying existing libraries and practices better, on the other hand, AI also enables a new team member to seek others less early on (a point the article itself makes), which I believe makes the onboarding process (according to my definition) slower — i.e. less communication = slower onboarding.
As I mentioned, we can also relate onboarding to getting to know the codebase, in which case AI definitely helps (and as more code is written with proper AI engineering practices, it will help more), but I really feel that this is a small part of the equation.
Similarly, I think getting to know the actual domain of a project (the users, the requirements, the 'language', the problems, etc.) is an important part of onboarding and, again, AI helps here, but not a whole lot. It's about people, not bits.
Sure, if you hire a junior to get him to work straight away on a new project, the new hire will be "productive" faster (therefore seeming to have been "onboarded" faster) than before, because the AI does make them "go faster" than before, but I wouldn't say they were _really_ onboarded.
Perhaps it's just a case of a different culture, a too-rigid definition of "quality", or just a different set of workplaces, but this has not been my experience at all. Most junior hires take at least 6-8 months to produce code with our standards of quality without a decent chunk of supervision. Even a junior with a very solid capability to think the system as a whole has a tendency to over-engineer or place code in the wrong places due to inexperience, which definitely affects their productivity.
The blog post is an advertisement for an AI powered employee stack ranking company, so it makes sense that they're shoehorning in AI even when it doesn't add to the piece.
Orthogonal comment here but “onboarding” has always struck me as weird. I’ve only had 3 tech jobs in 15 years and may not need to get another one, but at every one I just showed up on day one and started doing things that people asked me to. Clone the repo, run it locally, deploy a change to dev, poke around at it, read some docs, do a little refactor or comment on other people’s PR’s. There is much to do. I don’t get these people who show up and like.. don’t do anything. Even if you do something dumb and have your PR ready for review EOD it’s all good. I have never seen the effort that goes into these mountains of onboarding docs that some of my coworkers have pay off, I just pair with the new people and we solve things and they learn.
The gap between juniors and seniors today is really not that big. I know a lot of people with senior in their title that are closer to a junior. Have them actually read the docs for a month straight, and a junior would know more than a senior.
Also, if you really want to hire a senior, and you can't compete on pay, maybe compete by going remote? Almost all the job listings I see are for hybrid roles. Do they realize they're just throwing away all the candidates in other cities? Are hiring managers/CEOs masochists?
Yeah see this all the time :(
Senior is often about time in industry not competence. A lot of 'senior' engineers are completely ineffective and seemingly unable to ever become effective. They just joined the industry a while ago and are treading water and tricking the next hiring manager that they were called 'senior' at their last job so of course they are a 'senior' now. If they aren't applying for 'staff' level jobs.
The correlation between being smart, getting things done, speeding everyone up, being trusted etc and 'seniority' is not causal :)
I might have agreed with you on remote work before Covid, but the difference in productivity from my team that stayed remote after Covid, and the hybrid one I joined afterwards was almost impossible to believe.
That's the team, not the location. Take your hybrid team and move them remote and they'll perform the same.
For a few months they will, but the innovation, problem solving and creativity that happens in person just can’t be replicated online and it’ll eventually drop off.
I hope you’re not arguing for remote, in a non-tech hub city, but only in the US. If I thought remote individuals were as productive as in person, there would be no such thing as “remote but not too remote”. Canada is cheaper than the US and has American English speakers, if that’s important to you. LATAM is in the US time zones and is cheaper again. If I didn’t care about time zone offset there’s almost unlimited options for offshoring at a fraction of the cost of US labor.
I wonder if an AI wrote this. It seems to have all the hallmarks.
1. It's not just x - it's y.
It also reeks of lower pay propaganda. Shallow nothing points with AI can make juniors almost as good as seniors.
looks that way to me. However, that isn't necessarily a bad thing if a human reviewed and guided AI to get the article they want.
I can and will judge anyone who can't write a few paragraphs on their own
if I wanted to read AI text I could have just prompted it myself.
If I wanted to implement the next Twitter, I could have just vibe coded it myself.
> How to hire the right junior engineers...
The advice given doesn't just apply to junior software engineers, but also senior. It's pretty much how all the senior engineers at my company (including me) were hired.
While I found the process heavy as a candidate, it did seem to select for like-minded and similarly motivated co-workers.
That said, the company has also hired several university interns through a similar process, and they have been great co-workers.
Author here, great to see all the conversation & thoughts you all have shared so far!
One thing I've seen a lot of people saying: hiring juniors isn't worth it because they'll just leave for more money in a couple years.
I got hired with 0 experience for my first job and stayed for 3.5 years (I left when I decided to start my own company). I was otherwise never tempted to leave because I got all the support and growth opportunities I could have hoped for, and I always felt fairly compensated.
So based on my own experience, it's possible for a company to treat people well enough that they won't just leave. I do think software companies tend to be bad at this specific thing though - I'd imagine many have had an experience unlike my own.
From my experience, junior's tend to churn out after around three years. There are often factors that go beyond whether they felt they were treated well. Looking at it holistically, younger people tend to want to move around more. It is no surprise to me that the average tenure of a junior employee is about the same length as a degree - separating life stages in to 1-3 year periods is a mindset embedded into young people throughout their education.
I would wager that perception plays heavily into this too. It can be difficult to shake a perception of "being a junior", especially when the path to seniority is unclear or poorly defined. Plus, the "two years and disappear" ethos of job hopping for quicker compensation capitalises on companies' conservative promotion criteria (and more liberal hiring criteria). Loyalty is rarely rewarded in these cases.
In small startups - “we are a very small team and we don’t have time to mentor juniors, we need engineers who will be very productive from day 1"
In medium-sized companies - “we are going to grow very fast, we need engineers who can handle scale and have faced such challenges before"
In big companies - “our infrastructure is super complex, it’ll take juniors too long to ramp up".
Seeing things like this, I pretty much always hear "We don't know what we're doing and want to find someone who does and will make us make money fast".
Remember Joel Spolsky' guide to hiring [0]?
1. Smart
2. Gets things done
[0] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
> Look for passion and curiosity. You want the ones who light up when talking about their projects. They should show real excitement about the problems they've solved. These conversations should be energizing for both of you!
Interview prep tells candidates to fake "passion" and (now) "curiosity".
(The prep materials don't say to fake it, but they will phrase it implying that that's the truth, and that it's something that interviewers look for. The prep might give examples of when to be sure to "convey your passion", such as when discussing a project you worked on.)
The net result is that interview prep materials, and companies that select for that, end up selecting for people who will go through the motions of appearances. Which is OK if you are a stodgy huge company sitting on its laurels, that wants everyone to be a compliant worker drone, more than they want excellence. Not OK if you're a startup that really needs to execute with more than worker-drone capabilities.
Maybe an interviewer seeking genuine "passion" and "curiosity" would be better off giving points to someone who seems to have skills but didn't seem to have done interview prep, since they must have gotten that far by being genuine and non-drone?
If you keep asking questions eventually you hit something they don't actually know. How long it takes to get there + what they say when they get there is what makes this interesting imo!
Not very long ago, the real reason smart managers, in consulting firms, hired juniors by boat loads, though they are not very skilled, is because the young staff has other compensating qualities.
The work these companies had was quite irregular, unstructured and unexpected as well. This demands a workforce that is very flexible, work over nights, can learn fast, can switch to any work easily (they are not stuck to a single kind of work role). Juniors wore many hats easily as situation demanded (faking included). They are also very mobile, can travel to a client site in any country. Most of them are singles. Feed them, do team outings, reward them and give gadgets (my team got first version of iPods free). They would give 50 hour weeks plus weekends. They hardly have any life outside of office. Sometimes they slept at office.
Also, the young workforce has a high team-bonding nature (romances included, intentionally). This makes them very good team players. What a manager means by "team player" is, they work for team goals, with poorly defined roles and tasks, without complaining.
There were a few seniors who review and guide the work, but the bulk of work was done by very mediocre, hard-working junior staff. When things go wrong, managers are ready to do crisis management and shuffle their young worker crowd across teams.
In other industries they are called MSGs: multi-skilled-gangs. These are very fluid work force. They don't know what kind of work will assigned to them on a certain day. It can be anything, from taking a support call, arranging lunch or pub party for the team, writing some html, testing some UI, giving a presentation to clients.
Undefined work requires undefined roles and employees that aren't yet married to certain work role, life style, or other person.
This has been driving me crazy, at my mid sized company, higher management insists pretty hard in only hiring senior/staff. But to be honest we are far from solving novel, challenging technical problems. Inevitably we hire (expensive) super senior people who end up having responsibilities that do not match their level in tech and also in product. The good ones that want a challenge leave after ~1y. Junior or mid level would be a better fit in many cases. When I look at the job descriptions I find them ridiculously inflated in terms of expectations compared to what actually happens in the company. In the past when we hired junior, mid level engineers they ramped up pretty well, their salaries went up and they are still with us.
> When I look at the job descriptions I find them ridiculously inflated in terms of expectations compared to what actually happens in the company.
At every company at work to, each time there was openings for the team I worked in, I read the job descriptions and I was like: "I would never apply for this position, I'm not qualified".
So I asked HR to lower the expectations, otherwise we would never find candidates. They told me that it was to avoid inexperienced people to apply. And then 99% of the candidates they pushed and I interviewed lied on their XP.
Good stuff!
Not mentioned in the article : interns/juniors are too expensive these days ; seniors offer better value per dollar of comp.
Why not just pay them significantly less than seniors? if there is a surplus of juniors shouldn't the invisible hand of the market adjust the salaries accordingly?
The invisible hand of the market is playing games with promises of AI allowing one senior to do the work of a senior and 4 juniors.
Whether or not it works will be something we find out long past the early-experience tenure of those junior engineers.
Anectodally, I've seen that some newly graduated engineers prefer to forgo the job search altogether, rather than lower their comp demands to get a foot in the door.
Depends on what you think the cause is. They can’t work for $20 a month legally in most cases.
This article feels a little suspect. They beat the AI drum a bit hard. So I go to https://workweave.dev and of course their business model is tied up with LLMs.
I’d buy this argument but for heaven’s sake don’t rest your argument on what Shopify might be doing.
Shopify has famously done everything and then the opposite for the past 5 years.
They’re highly opportunistic in their messaging and marketing around hiring and what they publicly reveal there is better seen as propaganda than an indication of their actual hiring approach.
The thing is its much harder to higher a good junior dev. With a senior dev i can ask about the [hardest/most interesting/thing you would like to talk about] bug and talk through how they solved it to understand how their brain works.
With a Jr you basically need to spend an hour pair programming to sus out the great ones and no one has yet put in the time to filter out the bottom X0%.
We just lost our 3 summer interns and now I had to take over one of the projects from one of them. The code was a bit messy, but holy crap did they get a LOT done in 3 weeks. Just finished fixing it up in 2 weeks, but if I still had him, he would have done all the fixes in less than 4 days. He was twice as fast as anyone here.
Why do these blog posts always assume that utilization of AI makes employees faster at coding when the opposite has been proven to be true?
I think you are making the same mistake. Nothing of the sort has been proven conclusively in either direction.
When companies hire more senior engineers is the quality of software produced increasing and delivery time decreasing?
It's a good time to see if bodies or experience matters more.
Tragedy of the commons. People will prioritize selfish, short-term gains by taking from a finite pool of resources at the expense of long-term sustainability for everyone.
Junior engineers should spend half their time doing customer support.
It allows them to provide meaningful value to the company without needing to code, it shows them a customer first approach to the product, it teaches them empathy for users and the CS team. It also teaches them repro/debugging skills.
> We focus on system design, architectural decisions, and reasoning through trade-offs.
Are we still talking about hiring juniors? I hope I misunderstood and it's not about "design messaging app" type of questions. Otherwise we're firmly back in the Leetcode land.
> "[...] it’ll take juniors too long to ramp up"
I think unsaid about a version of that belief is "... and, after expensive ramp-up including mentoring, they'll probably job-hop for a better salary, or better company, before the company sees payoff."
It's not just latency on payoff, but risk of any payoff at all.
> “...interns bring [...]"
"...a relatively low-cost way to evaluate a candidate hire, and then, if they show promise, you have their attention to make them an offer for a real job."
Given how hard tech companies find vetting candidates (e.g., many still cling to Leetcode and what school someone went to), and the demands of post-ZIRP on effectiveness, interns (and expecting to spend more on mentoring than the interns produce in value) are one solution for finding good future junior hires.
I hope this happens quickly. These companies that use only AI should be devastated.
We love hiring junior engineers at https://yuzu.health/careers.
Please apply or reach out to me over email: russell@yuzu.health.
Oh hey I work for an (old fashioned) TPA. I need to get some sleep but I might check this out tomorrow.
Hiring too many junior engineers is killing companies...
...although this is a fault of management, not the juniors. I've seen the following at two companies:
- Large, complex codebases
- Management hires a bunch of juniors because they're cheaper
- The juniors "move fast and break things" and write a lot of extremely high tech debt code
- Management, lacking the ability or will to understand tech debt, think these juniors are productive because they see short-term productivity but cannot understand the medium- and long-term ramifications
- The juniors, not knowing better, don't realize the damage they're causing (again, not their fault)
- At some point the juniors outnumber the seniors and the lunatics are running the asylum. (More politically crafty seniors utilize this to their advantage and cultivate fiefdoms of juniors)
I am of course speaking in generalities. There are amazing juniors and terrible seniors. I have been in this career long enough to see the same things over and over, so I stand by my generalizations. However... I have also seen enough exceptions to know that you can't judge pre-judge any particular individual by "years of experience" or any other metric.
I mentioned why this is happening in a previous comment on HN [0].
I can't justify spending $120k or more on base salary for a new grad who lacks table stake skills becuase a program like UCB or MIT (let alone much lower ranked programs) reduced the requirements for fundamental theory and OS classes, offered the ability to take padded classes to bypass requirements (look at Cal's BA CS requirements in 2015 [1] versus 2025 [2]), or offer the ability to take these classes pass/fail thus reducing the incentive to study.
Sadly, Bootcamp grads also soured an entire generation of hiring managers away from nontraditional hiring. Screw you YC for enabling predatory programs like Lambda School (YC S17).
That said, I think an apprenticeship style program where a community college new grad earning $50k and gets a paid bachelors degree or directly hiring a bachelor degree new grad for $70k-90k while working would probably solve the issue. This is assuming those new grads don't meet the curriculum bar of the students they are competing with abroad. I think Shopify tried something similar and it worked.
I'm also not sure an "AI first" approach is the right approach unless you are looking for someone to manage generic CRUD type work (and that kind of work is a race to the bottom anyhow from a salary perspective). If I'm hiring a prompt engineer, then imo a Linguistics or Philosophy major (or any major where you are taught Structuralism) with a CS minor would probably be the best bang for your buck.
There needs to be coordinated reform in CS curricula, hiring incentives (eg. providing tax credits comparable to those which CEE, Israel, and India provide to attract FDI), and ease of doing business in order to resolve this crisis.
[0] - https://news.ycombinator.com/item?id=45413516
[1] - https://berkeleyguidearchive.github.io/2014-15/undergraduate...
[2] - https://undergraduate.catalog.berkeley.edu/programs/A5201U
You get the best bang for your buck if you just hire teachable people and fill the gaps that matter to you.
Sometimes teachability subsides over the course of your career: A senior I know has terrible git hygiene but is so close to retirement, he simply won't change. But some juniors I've mentored have significantly improved their ability to compose an atomic commit with a quality commit message, and are now valuable team contributors.
Even the core concepts of your CS162 course are easily within the grasp of a CS major from a less rigorous program; you could assign some required reading as part of your onboarding process if missing these concepts would prevent them from thinking critically about problems in your org.
I can't justify paying a junior engineer $120k-140k base salary to train them in OS fundamentals over several months in an industry as competitive and commodified as cybersecurity when competitors in Israel, Czechia, Poland, and India are able to hire experienced engineers at a lower dollar amount than a number of junior engineers in the US expect.
This is why the majority of startup activity in the space has shifted to Israel, the CEE, or India with a nominal American HQ hosting a CEO, CRO, and sales reps.
And this is the issue - we live in a globalized world, and a large portion of junior engineers in the US do not have the skills commensurate to the salary provided.
A business is not a charity.
Completely off-topic: How cool is that the headline text gets outlined when selected!
The technical term is “recession”
We don't hire juniors, just seniors. For juniors we do have AI. They have crazy ideas, like shooting sparrows with cannons. Eg using terraform for a setting up a static repo hosting website. Or kubernetes for a GNU parallel job.
Very ambitious, yes. Overly ambitious. It's called massive overengineering
The output of even junior mechanical engineers today would be considered mindblowing to the mechE's of 100 years ago, for similar reasons: computational tools have allowed an exponential increase in productivity.
Doesn't or didn't Netflix only hire seniors for a while when they were doing some of their most interesting technical work?
And shopify seems like an odd company from the outside.
Shopify experiments with hiring practices, and that's a good thing.
I've been following their program to recruit high potential high schoolers and have them work as junior SWEs while doing their degree part-time. I think this kind of a model is highly underutilized and would solve issues on both the hirer and the employee's end.
The issue is over the past decade, universities have dramatically reduced the scope of CS programs and removed foundational courses that have traditionally been gatekeepers to ensure some base maturity. Think like that theory of computation course, your CompArch course, or your OS Dev course.
Shopify had me do a timed test of multiple choice brain teasers. That is an odd thing to do...
I just checked the public school i went to and their required courses for CS include those that you listed
In Canada right?
Canadian programs haven't been watered down to the same degree as American programs and we can pay y'all 20-30% less than Americans.
If not, what program and year? The last few years of new grad hiring at portfolio companies left a bad taste in everyone's mouth so hiring shifted abroad.
Depending on the university in the US we might already be targeting them but then the cost aspect comes to play.
The real pro tip: hire someone with 2-3 years of experience
Another “here are the 5 easy steps to hiring a great engineer” post, said confidently but with zero empirical evidence that his techniques actually work.
There is nothing more useless than posts that purport how to hire effectively but offer no data.
Ok, which companies has it killed? At least one example?
many companies are walking corpses - see GE
GE today is not the GE it was 5 years ago. They have really paired down the company. They spun off finance, sold healthcare, and got out of energy & power. GE today is essentially just an engineering company in the aerospace sector, and they've paid down $100B of debt since 2018.
Today they're sitting on $10B in cash and do another $10B in free cashflow annually. Not very corpse-like!
And the sun looks yellow, but maybe back to the topic, is there an example of a company which was killed primarily by not hiring juniors?
Its like I asked of examples of burn victims and you told me "steve has the flu".
This GE?
https://companiesmarketcap.com/general-electric/marketcap/
https://companiesmarketcap.com/general-electric/earnings/
https://www.macrotrends.net/stocks/charts/GE/ge-aerospace/pr...
Certainly not in the top tier, but doesn't seem like it is at imminent risk of failing.
The pool is large, resumes don't differentiate => I have to talk to them to find the guy. I don't know how to do this efficiently. If you've got that skill, go right ahead. For my part, the rise in compensation has resulted in a lot of people who don't have any interest in the subject except as a tool to make dollars and they always run into dumb stuff like wrong documentation making them unable to act.
Yeah the kernel docs say one thing but the kernel behaves differently. Just look at the source. It's open source, man. Won't do it without being told.
If they don't care but will be persistent, fine. But if you can't work some basics, it's not worth it. And the correlation is near 1.0 because at least passion guy has something driving him to dig to next layer.
Inevitably some sucker will hire him, give him some on the job experience and then I can pay more.
Is Shopify a great company?
Stock below peak in a market giving extremely rich tech valuations. Canadian engineers hardly aspire to work there. Politics of the founders also seem to come up a lot.
This isn’t meant to be an attack but more an observation that it seems to be one of the companies getting killed.
To address the article itself, the argument isn’t juniors ca seniors, but juniors vs AI. Why is a junior worth paying 10,000x more than Claude? And it’s perfectly loyal, perfectly energetic, and can add its learnings to a contributions.md doc.
What makes a company great?
I think by most rational business metrics (top line revenue growth, gross margins, operating margins, cash flow, balance sheet), Shopify in 2025 is a fantastic business that seems to only be getting better?
This is notably different from an analysis of whatever the market price for its equity is or has been. I think that market price is ~40% overvalued today and it’s been much more overvalued than that in the past… but the fundamentals of the business have never been stronger.
In what way is it getting killed?
To force a comparison within the sector, is Amazon not a great company? Market price point aside, it’s arguably more politically charged and less aspirational engineering culture-wise. But I think I’d still call it a great company, same as Shopify.
I saw absolutely no compelling evidence to back up his thesis
While I'm deeply sympathetic to the original claim, I agree the evidence is lacking. All I really see is the assertion that AI means onboarding and coming up to speed is faster. Which feels a bit unproven?
(Unrelated but the post has a funny rhetorical thing where it says nobody is hiring juniors then also says if you don't hire then your competition will... But you already said nobody is hiring them?!)
hot take: covid killed a generation
If you were a junior in 2020 and right of the bat you were forced to work remotely you missed a great deal of learning experience. Or you had really bad time getting hired, at least up to a point, because business was booming.
Oh, and then you had that whole swarm of bootcamp graduates who thought they could cheat the system, get a degree in hello world and land a $300k job.
Back in 2013 I was making fun of job offers that would require 5-7y of experience in JS for a senior position. 7y of what? JQuery?
Same thing applies today. If someone started his career in 2001 I wouldn't even consider him if he had a job in BigCo.
Not sure why you're getting the hate. What you said is fairly accurate--there was a time period in which a lot of poorly skilled people were getting hired and that caused a lot of disruption inside of companies because you ended up getting all these ego-driven, writing checks their skills can't cash type of people. It was annoying as hell. I remember having a problem that was a slam dunk for using a state machine and this one guy argued against it because he didn't even know what a state machine was, but of course could not admit that to anyone. Anyways, he lost that argument, but why did we have to have it in the first place? Ooooh right--someone got hired as a Sr. Dev who wasn't really Senior anything.
Unsolicited advise, that's one thing I've learned about far too late in my life.
You know, if you have a brother or someone really, really close, and you're preparing for a wedding or a funeral, and they have a shirt that look absolutely ridiculous and you tell them that, they look at you, you match your eyes, and they trust you with their life. Well that doesn't happen in normal life.
Normally, what happens in ordinary life is you have a colleague that looks, smells or did something stinky, you want to be the good guy, you let him know and he's like "omg, he hates me, all hands to battle stations, that guy, aim that guy, he tried to wrong me!". And if he's slightly less on the spectrum than you - you're toasted. You're under fire, and there's no getting out.
And this happens every time you try to swim up the river in this current.
It takes 1 to 3 years to train new generic skilled grads on average.
A company initially typically loses $35k to $140k in resources to train a Junior to be minimally useful. Thus, most ponder if a hire is going to have a career long enough on a team to offset that liability.
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
In general, entry level gigs have a narrow scope of skills for many reasons, as managers know people plan to jump ship sooner or later. Staffing agencies have a feed queue for these roles in a large firm, and simply maintain the churn.
Good luck, =3
[dead]
[dead]
The real problem with hiring juniors is that tech does not have flexible pay. Realistically, hiring juniors is high risk high reward so they should naturally be on some kind of probational pay.
Companies hire juniors at low rates, but then when they like them they don't increase the rates. Instead the juniors leave for another company.
If they have to pay market for seniors anyway, why pay to raise them?
If you had to pay market rates for cows once grown, would you breed cows and feed them?
Thats the problem. If you have the pay market when they become seniors, you may as well just pay market for seniors today.
You don't pay as much to retain an employee as you do to hire one. If your employee feels like they're earning 5-10% below market rate, it's probably far less likely that they'll want to find another job than if you pay them 25%+ below market rate. There is a cost and a risk to switching jobs, and most established people at the company won't jump ship due to a discrepancy as small as this. So, the upside is that you get to train people and pay them at a slight discount, as opposed to having to put up a higher senior pay offer to attract someone willing to do the job.
Though, as a current new grad, the desperation market is setting in. I am open to getting paid basically anything a person can survive on where I live to just gain more experience, and many other people are in the exact same situation. The junior market's demands will keep going down until either the benefit of employing us becomes large enough for companies, or until we all leave.
Theyre higher value than actual seniors because they have more domain knowledge, more neuroplastic, probably willing to work harder, etc
My experience, real work is what a junior dev does, without an exception. Senior developer creates over-engineered version of what junior dev made.
Senior devs gibber about database systems, sql, nosql, clustering, etc. The real work storing the input in text file, querying with a simple loop.
Plus there is an additional huge misconception in industry, if something is realtime, it is a senior dev thing. It is something like a plague.