There Is a Huge Pool of Exceptional Junior Engineers
Posted3 months agoActive3 months ago
workweave.devTechstoryHigh profile
heatedmixed
Debate
85/100
Hiring PracticesJunior EngineersAI in Tech
Key topics
Hiring Practices
Junior Engineers
AI in Tech
The article argues that companies are missing out on exceptional junior engineers, sparking a debate on hiring practices, the value of junior engineers, and the impact of AI on the tech industry.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3m
Peak period
112
0-6h
Avg / period
16
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 29, 2025 at 11:17 PM EDT
3 months ago
Step 01 - 02First comment
Sep 29, 2025 at 11:20 PM EDT
3m after posting
Step 02 - 03Peak activity
112 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 3, 2025 at 10:53 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45421564Type: storyLast synced: 11/20/2025, 8:14:16 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
(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?!)
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.
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.
Its like I asked of examples of burn victims and you told me "steve has the flu".
Today they're sitting on $10B in cash and do another $10B in free cashflow annually. Not very corpse-like!
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.
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...
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.
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 :) )
It's just a place that is geographically disconnected from the mainland, and it rhymes.
Source: I work with some people from PEI.
Source: am WFH in remote farmhouse in Scandinavia- with fibre.
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.
And shopify seems like an odd company from the outside.
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.
I just checked the public school i went to and their required courses for CS include those that you listed
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.
They are a semi-target.
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
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.
This is why the majority of startup activity in the space has shifted to Israel, the CEE, or India with a nominal American HQ hosting a CEO, CRO, and sales reps.
And this is the issue - we live in a globalized world, and a large portion of junior engineers in the US do not have the skills commensurate to the salary provided.
A business is not a charity.
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.
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.
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#.
This is just sound advice in general. A good professional analogue to recommending a junior college as a stepping stone to a university.
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.
>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.
If you happen to be a superstar with a rare niche skill (like building frontier AI models), you basically skip the interview loop and get fought over with million-dollar offers. But that’s a tiny fraction of the market.
For everyone else, hiring looks a lot like dating: both sides aim for a “10,” but usually settle for a “6 or 7.” And the whole process is signaling—candidates overstate their skills, companies oversell their culture and tech stack, and the match lands somewhere in the middle.
Probably the most important non-technical skill is dealing with the egos in the industry since you will come across a lot of them.
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).
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.
It's a totally unavoidable problem with our industry.
People get bored working on one domain, one product and one codebase.
And most software shops have one domain, one product and one codebase.
It's the pay.
> People get bored working on one domain, one product and one codebase.
Yeah bullshit. It's the pay.
It's pay. It's always been pay.
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.
That's true, but why are you qualifying this with "who provide negative value at the start" in the first place? What if you hire juniors who provide positive value at the start instead?
Besides most companies won’t last long enough to worry about senior talent drying up.
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.
But that's fine. The junior you trained up will be more effective at their next job, and the junior your competitor trained up will be more effective when you hire them at your company. Again, that's how it's been for far longer than we've had LLMs.
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.
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.
I am saying that I care about them, and individually we all should pay attention to them. In this case, I will continue to push for juniors even if my higher-ups push for us to hire seniors only and augment our workforce with LLMs for more junior-level work.
It's stupidly expensive though if you look at the opportunity cost of that already-onboarded senior/lead/staff eng time. And this was obviously more compelling when it was super hard to hire senior talent.
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.
There has never been an apprenticeship model where one apprentice is trained by several masters. It's always the other way around.
A person who is learning a trade from a skilled employer, having agreed to work for a fixed period at low wages.
This fits the bill at leat in the MA "training programs" that I'm aware of, but again I'm not training at overseas dojos.
Has been a great, self-motivated hire who has found problems to solve and led the effort for solving them, resulting in saving our company a lot of money.
You don't have enough data to know if what you think matters in a candidate actually matters. If you repeat the same steps as before, you're likely to see different results.
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.
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.
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.
Whether or not it works will be something we find out long past the early-experience tenure of those junior engineers.
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.
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.
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.
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.
Software talk is free. So everyone can chime in. Your experience holds no weight. Heck an LLM can do it too.
However, I do feel that our team needs both types of people to be effective. People that have passion will try new things and explore possibilities more frequently. The "just a paycheck" folks tend to be a good moderating force to the "passion" people. They will generally bring focus and keep the end goal in perspective.
My goal is to avoid having too many of either. Too many "passion" people and you end up slowing progress because they're getting bogged down with everything they want to do. Too many "paycheck" people and the team/system starts to calcify (and usually accrues a ton of tech debt).
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.
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.
These days it's not difficult to buy hardware with Linux in mind, even on a budget. (And if you have two computers, I feel like budget is probably not really a problem for you.)
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.
In fact, most likely dozens of them will be perfectly good hires for the position.
The idea that you must hire only the single best possible candidate can lead to some pretty dehumanizing treatment of applicants, when the truth is that a) there almost certainly is no "single best possible candidate", there are many people who would do a roughly equally good job there, and b) your processes are almost certainly not optimized to actually find the true single best candidate for the job, but rather the person who is best at applying and interviewing for jobs among the candidates.
All that said, for "how do you actually design a better process"...I sure as hell don't know. I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.
No, it pretty much does mean that.
Until you can come up with concrete improvements and understand the potential flaws in those proposals as well, you can't usefully critique the existing system.
If they come in with a Linux laptop but aren't comfortable with the command line, that's weird. If they come in with a Mac or Windows laptop and do solid work only with GUI tools, that's fine. If the job requires being able to use specific tools (command-line or GUI or whatever), then the interview should evaluate that as well.
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.
These aren't tests if a user can si their job or knows their tools. This is a cultural purity test to see if they have the same quirks as OP. And is a terrible way to judge if someone will perform.
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?
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.
This is super ironic and shows your "us" in "the rest of us" is a tiny, marginal group, maybe "Silicon Valley programmers" or something. In most small software companies they couldn't care less what you use, the only thing they look at is perceived "speed". You could install Red Star OS and get a few pats on the back if you're closing the highest number of Jira tickets.
Hell, nowadays more and more are full remote and the devs do their work on their personal device. Or they do BYOD. Work devices are a cost center.
It's the opposite, the only places that force a particular OS are the top companies for whom compliance, fleet management and such are priorities.
All it takes for BYOD to become difficult is having to handle personally identifiable information under the rules of the GDPR, or having some kind of professional indemnity insurance with cybersecurity provisions, perhaps having quality management certification, being in certain highly-regulated professions like law or medicine, being in the public sector, working government contracts, etc. etc. (the list goes on and on) -- I'm just finding it hard to believe that this list doesn't capture most companies.
But then again, maybe, I am a member of an out-of-touch elite.
Are you sure about that? I have a strong suspicion that there may be a measurable correlation between using IDEs and other tools that aren't currently trendy/overhyped and having a stronger-than-average foundation of experience.
Given that VSCode is the big, trendy IDE at the moment, doesn't using a different one indicate that a developer has, at minimum, invested some thought and effort into considering alternatives and making a conscious choice?
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?
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.
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?
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 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.
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.
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.
263 more comments available on Hacker News