Operation Learn about Operations!

September 15, 2007 7:12 AM

NewJobFilter: I'm a programmer with some phone interviews next week that I'd like to be prepared for. I'm up for some non-senior coding positions on site reliability, infrastructure and operations teams with a few different top ten internet companies. Any tips on what I should brush up on before I'm on the phone with some expert?

I'm a young guy with a CS degree from a good school, and have worked for the last few years for a few medium-sized web companies as a backend software developer, mainly programming in C/C++. I've certainly done infrastructure design, but my jobs have usually not required too much thought about what needs to happen when something bad happens at the datacenter(s) at 2am (read: I've never had to wear a pager, and some of these new jobs may require that from time to time, despite not being a proper "sysadmin").

So, any tips, anecdotes, or resources describing best practices I should know about? Supposedly they'll be running operations scenarios with me over the phone, and while I think a lot of the answers will just come as common sense to a decent programmer I'd like to be prepared.

I tend to do pretty well with phone interviews when I have some idea of what may be asked of me, so let's not worry about the general phone interview tips like "stand up and walk around while you're on the phone" and "smile, you'll sound more confident!". You can comment here or drop me a line at [e-mail]

posted by anonymous to Work & Money (3 answers total)

Be prepared to answer questions like:
- describe how you work in a team
- describe a project you worked on that was a success
- describe a project you worked on that failed

Resist the temptation to trash other anonymous coworkers if they played a part in a project failing or not going well. Find a way to describe even negative situations as an opportunity for professional growth.

Be prepared with intelligent questions about the company. They will ask you if you have any questions. Good questions are those that demonstrate that you understand where the company sits in the marketplace, what its current projects and challenges are, etc. Reviewing the company's news releases and its major product lines will help you come up with good questions.

Because you are an implementer, it is appropriate for you to ask about design decisions in their products, but only if you are familiar enough with their products to do so without looking stupid. If you have never even seen their products in action, don't go down this road because they will quickly assume you know the product well and may fire back with a complex follow-up.

Bonus points if you also know about competitors' products and upcoming releases. If you can ask a question about why Feature A from Competitor A's product isn't in your employer's product (keeping in mind the guidlines I typed above), it shows that you are aware of and interested in current market conditions.

Good luck. Be flexible. Don't be afraid to admit that you don't know something. After all, you're entry level. If you get stumped, the best answer is that you don't know but are interested in developing your skillset in that area.
posted by rachelpapers at 9:18 AM on September 15, 2007

- Quite honestly, no one can really give you a list of "x" number of best practices - because your & prospective employer will have different experiences and history that may make them irrelevant.

So, onto the generalities:

- Don't lie, if you've never done something before - then don't pretend you have.

- Do not hesitate to simply say: "I don't know" if you feel comfortable, add: "but, I will follow-up on that and get back to you" - then DO just that.

- What do you do to keep current? Magazines? Books you have just read, blogs, technical communities?

- Beforehand think about what type of "hairy" debugging sessions you've had to be involved with - what strategies, tools and techniques did you use to solve those issues. Definately if you will be supporting applications in production as a programmer occasionally wearing a pager they will be interested in your analysis, diagnosis and "behaviour under stress" skills.

- Have you done crash dump analysis? What tools? It is very rare to be able to debug live code in a production environment, so typically we rig things up to produce full crash dumps and then analyze them "off-box".

- If they present hypothetical support issues - ask what options/contracts the company has for outside support - it never hurts to call a vendor, some even have whole account teams dedicated to ensuring things keep working ;-)

(Guess what I do, eh?)

- Relax.
posted by jkaczor at 9:29 AM on September 15, 2007

What's the difference between robustness and high availability? What about fault tolerance?

As a developer, what can you do to keep planned downtime to a minimum? Unplanned downtime?

Can you give examples of what important items must be considered for disaster recovery scenarios?

Wikipedia provides decent info on all these items and it might not hurt to prepare a few checklists for any of these if you aren't comfortable.

Good luck!
posted by furtive at 11:12 AM on September 15, 2007