Interviewing the Interviewer

Uploaded with plasq's Skitch!

I get lots of job offers via e-mail, as I'm sure we all do. If your e-mail address appears anywhere near a blog or forum related to programming, you're guaranteed to be on a few dozen spam lists for head hunters. Most of these offers get filed in the bit bucket. However, one landed in my inbox the other day and it had enough of the right words and phrases to pique my interest. It was intriguing enough that I had to stop and ponder how I would follow up on it if I were genuinely interested. I've only applied for a job once in my entire career; every venture since has been through networking. So I started building a list of questions I might ask a prospective employer. I've listed them here for future reference, and so that you might find them helpful or offer up your own...

The Business:

- Give me your elevator pitch.

- What is your product/service?

- Why is it unique or better than the competition?

- Who is your customer?

- What is your revenue model?

- How old is the company? Give me a summarized history.

- How are you currently financed?

The Management:

- How many employees do you currently have?

- How many do you plan to have a year from now?

- How many of those employees are in my department?

- How many of those employees will be reporting to me?

- Who do I report to?

- How many layers are there between me and the CEO?

- What does your org chart look like?

- How much turnover have you seen in the last year?

- What's the overtime situation? Is it a necessary evil you suffer a couple times a year, or is it standard operating procedure?

- Is there a dress code?

The Technology:

- Can you build the system in one click/command?

- Can you deploy the system in one click/command?

- Which source control tool do you use?

- Do you leverage branching with your source control? How?

- Do you use Test Driven Development and Defect Driven Testing?

- Do you have code coverage?

- Do you use continuous integration?

- What tool(s) do you use for project management, bug tracking, documentation?

- Walk me through the process of a new feature from conception to delivery.

- Walk me through the process of a bug fix from discovery to resolution.

- Explain your software architecture.

- Explain your network architecture.

- Which brand of database are you using? Why?

- Where are you hosted? If is fully managed or colocation?

Looking out for Number One:

- Will I have my own office? Will it have a door to close when I need some privacy or peace and quiet? A window for some sunlight? A comfortable chair? A dry-erase board on my wall? Wi-fi, or enough network jacks on the wall that I don't have to have a hub and a rat's nest of wires?

- If telecommuting, what will be our primary means of communication? Skype or cell phone? If I'm using my own account/phone, will I be able to expense our calls?

- Is there travel involved? If so, how often, to which common destinations, and what general duration?

- What's the process of requesting and receiving newly required tools (e.g. replacing a dead hard drive)? Do I buy it myself and submit an expense report, or do I have to file paperwork with somebody and wait for delivery?

- How many vacation/personal days am I afforded? How are they calculated (e.g. set number per year or accrued over time)? Does that number increase with my tenure?

- Assuming this is an on-site job, will I be allowed to telecommute on occasion, at my discretion, when I need to attend to personal matters and schedules that preclude a trip to the office?

- Will I have a budget for books, software, travel, conferences, other educational materials (e.g. Peepcodes)? If yes, what will that budget be?

- Is conference attendance at my discretion (which and how many to attend)? Will the be covered as company expenses?

- When I travel on company business, may I expect my expenses (travel, food, lodging, entertainment) to be reimbursed in full? May I expect to have my own room for overnight stays (no roommates)? May I expect to get "decent" flight schedules (no red-eyes and no there-and-back in a single long day)?

- What will be the schedule for my reviews and raises, based on my date of hire, or first of the year?

- Will I be awarded stock options? Performance bonuses? Quarterly, yearly, or some other schedule?

Brains, Brawn, Charm, and the Checkbook

Uploaded with plasq's Skitch!

Last night I was pondering my tangential relationship with the latest start-up of an entrepreneurial friend, and I harkened back to my history of start-up involvement (roughly a half-dozen in twice as many years) and it dawned on me that there's consistently been four key players at the beginning, each with a pretty clear personality stereotype. As you might have gathered from the title of this post, those people represent the brain, brawn, charm, and checkbook.

The Brain is the mastermind that knows how to turn an idea into reality. He's not necessarily the founder, and in most cases I've seen he's "the tech guy". The founder comes along and asks, "Wouldn't it be cool if we could do X?" and the Brain says, "That's possible, and I can architect it!"

The Brawn is the guy that actually builds it. He's the guy that works eighteen hours a day pumping out mountains of code. In many cases, the Brain and the Brawn are the same person, but eventually, and sometimes pretty quickly, the Brain gets too busy with other business matters and the Brawn title gets passed on to another.

The Checkbook is the guy with the money. I'm not talking about the bootstrapping of the company; the founder usually foots that bill. Eventually the business needs to "step it up" and that requires some big money. That's when the wealthy friend-of-a-friend comes into the picture and writes a nice fat check.

The Charm is the wheeler and dealer. He's the cheerleader for the Brain and the Brawn. He's the seducer of the Checkbook guy. He's the "demo" guy; the sweet talker for partners, clients, and customers. In my experience this is always the founder. He's the guy the brings the other three together, gets the ball rolling, and keeps it going.

Rails Doesn't Scale?

[Originally posted to the AdPickles blog.]

Last month, an old entrepreneurial colleague dropped me a note regarding some speed bumps he's hit while courting potential investors and partners...

"I've heard a few people mention that they heard that Rails doesn't scale [...] any suggestions on how we might alleviate their doubt?"

So I rallied the troops (his two contractors) and we set out on a little informal fact-finding mission. Here's what we've come up with thus far...


How 7 Mongrels Handled a 550k Pageview Digging

Not a lot of in-depth analysis here, just an impressive scaling success story with a pretty bar chart of the traffic load and an itemization of the hardware and software involved along with costs.


It's boring to scale with Ruby on Rails

Granted, this one is written by the man himself, Mister Rails, so you have to take it with a grain of salt, but he hits upon the common themes, which are caching, load balancing, and:

"Scaling the database is the `hard part'"

Unfortunately he gets a little off track in the second half of the essay and goes into the cost analysis of productivity and happiness, which is where you'll lose the attention of most investors.


Scaling Twitter: Making Twitter 10000 Percent Faster

I love the High Scalability blog; it's the dessert of my weekly reading. Granted Twitter still has its problems to this day, but you can't deny its monumental achievement in wide-spread adoption and ungodly levels of traffic. In addition to the aforementioned staples of caching, load balancing, and database optimization, they add partitioning and queueing to the mix.


Engine Yard Bets Big on Rubinius

What does this have to do with the scalability of Rails? Well nothing explicit in the article, but it supports two important movements that will eventually lead to a greater good.

First of all, Rubinius is one of three now mainstream Ruby implementations (the other two being Matz's original and Sun's JRuby). Competition here is good. This means better, faster, more stable Ruby environments, which will translate into a faster and more stable Rails.

Secondly, Rubinius is eventually going to lead to mod_rubinius, which will lead to even more scalability of the Rails platform by allowing us to leave separate single-process servers (like Mongrel) on the wayside.

Personally my money is on JRuby (and Glassfish) for the long haul; if you haven't checked out Glassfish yet, you're doing yourself a disservice!


Benchmark Invests in RoR Provider

Pretty much a no-brainer here. Benchmark Capital invested $3.5 million into Engine Yard, whose main business is Rails hosting.


Riding the Rails with WebSphere

If Glassfish is a little too cutting-edge for you, and you're all about being "enterprisey", then IBM's WebSphere is probably right up your alley.

At this point, between IBM and Sun's support of Ruby and Rails, and the multi-million dollar investments other Rails-based ventures are receiving, I'm beginning to wonder how savvy are these potential investors my friend is getting flak from.

But we're not done yet...


Can Rails Scale? Absolutely!

This article is a pretty good round-up of the more recognizable names using Rails, such as Yellow Pages, Basecamp, and the infamous Twitter, as well as a rehashing of the same old story: caching, spreading the load, and tuning your database.


Friends for Sale Architecture - A 300 Million Page View/Month Facebook RoR App Todd Hoff's picture

Here we are again at my favorite feed, High Scalability, with another Rails scalability success story. This time it's a Facebook app, and a rather popular one at that. I won't spoil the surprise for you, because their is no surprise -- it's the same old story: cache, distribute, and:

"The most important thing we learned is that your scalability problems is pretty much always, always, always the database."

So in summary, there's plenty of good ammunition out there against the naysayers.

How Awesome is it to Work for Me?

WARNING! Gratuitous and shameless ego stroking below...

With my current employer, there are two formal events that call for an employee to comment on my performance as a boss: the end of their hiring probationary period, and their exit interview. Here's a collection of excerpts from both events - recorded by the human resources director and reported back to me - that keep me coming into the office day after day no matter how bad things get:

"Ted runs department smoothly"

"Likes that Ted is a manager but a developer too"

"He would recommend this as a place to work because of Ted"

"Likes the once per week meetings with Ted re[garding] the knowledge of the system"

"Thought Ted was the best in caliber and by far the most knowledgeable person he has every worked with/for" [I swear that's verbatim!]

"Liked when Ted moved on the floor – brought humor and direction" [referring to a time when I voluntarily left my comfy corner office to join my team in cubicle land]

"Said he preferred the B2B team – likes the structure of the B2B build – more cohesive and easier to work with" [referring to the time when I was running the B2B team while somebody else was running the B2C team]