Ask HN: May I sit in on an interview for an ansible-focused role? | Hacker News Reader

Ask HN: May I sit in on an interview for an ansible-focused role?

8 pointslsc6 comments

Chris and I are working on our second technical book; rather than the second edition of "The Book of Xen," we are attempting to write something shorter about Ansible.

Thoughts on how I can sit in on a few interviews when I don't intend to take the job without being rude and/or unethical?

I'd also be super interested in hearing from anyone who has recently interviewed for an ansible-based position.

View on HN

For Ansible questions I mainly asked them to go over existing Ansible task files and explain (to the best of their ability) what they did or might do. This was mostly targeted towards people who might not know Ansible already but have worked with configuration management tools in the past, though.

https://bitbucket.org/_lae/interview/src/master/roles/interv... https://bitbucket.org/_lae/interview/src/master/roles/interv...

Curious to what this book would even be about? Most of the books out there are pretty straight forward and teaches you how to use Ansible (which itself is a pretty simple tool imo)

I have been looking at how McDowell wrote an interview-cram book that became a respected tome on algorithms.

I've been looking at doing the same with sysadmin tools. I mean, I don't know I can live up to her standards, but what I want to teach is easier, too, really. I want to relate the new sysadmin tool-of-the-week to old UNIX concepts in ways that would enable someone who has deep UNIX experience to quickly jump in and at least pass an interview dealing with the tool-of-the-week.

I mean, the latter part of that is going to be a lot of work, but it's not what I'm looking for help with. What I'm looking for help with is the "interview" part; I need to construct real-sounding ansible brain-teasers. And having several different sets of "production workflow" would help, too.

Would your needs not be met by finding Ansible users and interviewing them directly (similar to UX or requirements research)?

That would also work. But interviewing is in some ways fundamentally different from doing the job; Most software engineers aren't going to use most of the algorithms in "cracking the coding interview" except when interviewing.

But... as I said in another comment, a handful of real-world production workflows would also be really useful, and user interviews would likely be the best way to go about getting that.

What are you hoping to learn, Luke?

Reply on news.ycombinator.com