Interview at the Y went really well, and I am quite hopeful. Quick version: the job is on the User Database team (UDB is the thing that stores all the “user data” stored along with a user’s Yahoo account, including customization and settings for most or all of Yahoo’s various features (properties). People I already know on this team are Edgar W. (former AV) and Greg H (former SGI). They seem impressed with my abilities and background. Something like 2 or 3 other candidates need to also be interviewed, but I’m pretty confident we’ll be moving on to the Price Is Right phase soon.

The new resume: I’m a lot happier with it. (link is here). I could probably still use some feedback, but I think it’s already a lot better. I didn’t give it a total makeover — i.e. it doesn’t say “perl coder” on the top line, and “Sysadmin” is still the focus. But, perl coding is in there along with the other things I want to highlight about my career so far. (Thanks to waterowl and bhoneydew as well as others for the excellent advice).

I met: Brian, Ryan, Brent, and Roland. Brian is the sysadmin’s 2nd level manager, and the only one to ask me my current salary (yes, I told him). He asked me why I want to leave SGI, am I OK with being an individual contributor and not a manager, and how do I feel about being on call, a lot, for what seem to be fairly serious numbers of hours on-call work. (In fact all 4 people asked me that). I answered quite honestly that I don’t mind doing the work as long as I feel I have some input to the development and operational structure, and some hope of positively affecting things to be more predictable.

Ryan is a junior-level sysadmin who worked in Noc and Siteops (hardware) before. He warned me that it will take a while to get up to speed and that I’ll likely be doing “routine” requests for several months before I’ll be comfortable enough (and trusted enough) to make changes to things. He was impressed with my amount of experience, though I think I successfully communicated that I don’t mind doing “low level” tasks and taking my share of on-call days. He said several times how impressed he was and that he really hopes I get the offer. I also assured him that I’m not looking to be the manager, but that I do speak “manager” speak as needed :) Ryan also told me that things have gotten better recently and that there is now a team in India that is able to provide a first response during our evening.

Brent is a senior sysadmin and perl coder, probably with experience similar to mine. He was also the only one who gave me a technical question, which was to write a perl script to parse a CSV file and stuff the data into a $hash{“by instance”} = [listref containing hostnames] and another $hash{“by hostname”} = { “rest of” => “data items” }. The syntax was not exact in my written answer but I effectively demonstrated ability to write perl from scratch, reg exp pattern matching, and understanding of where he was going with the data structures (which could probably have been done as a bunch of named hashes, but the hash-within-hash was probably more elegant and extensible). Anyway I kept writing until he said “Ok, that’s good enough”. Then I showed him some of the sample scripts I brought with me :)

Roland is the sysadmin’s immediate manager and his questions were the most interesting and also the most abstract. Some were predicatable, like am I really sure I’m OK being on-call, and not being in a manager position. (Answer: Yes it’s OK as long as I have some feedback in fixing underlying issues, and No, don’t need to supervise others, though I may still do leadership-type things like training, mentoring, project mgmt etc.)

He also asked what qualities I look for in a manager, or what makes a good manager, and I said definitely communication, to some extent trust, but mostly I want someone with good listening skills (which I prided myself on when I was managing others) and who will go to bat for the team. I also explained my theory on the power of WE, meaning that if someone screws up, “we” screwed up, and pointing fingers at specific people should happen behind closed doors, so that the team builds solildarity and trust in each other.

He also asked a couple questions that seemed cryptic at first: have I had to deal with a situation where I didn’t completely understand all the context and interoperation of things (yes, gave an example from early AV of finding a bad config file and fixing it, only to find out that the “bad” config file was being pushed from another location). This was followed by how I would approach a problem with a program (such as a client/server listener bot on a certain port) that works on one machine but doesn’t work on another (I gave several suggestions such as adding debug output directly to the script, telnet direct to the port to see what’s going on, examine nodes for different files or dependent files, etc). The final question tying those other two together was: How do you deal with something that’s basically a “black box”, which you don’t understand how it works exactly (basically, it’s magic) but you still have to make changes to it. I gave an example where I had to deal with something that I wasn’t able to examine: third party appliances such as Cuda spam where all we see is a web interface, and yet there’s something going on under the hood that’s wrong and you have to be able to understand what the problem is so you can describe it to the support guy. I also gave him the QA/troubleshooting standby of “change one thing at a time and remember what you changed”. Finally I gave him an example (spam bounces) of a situation where we had a half-assed bandaid solution up quickly and bought more time to come up with a better, more complete solution.

He spent some time talking to me about the history of UDB and how it just keeps growing, in number of requests as well as size of the data. There have also been some engineers on the Dev side that left UDB mostly because they were tired of saving the world and then being asked to get blood from a stone again. (Which is why there’s a bit of “black box” or even “f*ing magic” in the system now and nobody understands it completely, which also explains the questions about black boxes).

Finally he asked me a couple more questions about my comfort level in how much communication to provide managers… I said that my theory is that most managers at director level and up want two things: timely heads up so they don’t get surprised, and to be able to scratch the surface a little bit and make sure there’s some intelligent details under the surface here and there (usually a random sampling). I also explained that my usual response to getting too much attention from manager (or higher) is to turn it around and become even more proactive, providing the answers to anticipated questions before they come up, and then when the trust is built up again, the scrutiny usually eases up. I also mentioned that it’s important to be consistent as well as proactive (if possible, point managers at a web page where the info they need is always there, so they don’t even have to ask if we’ve done a good job publishing).

I’m sure there’s a bunch of questions I’m missing, but most of it is here. I feel good and confident about this… I just hope the price is right!

Thanks, friends, for all the support and well-wishes.