Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SadServers – Test your Linux troubleshooting skills

sadservers.com

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#81

Post by KaiserPro »

deeblering4 wrote: post #6

> It's also my not-so-secret hope that a sophisticated enough version of SadServers could be used by tech companies (or for companies that carry on job interviews on their behalf) to automate or facilitate the Linux troubleshooting interview section. Yup, that's what I was afraid of.

but why? a real test that is repeatable, realistic and not _overly_ hard. Sure for a junior software its a bad fit. but for a devop/sre/sysadmin, its a great fit.

its certainly better than some crappy whiteboarding session, or worse a take home test.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#82

Post by andrewmcwatters »

grepLeigh wrote: post #73
andrewmcwatters wrote: post #68

Earlier quoted context omitted.

I feel like you definitely have to target particular companies and more specifically specific titles and skills to offer to do so. My guess is trying to sell high end services as a "principal software engineer" isn't going to be enough to justify that cash comp to a lot of people hiring.

I wouldn't think of it as trying to sell yourself as a "principal software engineer" on an open market. I'd make a list of the companies where hiring/scaling the ops team will make or break the business's value delivery, and filter by companies aware of this. You can knock this out at the recruiting step, just by asking about open developer headcount vs. open SRE ops headcount. Ask which direction that ratio seems to…

Thanks for the heads up!

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#83

Post by mike_d »

rednerrus wrote: post #47
mathverse wrote: post #32

Earlier quoted context omitted.

People in higher up positions like yourself will rarely be subjected to testing with tools like this. You are basically trying to remove the human from equation and industrialize the whole process.

What we're trying to do is respect peoples' time. We can get more about someone's technical understanding in 30 minutes of hands on exercises than we can in a full day of panel interviews. It's better for us as we have a much better understanding of where you're at Linux wise and it's better for you because you only need to come to two hours of interviews, total. Seems like a win win to me.

In my experience this type of interview (and coding interviews in general) usually fall into one of two categories: 1) "I learned this neat trick and want to show candidates how smart I am" or 2) "I have this bug in prod and I want to see if you can fix it for me."

If the interview was along the lines of upgrading the packages on the system, debugging why nginx was crashing, figuring out the specs of the system, etc. that is totally fine with me and I believe respectful of a candidates time. Unfortunately it always turns into something else when people need to come up with new "challenges" for canidates.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#84

Post by BossingAround »

apawloski wrote: post #13

Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/ . That will avoid account limits and also keep your AWS costs more predictable.

Why not spin up containers instead of VMs? Seems to me containers would fit much better than VMs.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#85

Post by BossingAround »

yubiox wrote: post #15

Can't get to the first problem because of HN hug but anyway there are fake ways to "solve" it like renaming the logfile (what they test for solved is provided).

This is a self-test, not a certification. The goal is not to defeat the verification goal, but to learn something. So yeah, it's perfectly acceptable that the tests are not bullet-proof.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#88

Post by freeone3000 »

yamtaddle wrote: post #63
apawloski wrote: post #13

Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/ . That will avoid account limits and also keep your AWS costs more predictable.

Just run them in Linux VMs with WASM, on the users' browsers. Make them all pay for it with higher utility bills and greater wear & tear on their hardware. trollface.jpg

This is actually a good idea for this -- the user wants the education, they can pay for it with their own hardware. Keep your costs low!

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#89

Post by fduran »

BossingAround wrote: post #87

I'd love to get the actual VM content offline, packaged as Vagrantfiles or Containerfiles. Love the idea though! Go to Pluralsight and pitch it to them :)

A few people have suggested offering content offline as a Docker image etc, good idea, thanks.

Re: Show HN: SadServers – Test your Linux troubleshooting skills

#90

Post by twalla »

ilyt wrote: post #35
apawloski wrote: post #13

Based on your architecture diagram it looks like you're spinning up an instance per-user? As you're probably finding now, you will hit AWS limits quickly. You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/ . That will avoid account limits and also keep your AWS costs more predictable.

That's kinda nice use case for the WASM machine/linux emulators, then you just need to provide image and user can run it in the browser > You might instead want to have a smaller pool of (larger) servers that you run co-resident VMs on with https://firecracker-microvm.github.io/ . That will avoid account limits and also keep your AWS costs more predictable. I'd imagine (still waiting for it to load lmao) most of it c…

Someone else linked https://github.com/copy/v86 which seems really neat.

I like making jokes with coworkers about implementing this or that bit of infra with WASM-based tools mostly to get a rise out of them but each time I make the joke I look into some of the tools or projects and the balance of joke to "I'm actually serious" shifts a little bit to the right.

Post reply on HN