Live data from Hacker News

You can't git clone a team

virtualize.sh

31–40 of 115 posts

Re: You can't git clone a team

#31

As an aside, TFA says: 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, w…

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 cou…

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."

Re: You can't git clone a team

#32

The article starts off saying that if you want people with real full stack experience, from kernel to UX, you need to grow it. 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?

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).

Re: You can't git clone a team

#33
post #22

> What we’re doing about it (before it’s too late) I don't see "pay like Google" listed.

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.)

Re: You can't git clone a team

#34
post #21
post #3

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…

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 h…

Hi,

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.

Re: You can't git clone a team

#35
The title holds for much more specific and thinner stacks, along with support, QA, and sales - especially even simple web apps.

Onboarding is important Training is important Retaining is important

Maybe your system is 100% documented, conventional (looking at you Rails, Angular), debt free, tested, instrumented - but more than likely it's not.

But if you get down to staff who can't teach a a system, including product teams that don't respect feature overload, value, or internal feature training. If you prioritize new features over team development and training (aka a team that doesn't know the system), you're likely to get muddy with existing features both technically and use facing.

Re: You can't git clone a team

#36

The title holds for much more specific and thinner stacks, along with support, QA, and sales - especially even simple web apps. Onboarding is important Training is important Retaining is important Maybe your system is 100% documented, conventional (looking at you Rails, Angular), debt free, tested, instrumented - but more than likely it's not. But if you get down to staff who can't teach a a system, including product…

I agree. If it's already hard for simpler stacks, you can imagine how hard it is for more critical or complex ones. And it's even worse if you inherited some of it (ie collecting technical debt that's not yours, which is the case here as some part of the stack are the result of a fork).

Sometimes it's even a catch-22 situation, where the technical/generic knowledge is already hard to find, but you absolutely need it to train more junior people. Luckily we found such experimented people, but then you also need to use their expertise to actually fix stuff and not just mentor juniors. A very very delicate balance to find, especially in a timed market.

Re: You can't git clone a team

#37

As an aside, TFA says: 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, w…

Say the things you just said, but in the interview

getting the interview is the hard part and the reason you need to market yourself

Re: You can't git clone a team

#38

As an aside, TFA says: 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, w…

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

Re: You can't git clone a team

#39

Earlier quoted context omitted.

Say the things you just said, but in the interview

getting the interview is the hard part and the reason you need to market yourself

There's also a question of making the market. I've got these really weirdly-broad skills. LinkedIn is not great for finding the niches I want to fit. I suppose there's HN's "Who Wants to be Hired" threads, but that's risky if you're already employed. I'm obviously networking already, but what else is there?

Re: You can't git clone a team

#40

> System teachers: now rarer than RGB-free laptops LLM are quite good at explaining systems and frameworks. I would never got into kernel programming without Deepseek guidance. As for universities: too expensive, too much paperwork, too slow, too elitist.

It's true but until some extent. When you are talking about a hypervisor (like Xen), and many many subtle things depending on your CPU brand/model, it's really really *hard*, even with an LLM (and even more with an LLM hallucinating some CPU features or forgetting basic things like Meltdown and Spectre). However I agree: to learn a topic, LLMs are providing a great speedup. As a CEO/co-founder, I have no issue to hir…

As a CEO, are you going to hire that motivated student? Or is it some sort of unpaid internship?
Post reply on HN