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.
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”.
>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 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.)
> >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 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.
> 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?
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.
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.
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.
> 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.
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.
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 company that used FizzBuzz had a rule that we’d give the candidate an explanation of the modulus operator if they weren’t familiar or didn’t remember.
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).
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)
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.
I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
I have such strong but mixed feelings about this.
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.
Are you explicit about this when you pose the problems?
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.
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.
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.
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:
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.
> 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.
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'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 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.
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.
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.
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".
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
It usually amounts to asking only 2 or 3 questions and a lot of discussion. I honestly wouldn't mind if we only get through one question if it leads to good insight on the candidate.
> 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 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.
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 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.
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.
> 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.
> 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?
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.
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.
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.
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.
If I handed you 200 resumes and said "hire from this set our next junior frontend engineer," how would you do it? Assume: generic b2b SASS, post-seed, 5 person engineering team making first junior hire.
> 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
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/
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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 :) )
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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?
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 :)
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.
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.
> 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!
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".
Personally I think the junior/senior distinction is overstated. Yes, experience does count for something. But it comes a distant third on the list to the two Joel mentions.
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.
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.
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%.
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.
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?
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.
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.
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.
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.
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.
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.
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?!)
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.
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.
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.
Binghamton is a good program. They and the other SUNYs affiliated with the NY Semiconductor Initiative have continued to use the same curriculum industry partners recommended.
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.
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.
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.
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.
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.
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.
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.
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.
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”.
>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 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.
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.
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.
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.
> 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.
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.
How do candidates express that in interviews?
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.
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.
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.
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.)
> >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.
> 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?
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.
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.
Thanks for fighting the good fight. I know I left Reddit for Digg (btw Digg's back) because of all that negativity.
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.
> 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.
> 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 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.
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 company that used FizzBuzz had a rule that we’d give the candidate an explanation of the modulus operator if they weren’t familiar or didn’t remember.
It didn’t change anything.
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).
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)
You might like https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
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.
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.
Are you explicit about this when you pose the problems?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.
> 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.
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.
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.
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"
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"
https://knowyourmeme.com/memes/the-breakfast-question
That other one about anachronisms feels a bit too familiar. Something about George Washington taking airfields.
Wow that got dark fast.
Par for course for greentext.
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.
Yep 100%
It's disturbing that you went from hiring to execution that quickly.
"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"
> 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.
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'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.
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.
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.
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.
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.
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".
> I've also seen less and less passion for the career as the years go by (ie. less computer nerds).
Ahh yes, the 'pre-med'ification of CS.
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 try to give them problems
What does it look like in a span of an hour?
It usually amounts to asking only 2 or 3 questions and a lot of discussion. I honestly wouldn't mind if we only get through one question if it leads to good insight on the candidate.
> 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 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.
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 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.
Then, among 200 resumes, how do you find the good programmer? If you have budget to hire one of them.
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.
> 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.
> 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?
> 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.
> 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.
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.
Cloning a repo and running things from it are two very different things.
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.
Understood, thanks for clarifying.
I don't see why using vi mode in vscode isn't a green flag.
That would be a green flag for me.
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.
If I handed you 200 resumes and said "hire from this set our next junior frontend engineer," how would you do it? Assume: generic b2b SASS, post-seed, 5 person engineering team making first junior hire.
> 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
[dead]
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.
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.
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/
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.
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.
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.
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.
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.
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.
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.
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.
In my experience hiring, its not just the top 0.5%, more like the top 30-50%.
People aren’t fungible. The senior engineer you’ve trained for a couple years is way more effective than the one that joined yesterday.
But also is paid less than a new joiner.
At most places yeah
> 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"?
> 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.
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 :) )
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.
Prince Edward Island sounds a _great_ place to work from home!
Source: am WFH in remote farmhouse in Scandinavia- with fibre.
>> 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.
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.
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.
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.
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.
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.
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.
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 wonder if an AI wrote this. It seems to have all the hallmarks.
1. It's not just x - it's y.
You're absolutely right!
You've touched on something profound and deeply human.
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.
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.
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.
Out of curiosity, how did you "lose" them? Was it a 3 week stint from the getgo?
Sounds like its time to make him an offer he can't refuse
Ok?
Ok!
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.
> 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!
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]?
Personally I think the junior/senior distinction is overstated. Yes, experience does count for something. But it comes a distant third on the list to the two Joel mentions.[0] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
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.
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.
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%.
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 saying to hire offshore
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.
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.
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.
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.
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.
Isn’t your pay kind of low to be an in office job in NYC?
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.
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.
The real pro tip: hire someone with 2-3 years of experience
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?!)
The technical term is “recession”
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.
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.
SUNY binghamton https://www.binghamton.edu/watson/student-services/advising/...
Binghamton is a good program. They and the other SUNYs affiliated with the NY Semiconductor Initiative have continued to use the same curriculum industry partners recommended.
They are a semi-target.
Ok, which companies has it killed? At least one example?
many companies are walking corpses - see GE
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.
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]
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.
As in “kick ass and we’ll pay ya even better than we are now” probation?
Yes
I’m all about that.
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.
I have seen this happen countless times and it still baffles me.
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
Employees aren't fungible.