We’re talking about skills that span kernel-level programming, hardware quirks, low-level debugging, distributed systems, security, orchestration logic, even the capability to work with the UI/UX team... and the ability to explain all that without scaring interns. You can’t just hire for that. You have to grow it. Nurture it. Beg for it. Or in some cases, resurrect it.
If you are that person, what is the best way to market yourself? I am the person described. I've got experience from poking registers in firmware, to wireline transport protocol implementation, to infosec, to writing microservice framework middleware, to pipeline orchestration at the OS level, and on and on. In the last week I've debugged Linux UDS issues and TLS cipher suite problems, and wrote code to provision WiFi-connected devices over BLE.
But it's incredibly hard to demonstrate that in an interview, if I can even find a role that warrants it. You're not going to find me on a university campus or in a research lab because I'm at a FAANG trying to pay my mortgage.
I think there's a bit of an "eternal September" where people are promoted to management, asked to hire a bunch of people for some niche role, and blog about their inability to hire good people.
Hate to break it to the author, but there are plenty of people who can write a driver, bootloader, distributed systems, PAXOS, etc. but there's NO JOBS DOING THAT so they all work for <generic SaaS company> making <generic NodeJS app>.
The author mentions their grand strategy is fishing for talent out of universities, which is probably smart. Pulling people out of generic web dev world to go write "container orchestration logic" (or some other niche) is going to be a hard sell - most of those people were burned before by straying too far from the lucrative web dev jobs. Nothing like going into job interviews and telling the hiring manager that your last job was some ultra-obscure niche.
My first job out of university was working on an embedded Java runtime, with a group of peers from said university. Which sounds similar to what Virtualise.sh is doing.
Now, 20 years later? Tech lead on a Typescript/Flutter/AWS internal system.
In some ways I'd be excited to write container orchestration logic, or hack on a hypervisor. There's precious little of that work available, especially so in a small country like mine (NZ). My CV is crazy enough: being burnt isn't the issue, just finding the work is.
The cynical part of me wonders if the other reason to hire people straight out of university is that they're cheap...
Also the usual botched hiring process, where even if one has the knwoledge, just because it wasn't what one was doing the last five years, it doesn't count, even if one has portfolio from side projects to show.
Or the dumb leetcode stuff because "we are going to be cool like Google over here".
So many gravitate to companies with more sensible hiring practices, and that is how a company loses candidates, if it is one of those unicorns that the whole planet wants to work on.
Pretty much matches my experience. I'm an EE, I started out writing an LLVM backend for a custom DSP. Pretty good understanding of hardware, compilers and general low level things.
Now I have a generic web dev job working on a generic nodejs app. There are many more jobs available and in general it's much easier to have a remote web dev job.
I think I'm pretty similar; I don't have great advice, more or less my first real job I got the attention of my skip level boss (he was one of my interviews and also I did a couple projects with him), and he's hired me to two more places since then, so I'd say be sure to network. Bonus points if your network gets you a job where you don't have to work again.
I've also done a couple sessions of peek at a problem in production and fix it / tell people how to fix it based on reputation, which is networking.
Oh, and one more thing: never ever mention any experience with mail handling, or you'll get roped into doing it again. People remember, even if you only said it once. :P
I think this is the real answer. A personal testimony is the only way to truly distinguish between a bullshitter and one of those radically curious, passionate people who learn everything they can and quickly become experts in whatever they touch.
> You're not going to find me on a university campus or in a research lab because I'm at a FAANG trying to pay my mortgage.
Make sure you are demonstrating it to the people on your team so that when they leave and go somewhere else, they can hit you up. This takes some time.
And, sorry, you have to get out and hit some gatherings in person (hackerspaces, meetups, professional meetings, etc.)--online-only isn't going to cut it anymore. With the AI garbage clog of inline interactions, your professional network is back to who you know in-person.
A sibling comment said to repeat what you just said in an interview. Don't do that.
Demonstrating that you are a stable hire who will fit well with the team is almost all that matters. You wouldn't be having an interview to begin with if you didn't technically qualify-ish. Even when speaking to technical interviewers, you will intimidate them. Actually selling yourself comes after your first 90 days of acclimation.
I think it's just not possible, because you're stuck with the reality that it's some combination of a machine and HR sorting through resumes.
Even past that step, it's a bit random. I fully admit I ignore the resume when doing interviews, as it's a bias for the interview role I get, which is typically working through some coding problems.
Go for robotics or specific robotics subtype (UAV, ROV, vehicles, etc..). If there is a "platform team", that would be your best fit, but some companies don't have separate platform team, or they don't advertise team name in the job postings.
People like that are in demand. Our company just filled few position like this, and hiring was hard. Some people were rejected because of not enough low-level knowledge, some people were rejected for not having enough high-level knowledge.
Agree with the TFA's author though, people with all the skills are super rare.. We were lucky to end up with few hires like that, but most of the people don't have all skills at once, and they have to learn on the job.
>because I'm at a FAANG trying to pay my mortgage.
Let's rephrase that:
I'm at a company with top of the line talent in many different domains and I prefer the compensation of this company over networking to find someone who knows the hiring manager of a team like this.
You have the easy way into this. For people without this networking, the best advice is to make them come to you. You gotta share that knowledge out there and get regards in various communities online if you can't stand out in a batch of resumes (and no one these days can, for reasons entirely the fault of HR and ATS). Do that and your newfound network will connect you.
On the right team at a FAANG to a large SaaS, because the places that need all of that kind of work are few and far between. Eg somewhere among the teams that make the Oculus firmware would be close enough to the hardware to need all that sort of work in order to ship to the tight latency specs they're looking for. Or early employee at a startup making a product that's going to need those sort of problems solved on a consistent basis, that's well funded enough that you can have enough time to solve problems like that in ways that aren't a total hack (because we all know those are going to be removed Real Soon Now).
What you say makes sense, but I guess finding the right team is extremely hard. I would guess that 95% of FAANG is actually kinda bad and only lives from the reputation of the 5% (or less). So how do you specifically interview for the 5% without a prior connection / network?
I found it is best to keep quiet, not even have a (directly attached to your name) blog with such varried content, and instead just send appropriate version of your CV when needed. When it comes to interviews I found it helps that I'm in my office/lab space, able to pick up the cam and show the person on call contents of my shelves and present few details about them on the office whiteboard. But even then they of course doubt you.
This is the advice I plus one. On the other hand to include kernel to UI raises security questions. In my experience, I was rejected as "we can't hire you, you're too dangerous."
I think the issue started way before AI when it comes to not having enough fresh blood for this industry. Companies have decided they don't want to train juniors. They want seniors who already have the skills.
> Companies have decided they don't want to train juniors. They want seniors who already have the skills.
It got worse in last two years. Now Senior Engineers must have exact combo of the weird tech stack and tools with N years of experience exactly as the existing employees, else gtfo, you don't even get screening calls. You don't have something from nice to have list? Lol, why are you wasting our recruiter's time even? She needs to use GenAI to write her next rejection email.
Also, your 15yoe does not matter, unless you are coming from direct competitor, in which case your 1.5yoe with internship is also excellent.
I think it is important to acknowledge that it takes much longer to train juniors in systems software today than a couple decades ago because the nature of the problems have changed. It now takes several years to get someone to an acceptable level for a lot of systems software work. In many cases that’s longer than the entire development cycle — a junior would never really be productive on the project. And yes, this is creating a vicious feedback loop where we are no longer producing many new people with these skills despite a lot of demand.
The minimum level of sophistication required to be effective in systems software has increased dramatically since the 1990s, when I first started doing systems software. The kinds of systems software we were putting in production in back then would be considered a trivial toy today. This shift has placed an enormous amount of upward pressure on the minimum level of experience and skill that would allow someone to become productive within a useful amount of time.
It is no longer feasible in many cases to have companies effectively subsidize the development of highly skilled systems software people. The training time has become so long that companies will never recoup the investment. It is easy to see how the incentives have created the current situation and it is not clear how to address the shortage. Even before the current situation, it was widely noted that most systems software developers were self-taught over many years rather than trained up in a structured environment.
>And yes, this is creating a vicious feedback loop where we are no longer producing many new people with these skills despite a lot of demand.
if the company would rather burn out and age out all their talent than invest in the future, I don't know what to say. For niche domains, you can't treat talent a a pure business expense. That's how you lose out all that talent to China and suddenly you can't compete at all. If anything, training should be treated like insurance.
>It is no longer feasible in many cases to have companies effectively subsidize the development of highly skilled systems software people.
"subsidize" implies that somehow engineers are saving money by choosing to take these more niche paths. It doesn't make sense. You have a product and you need talent to develop and maintain it to compete. There's no "subsidies" in a business relationship like this.
your choices are few and simple: train in-house, lobby schools to train for you, or publicize your tech and hope people train themselves for you again. It seems like these days companies aren't looking out long term though and just want to jump the ship that has plenty of time to steer past the iceberg everyone sees ahead.
I agree but it was always like that. Also there isn't any incentive anymore in growing juniors if they're going to immediately take the next better offer that comes around when they know enough, and you have such thing being offered on a daily basis (at least until a couple years ago).
I would love to work on low-level, systems stuff (anything as close to the hardware as possible), that's even my education and area of expertise. BUT SaaS companies in reality:
- pay better
- have lower costs
- are way easier
- don't have that many (or any at all) geographical restrictions (e.g. importing hardware prototypes).
>there isn't any incentive anymore in growing juniors if they're going to immediately take the next better offer that comes around when they know enough
okay. Promote them with proper pay then. This HR debacle of putting more budget into hiring over retaining is entierly self-inflicted.
>People follows the money.
Well that love sounds more like a low priority whimsy in that case. I don't think tech workers of all people are ones who ever complain about low compensation. Unless you work in games, I suppose.
This doesn’t follow. Below some level of skill and experience they can contribute negative value to the project. Companies need a minimum level of experience just to make the role pay for itself.
Does the high skill standard for surgeons mean the market for surgeons is saturated?
...this doesn't make sense. Surely you need to factor in price point. Often times junior engineers deliver disproportionate value. Some ratio of juniors:seniors just seems rational, and those juniors grow into seniors.
Maybe there's a good argument against training, but it could also just be irrational and stubborn in this case.
I’m a lead consultant on a gig where the CTO outright told us that he’s not really interested in growing their (frankly, under qualified) engineers, just wants them to get on with the job - it’s very short-sighted and sad.
That said, in my previous job in a startup we hired very junior engineers and gave them plenty of opportunity and support for growth and several people did stunningly well. Pity the company didn’t do very well (IMHO due to focusing more or this sort of thing rather than making money).
>That said, in my previous job in a startup we hired very junior engineers and gave them plenty of opportunity and support for growth and several people did stunningly well. Pity the company didn’t do very well (IMHO due to focusing more or this sort of thing rather than making money).
Mentoring is a key part of technical leadership, way easier to help the talent grow into your requirements (even if they are under-qualified, for now)
Maybe I'm being too cynical, but I can't tell whether this is a promotional piece for something..
That said, I do agree with the premise of the article that it's hard to learn "the stack", especially with the advent of generative AI.
"Back in the day", when google spat out a link to something resembling your problem, you still had to deconstruct the answer given to apply it to your particular case. That required some sort of understanding, or a mental model of the domain. With ChatGPT I find myself copying/pasting error messages between two browser windows, or a terminal, not really understanding what is going on.
No learning is happening. Does not bode well for new folks coming in.
It's not a promotional piece of something, it's my personal experience as a CEO and co-founder of a company using Xen as the core of our stack. I like to share my views in a transparent fashion on how it's hard to do very technical stuff, not just for technical reasons, but due to the lack of people trained for.
It is a promotional piece - for Xen-based stack (the most popular hypervisor decades ago). That author laments that few people are interested in bare-metal hypervisors, like Xen.
But hypervisors did not disappear, they just got replaced. When we run virtual machines, they are usually backed by KVM (low-level) and qemu (higher layer). Sometimes there is libvirt on top of it too, but running qemu directly is not that hard.
And there is plenty of exciting research about this stack, for example KVM can be driven by things like firecracker and crosvm, and there are some rust projects targeting it too. There is also BSD's bhyve which
My impression is that it's not that people find hypervisors in general are boring, but just Xen specifically (or maybe all classic Type-1 ones? hard to tell with Xen being the only open-source representative).
I respectfully disagree with much of your comment.
First, this wasn't intended as a promotional piece. It's a personal blog post where I share some of the challenges involved in building a full virtualization stack — a stack that happens to be fully open source. It's unfortunate that sharing real-world experience is sometimes immediately perceived as promotional.
Second, I think there's some confusion between using a hypervisor and mastering one — or building and maintaining an entire stack around it. KVM/QEMU is widely used, but it has significant issues, especially regarding security, performance, and latency consistency. Very few groups in the world are actively trying to tackle these challenges holistically (even major players like VMware have made some questionable shortcuts).
When it comes to low-latency, real-time use cases with a strong security model, Xen remains unique among open-source hypervisors. It's definitely not boring — in fact, it's one of the few that enable certain classes of critical applications at all.
We also work closely with academic research labs, and I can tell you: there’s still a lot of exciting work happening around Xen — even if it's less visible than buzz around newer projects like Firecracker or crosvm.
It made me smirk a little, I've been doing almost exactly this line of work at $dayjob for the past few weeks/months, trying to prove out a concept as a solution to solve a problem. Actually really enjoyed the work, it has been a neat problem to solve.
Sadly, the program I was supporting just had all of its funding yanked, I expect to get laid off tomorrow.
> No learning is happening. Does not bode well for new folks coming in.
Recently got into a completely new language/framework and used Copilot to understand what was going on. I still made all the big decisions and wrote most of the code myself.
You can definitely use AI to avoid learning though (up to a point).
> If it's difficult to find kernel developers then wouldn't it help to not require them to also know web UX?
That means hiring two people, and in $current_year, companies expect one person to know everything. Sysadmin, backend programmer, frontend programmer, designer and a DBA used to be different people not that long ago, now they expect one person to do all that... + it seems they want kernel development experience now.
Good, that's the way it was until the splitting of roles for commodification. A programmer is more like the Renaissance man who makes it a goal to do everything from different disciplines than a drone who has been trained to do one thing and can only be trusted to do one thing.
Sure, let me explain it a bit better. It's more like in the sense of the "stack" is very deep now. Clearly, we have/hire Xen/hypervisors specialist, and we do not ask them to be CSS experts. However, deeper in the stack (at lower levels) harder it is to find them, because of the lack of expertise in universities and/or appeal of doing such job.
And if you find or train those low-level/system-oriented people, they also need to understand how a feature they build will be exposed functionally to a user (and why they need it in the first place). Because things are not make into thin-air but required to work in a bigger picture (ie: the product).
Because we cannot afford that, we aren't Google, and still a relatively small company vs the task of building a full-stack virtualization solution. Luckily, we have other strong points helping a lot (remote first, no micro-management, a great culture promoting human values and so on etc.)
Great idea to go to Grenoble (France). There is there a nice ecosystem of companies + grad schools + researchers, one of the birth place of IT in France.
If you are looking for the place to hire new engineers, or researchers to work on an advanced project, I would recommend it too.
The median software developer in France (similar for e.g. Germany) makes around 50k. Software development as a path to personal wealth does not exist outside the US.
The proposition by these companies for new hires is: "Put in a lot of work, longer hours and solve difficult problems, so that (after taxes) you can earn 2k more a year than someone with a far more relaxed job".
The only people you are going to find are the very few ones intrinsically motivated to forego their social life in favor of your job offer and new graduates who don't know any better and will burn out and resent you and possibly the entire industry for the rest of their lives.
I will not put in exceptional effort, unless you are offering me something exceptional in return. And no, the "opportunity" to work hard on some problem does not count.
Basically all of Europe has this problem, companies are looking for people who put in exceptional work for average salaries. The problem isn't that these people don't exist or that you couldn't find them. The problem is that everyone who fits your role knows what kind of effort it involves and knows that their time will never be adequately rewarded.
Curious if there is a way to dip your toe into this kind of thing without dedicating years of learning. Maybe a home lab? I've always been interested in this because it seems hard/interesting, and enjoyed learning about it in school. Wondering how much time you'd have to invest to see if you like it. I assume there is a healthy amount of "this is hard/not fun" along the way before you find out.
Readit News
We’re talking about skills that span kernel-level programming, hardware quirks, low-level debugging, distributed systems, security, orchestration logic, even the capability to work with the UI/UX team... and the ability to explain all that without scaring interns. You can’t just hire for that. You have to grow it. Nurture it. Beg for it. Or in some cases, resurrect it.
If you are that person, what is the best way to market yourself? I am the person described. I've got experience from poking registers in firmware, to wireline transport protocol implementation, to infosec, to writing microservice framework middleware, to pipeline orchestration at the OS level, and on and on. In the last week I've debugged Linux UDS issues and TLS cipher suite problems, and wrote code to provision WiFi-connected devices over BLE.
But it's incredibly hard to demonstrate that in an interview, if I can even find a role that warrants it. You're not going to find me on a university campus or in a research lab because I'm at a FAANG trying to pay my mortgage.
Hate to break it to the author, but there are plenty of people who can write a driver, bootloader, distributed systems, PAXOS, etc. but there's NO JOBS DOING THAT so they all work for <generic SaaS company> making <generic NodeJS app>.
The author mentions their grand strategy is fishing for talent out of universities, which is probably smart. Pulling people out of generic web dev world to go write "container orchestration logic" (or some other niche) is going to be a hard sell - most of those people were burned before by straying too far from the lucrative web dev jobs. Nothing like going into job interviews and telling the hiring manager that your last job was some ultra-obscure niche.
My first job out of university was working on an embedded Java runtime, with a group of peers from said university. Which sounds similar to what Virtualise.sh is doing.
Now, 20 years later? Tech lead on a Typescript/Flutter/AWS internal system.
In some ways I'd be excited to write container orchestration logic, or hack on a hypervisor. There's precious little of that work available, especially so in a small country like mine (NZ). My CV is crazy enough: being burnt isn't the issue, just finding the work is.
The cynical part of me wonders if the other reason to hire people straight out of university is that they're cheap...
(throwaway account, my CV is bad enough already)
Or the dumb leetcode stuff because "we are going to be cool like Google over here".
So many gravitate to companies with more sensible hiring practices, and that is how a company loses candidates, if it is one of those unicorns that the whole planet wants to work on.
Now I have a generic web dev job working on a generic nodejs app. There are many more jobs available and in general it's much easier to have a remote web dev job.
I've also done a couple sessions of peek at a problem in production and fix it / tell people how to fix it based on reputation, which is networking.
Oh, and one more thing: never ever mention any experience with mail handling, or you'll get roped into doing it again. People remember, even if you only said it once. :P
Make sure you are demonstrating it to the people on your team so that when they leave and go somewhere else, they can hit you up. This takes some time.
And, sorry, you have to get out and hit some gatherings in person (hackerspaces, meetups, professional meetings, etc.)--online-only isn't going to cut it anymore. With the AI garbage clog of inline interactions, your professional network is back to who you know in-person.
Demonstrating that you are a stable hire who will fit well with the team is almost all that matters. You wouldn't be having an interview to begin with if you didn't technically qualify-ish. Even when speaking to technical interviewers, you will intimidate them. Actually selling yourself comes after your first 90 days of acclimation.
Even past that step, it's a bit random. I fully admit I ignore the resume when doing interviews, as it's a bias for the interview role I get, which is typically working through some coding problems.
People like that are in demand. Our company just filled few position like this, and hiring was hard. Some people were rejected because of not enough low-level knowledge, some people were rejected for not having enough high-level knowledge.
Agree with the TFA's author though, people with all the skills are super rare.. We were lucky to end up with few hires like that, but most of the people don't have all skills at once, and they have to learn on the job.
Let's rephrase that:
I'm at a company with top of the line talent in many different domains and I prefer the compensation of this company over networking to find someone who knows the hiring manager of a team like this.
You have the easy way into this. For people without this networking, the best advice is to make them come to you. You gotta share that knowledge out there and get regards in various communities online if you can't stand out in a batch of resumes (and no one these days can, for reasons entirely the fault of HR and ATS). Do that and your newfound network will connect you.
Tldr raise your price and they'll belive easier.
If that has worked for you, that's amazing! But it seems really counter-intuitive to me.
It got worse in last two years. Now Senior Engineers must have exact combo of the weird tech stack and tools with N years of experience exactly as the existing employees, else gtfo, you don't even get screening calls. You don't have something from nice to have list? Lol, why are you wasting our recruiter's time even? She needs to use GenAI to write her next rejection email.
Also, your 15yoe does not matter, unless you are coming from direct competitor, in which case your 1.5yoe with internship is also excellent.
The minimum level of sophistication required to be effective in systems software has increased dramatically since the 1990s, when I first started doing systems software. The kinds of systems software we were putting in production in back then would be considered a trivial toy today. This shift has placed an enormous amount of upward pressure on the minimum level of experience and skill that would allow someone to become productive within a useful amount of time.
It is no longer feasible in many cases to have companies effectively subsidize the development of highly skilled systems software people. The training time has become so long that companies will never recoup the investment. It is easy to see how the incentives have created the current situation and it is not clear how to address the shortage. Even before the current situation, it was widely noted that most systems software developers were self-taught over many years rather than trained up in a structured environment.
if the company would rather burn out and age out all their talent than invest in the future, I don't know what to say. For niche domains, you can't treat talent a a pure business expense. That's how you lose out all that talent to China and suddenly you can't compete at all. If anything, training should be treated like insurance.
>It is no longer feasible in many cases to have companies effectively subsidize the development of highly skilled systems software people.
"subsidize" implies that somehow engineers are saving money by choosing to take these more niche paths. It doesn't make sense. You have a product and you need talent to develop and maintain it to compete. There's no "subsidies" in a business relationship like this.
your choices are few and simple: train in-house, lobby schools to train for you, or publicize your tech and hope people train themselves for you again. It seems like these days companies aren't looking out long term though and just want to jump the ship that has plenty of time to steer past the iceberg everyone sees ahead.
I would love to work on low-level, systems stuff (anything as close to the hardware as possible), that's even my education and area of expertise. BUT SaaS companies in reality:
- pay better
- have lower costs
- are way easier
- don't have that many (or any at all) geographical restrictions (e.g. importing hardware prototypes).
People follows the money.
okay. Promote them with proper pay then. This HR debacle of putting more budget into hiring over retaining is entierly self-inflicted.
>People follows the money.
Well that love sounds more like a low priority whimsy in that case. I don't think tech workers of all people are ones who ever complain about low compensation. Unless you work in games, I suppose.
Does the high skill standard for surgeons mean the market for surgeons is saturated?
Maybe there's a good argument against training, but it could also just be irrational and stubborn in this case.
That said, in my previous job in a startup we hired very junior engineers and gave them plenty of opportunity and support for growth and several people did stunningly well. Pity the company didn’t do very well (IMHO due to focusing more or this sort of thing rather than making money).
The truth is bound to be somewhere in the middle.
Mentoring is a key part of technical leadership, way easier to help the talent grow into your requirements (even if they are under-qualified, for now)
That said, I do agree with the premise of the article that it's hard to learn "the stack", especially with the advent of generative AI.
"Back in the day", when google spat out a link to something resembling your problem, you still had to deconstruct the answer given to apply it to your particular case. That required some sort of understanding, or a mental model of the domain. With ChatGPT I find myself copying/pasting error messages between two browser windows, or a terminal, not really understanding what is going on.
No learning is happening. Does not bode well for new folks coming in.
It's not a promotional piece of something, it's my personal experience as a CEO and co-founder of a company using Xen as the core of our stack. I like to share my views in a transparent fashion on how it's hard to do very technical stuff, not just for technical reasons, but due to the lack of people trained for.
But hypervisors did not disappear, they just got replaced. When we run virtual machines, they are usually backed by KVM (low-level) and qemu (higher layer). Sometimes there is libvirt on top of it too, but running qemu directly is not that hard.
And there is plenty of exciting research about this stack, for example KVM can be driven by things like firecracker and crosvm, and there are some rust projects targeting it too. There is also BSD's bhyve which
My impression is that it's not that people find hypervisors in general are boring, but just Xen specifically (or maybe all classic Type-1 ones? hard to tell with Xen being the only open-source representative).
I respectfully disagree with much of your comment.
First, this wasn't intended as a promotional piece. It's a personal blog post where I share some of the challenges involved in building a full virtualization stack — a stack that happens to be fully open source. It's unfortunate that sharing real-world experience is sometimes immediately perceived as promotional.
Second, I think there's some confusion between using a hypervisor and mastering one — or building and maintaining an entire stack around it. KVM/QEMU is widely used, but it has significant issues, especially regarding security, performance, and latency consistency. Very few groups in the world are actively trying to tackle these challenges holistically (even major players like VMware have made some questionable shortcuts).
When it comes to low-latency, real-time use cases with a strong security model, Xen remains unique among open-source hypervisors. It's definitely not boring — in fact, it's one of the few that enable certain classes of critical applications at all.
We also work closely with academic research labs, and I can tell you: there’s still a lot of exciting work happening around Xen — even if it's less visible than buzz around newer projects like Firecracker or crosvm.
Sadly, the program I was supporting just had all of its funding yanked, I expect to get laid off tomorrow.
Sometimes, probably most of the time, it is better to work through it and understand an issue than to blindly copy pasta.
Recently got into a completely new language/framework and used Copilot to understand what was going on. I still made all the big decisions and wrote most of the code myself.
You can definitely use AI to avoid learning though (up to a point).
It goes on to say that it's hard to find and develop expertise for low level software like hypervisors.
What's the connection between the topics? It feels like two different rants.
If it's difficult to find kernel developers then wouldn't it help to not require them to also know web UX?
That means hiring two people, and in $current_year, companies expect one person to know everything. Sysadmin, backend programmer, frontend programmer, designer and a DBA used to be different people not that long ago, now they expect one person to do all that... + it seems they want kernel development experience now.
A single person can in fact write a program for a computer.
And if you find or train those low-level/system-oriented people, they also need to understand how a feature they build will be exposed functionally to a user (and why they need it in the first place). Because things are not make into thin-air but required to work in a bigger picture (ie: the product).
I don't see "pay like Google" listed.
If you are looking for the place to hire new engineers, or researchers to work on an advanced project, I would recommend it too.
The proposition by these companies for new hires is: "Put in a lot of work, longer hours and solve difficult problems, so that (after taxes) you can earn 2k more a year than someone with a far more relaxed job".
The only people you are going to find are the very few ones intrinsically motivated to forego their social life in favor of your job offer and new graduates who don't know any better and will burn out and resent you and possibly the entire industry for the rest of their lives.
I will not put in exceptional effort, unless you are offering me something exceptional in return. And no, the "opportunity" to work hard on some problem does not count.
Basically all of Europe has this problem, companies are looking for people who put in exceptional work for average salaries. The problem isn't that these people don't exist or that you couldn't find them. The problem is that everyone who fits your role knows what kind of effort it involves and knows that their time will never be adequately rewarded.