This was a fantastic and enlightening read, thank you.

I'm always impressed when I read about the exploits of the US Digital Service. As I understand it, they have basically no direct power. They can walk in, say "I'm here from the White House," and anything beyond that is chutzpah, effort, and nightmare-difficulty cat herding. Getting whole departments to volunteer to try a different hiring program from that humble starting point is staggeringly impressive, and I think the author's underselling it.

>There was a really interesting talk at Strange Loop this year about how quirks in code layout fool programmers into chasing their tails thinking they’re improving performance when they’re not.

I think the author may be referring to this talk:

https://www.youtube.com/watch?v=r-TLSBdHe1A

Absoluteky astounding take on optimisation - one example uses techniques to get 25% speedup in SQLite - wow!

I couldn't find discussion on HN - maybe because YouTube doesn't have canonical link addresses for videos?

This is a fantastic talk. Well worth the time spent watching it.

"White House HR once tried to reject a candidate whose previous employer was Github because he didn’t specifically list experience with version control on his resume."

This happens in the private sector too, had this with an internal recruiter that had no idea about the role and was only checking for keywords.

Happens in European private sector a lot.

HR and internal recruiters are clueless about how software engineering knowledge and experience works and just filter based on keywords. Most have no idea what's the difference between C & C++, Java & JavaScript so you have to tailor your resume for each application to include all the buzzwords they want to hear if you want your resume to reach the technical staff.

An external recruitment company in Germany got me to fill in a spreadsheet rating my knowledge of several technologies including among other things, I quote: "Fox Pro, Windows 98/2000/XP/Vista, MacOS, Adobe Flash, OS/400, MS Office, Lotus Notes, WLAN, Outlook, Backup, Cisco, Alcatel".

I've never facepalmed myself so hard in my entire life.

Now I understand why lots of top companies here employ external recruitment agencies from the UK. At least there's some tech savvy people among them who can understand what the company needs and what potential the employee has to fit the requested position.

> Now I understand why lots of top companies here employ external recruitment agencies from the UK.

One of my favourite blog posts of all time is "Don't Feed The Beast - The Great Recruitment Agency Infestation" [1] which describes behaviour very familiar to those who have had to deal with external recruitment agencies in the UK.

Sadly the original post appears to have gone but there is a mirror.

[1]: https://hackerfall.com/story/dont-feed-the-beast--the-great-...

This is why those stupid lists of skills are important to include on resumes.

This is why I explicitly avoid these lists and highlight some core tech which should be meaningful for other engineers. I try to use terms specific enough to implicitly include several skills.

My intuition is that if my CV is ignored by a recruiter, it's because engineering is not involved enough in the sourcing process for the company, and that is a terrible signal.

Exactly my strateguly as well, seems to work perfectly.

Another trick I do is send my CV as a text file with Unix line endings. Engineers would be able to read it easily. Irrelevant recruiters or the HR department, not so much.

Sadly Windows notepad in recent versions of Windows 10 can read Unix line endings just fine, although quite a few businesses have not upgraded yet.

From the other side of the screen, I see a lot of people inside organisation's trying to hire and becoming annoyed when their recruiters send them CVs that aren't ideal matches.

So this cuts both ways. If you want engineering to have eyes-on early, that necessarily means they're gonna see some CVs that don't fit. Recruiters tend to avoid this because of the 'signals' they're getting back from their client.

Relation between engineering and sourcing also works the other way: engineering can teach recruiters to read CVs better.

A minimum would be to have the recruiter explain why they thought the CV was worth a review and the engineer can then correct them.

Also, in the companies I worked for, recruiters where checking GitHub or LinkedIn when they needed more signal.

Agree with this 100%

> This is why those stupid lists of skills are important to include on resumes.

Sure, but it looks like whoever acts as a parser for that stuff is not significantly more intelligent than the grep command with a few basic options.

That's why they need to be included. Companies are using automated systems and/or non-technical HR people to filter resumes. The bigger the company, the worse it is because they get more applicants.

I always list it under my resume skills for this exact reason

SRE is a framework of critical thinking applied to computing.

Our society seems more interested rigidly regurgitating a customized framework and avoiding critical thinking of their own.

It’s better for business, they say, saves money.

This is what folks like Cal Newport discuss in Deep Work, and Feynman meant by ignoring other people’s work. Paulo Freire warned about importing others models.

This feels too much like thinking SRE is some literal thing. Label life stuff in your own way. That’s having work/life balance, IMO.

I don’t want to cart that shit around all the time.

Working in tech in the government, this resonated with me. The author summarized things well. Another problem in my agency is that only HR is allowed to construct job postings. We provide inputs, but they put it all together. I have seen this work against us consistently. We also aren't allowed any variance during interviews. All interview questions must be identical across all interviewees. This rule prohibits follow-up questions. Believe it or not, it is difficult to have a meaningful interview and to properly guage one's experience with thid handicap.

Apologies for errors. I'm on mobile.

The lens is that of an SRE, but what the author is basically doing is applying an iterative improvement process, or learning cycle, or decision cycle. There are many examples of them in many industries. Many of them are used to improve quality, but they can also be used to fix crappy process. I find they work best when implemented asynchronously (e.g. an outsider who is pissed off decides to fix the broken thing, and goes around and helps improve different parts of the process)

Tenth paragraph defines the acronym, "Site Reliability Engineering." Is there enough room to expand that in the title?

In my org, we're technically called Service Reliability Engineers which is internally appropriate and fitting.

I think it's very common knowledge that's what the acronym means. I've never worked at a company that didn't just say SRE

SRE has a lot of different meanings, even in the science & technology world [1]. (I'll refrain from claiming that such is "common knowledge".)

[1] https://en.wikipedia.org/wiki/SRE

Most companies don't have them at all. Not by that name or anything like it, and if they have anyone kinda doing a similar-ish job you'd probably find their role and practices dissimilar enough that you'd not call them that, either.

Never heard of it before.

It's not.

I probably stopped trying to understand what it meant at the 3rd-4th paragraph. I feel I wasn't worth an explanation...

Did you Google it? It's the first thing that comes up.

Google customizes results per the logged in user, so "site reliability engineer" wouldn't necessarily be the first result for different people. Random list: https://www.abbreviations.com/SRE

google made the term popular. there is a book on it that kinda expands on what it entails.

It also stands for Software Reverse Engineering. An example is Ghidra [1]

[1] https://ghidra-sre.org

Very interesting read as I am considering a Grade 6 or 7 Technical role in the UK civil service (right at the top end of the GS scale) and am looking at how they recruit and to tailor my cv to suit.

I am lucky in that I have done board style interviews before and have contacts who know how the system that most UK techies wont have.

I think Marianne ought to touch base with Loren DeJonge Schulman at War on the rocks as She has written on the hiring challenges the US government faces

I thought this was going to be about error-budgeting your carbohydrate SLO in your dietary SLA.

tl;dr: We applied the principles of root cause analysis to a non-technical process (hiring) and it made things better.

You should still read the article though, it has a lot of eye-opening info about how broken government hiring is.

Some more blog ideas:

Can you apply DevOps thinking to things that don’t involve computers?

Can you apply Agile thinking to things that don’t involve computers?

Can you apply the UNIX philosophy to things that don’t involve computers?

The UNIX philosophy comes down to making tools that each do one thing and do it well. It's already the same philosophy as a workshop full of hammers, screwdrivers, squares, saws, planes, etc.

Put them together and you can build a cabinet. But you probably wouldn't want a "cabinet making tool" that tries to do every job required in the cabinet making process.

If anything, all of the philosophies that we apply to computers and technologies are taken from other areas. Of course you can take them back out and apply them elsewhere! Computers are a very recent addition in the grand scheme of things.

https://catless.ncl.ac.uk/Risks/ is a mailing list of people with large numbers of references to these ideas being applied outside the computer context.

Applying agile thinking to everything but software is a cottage industry at this point.

What the hell is SRE?

Site Reliability Engineering