1. for folks with no “real” experience yet, I ask them to rank themselves on a few key technologies on the “Google scale”
• the range is 0..10 where a 0 is no knowledge, 1 is some, 10 is “you wrote the book”, 9 is you could’ve written the book, or you edited/contributed
• on a few occasions, I have had folks ask to change their ranking from their initial [overconfident] statement to one that is much closer to inline with their true experience/comfort/knowledge level – and that’s OK in my book – honesty is always the best policy here
2. a couple quick “about us” questions – open-ended inquiries that let the candidate tell me what they’ve done for work
• this verifies their resume
• gets them warmed-up for the rest of the call
• allows the candidate to brag on something
3. perhaps a couple quick probes to find out more about a specific experience
4. a few basic / intermediate questions to assess candidate’s technical chops (ie, verify that their resume is accurate)
• this goes along with my personal rule of “never put anything on a resume you don’t want to be asked about”
5. open-ended, intentionally-vague questions to gauge problem solving ability, and methodologies
• see how they go about refining the problem statement (if at all)
• gauge estimation skills
• gauge teamwork and delegation aptitude
6. a few intermediate/advanced questions about an area they *don’t* know anything about – to gauge their response to unfamiliar/stressful situations
• in my field in particular, it is impossible to know every new technology or even (probably) to be truly 100% aware of those that you do use every single day
7. a few intermediate/advanced questions in their now-articulated fields of expertise (presuming I have any)
• this verifies more of their stated (and unstated) job experience, and helps determine at what title/work level they should start
8. lifestyle/workstyle questions
• how much they enjoy travel
• how they handle last-minute demands and “requests” by customers and management
9. a few questions to gauge flexibility of response to changing requirements
• for example, switching a project from being Solaris-based to Windows-based part way into implementation because a new CIO has come in, or new licensing is available, etc
10. open time for them to ask me whatever they may wish to know that I can tell them
• this usually ends-up being very short because the candidate was stressed-out over the interview, and can’t think of anything about the company they want to know on the spot

What I try to NEVER ask:

• “trivia” questions – I bet there are C questions even K&R couldn’t answer

• I guarantee I can ask you a question about your area of expertise you cannot answer…just like I guarantee you could do the same to me
• since that is the case, trivia questions are pretty pointless, and more of an ego stroke to the asker than anything else
• pointless “MindTrap“, lateral-thinking questions

• riddles are fun – but only add to the stress of the interview
• pointless problem-solving and estimation problems

• for example, “how would you move Mt Fuji”, “why are manhole covers round”, or “how many gallons of water flow into New York Harbor from the Hudson River per hour”
• estimation problems are wonderful tools and games to play, but not in an interview
• illegal questions

• sometimes they slip out, but it’s never intentional

I adjust my questioning to fit the situation, timing, and candidate responses – so it’s [somewhat] different every time.

When the interview is done, I write-up my evaluation of the candidate and send it on to the hiring manager. In line with Joel Spolsky‘s “Guerilla Guide to Interviewing“, I make sure to put my firm conclusion of Hire/No-Hire near the top, and again at the bottom – with my reasoning in between.

One thing I have noticed about almost every interview I have ever taken or given is that I end up learning something in the process – and not just about the candidate (or company). It’s important to listen to both how and the candidates responds to questions, and what they say.

So, if you ever get the chance to interview with me, you have an idea of how I’m going to run the show

However, to go back to my friend’s point, he asked how an assert can “benefit someone that is running the application”. The short version is that NO ”error message” that is in the frame for a developer will [likely] benefit the person “running the application”.

David Pogue wrote about this more than a decade ago, but it’s something that still has not taken-hold in most applications: the human-friendly error message.

The C Compiler in MPW (a Macintosh programming tool kit) gives you messages like this: “You can’t modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler.” Or this: “Type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11. (I know you don’t care, I’m just trying to annoy you.)” Or how about “This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn’t wide enough to read this whole error message.”

The BeOS‘s native browser, Net+ (pronounced “net positive”), had amusing error messages – in fact, it was those amusing messages that spurred the name of the OSS reimplementation of BeOS, Haiku.

For instance, a user might see the following error message if they try to access a website that is unavailable:

Cables have been cut

Southwest of Northeast somewhere

We are not amused.

If the user tried unsuccessfully to authenticate against a website, they might see:

Server’s poor response

Not quick enough for browser.

Timed out, plum blossom.

One you might see, however, in a product I use frequently:

2011-09-08 19:03:58,590 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: checkbox_key
handler: org.apache.beehive.netui.tags.html.CheckBox$CheckBoxPrefixHandler
2011-09-08 19:03:58,591 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: checkbox_group_key
handler: org.apache.beehive.netui.tags.html.CheckBoxGroup$CheckboxGroupPrefixHandler
2011-09-08 19:03:58,592 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: radio_button_group_key
handler: org.apache.beehive.netui.tags.html.RadioButtonGroup$RadioButtonGroupPrefixHandler
2011-09-08 19:03:58,592 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: select_key
handler: org.apache.beehive.netui.tags.html.Select$SelectPrefixHandler

Gee, thanks Apache!

Compare that with Google’s Chrome browser that puts a frowny face on a file folder and says “Oh Snap!” when something goes wrong (whether it’s the browser’s ‘fault’ or not).

So why don’t more applications come with “friendly” error messages?

Part of it is because developers too often are concerned with getting something shipped (shipping is a feature, after all), that they don’t stop to consider who is going to actually use the software.

User. The four-letter-word of the development community. Developers all too often (I’m as guilty as anyone on this) of forgetting that what they are writing is for someone else to use. Not for them to work on, debug, develop, extend, and futz with. No, it’s to use.

The average user doesn’t care that some component interacted in a bad way and caused a stack trace… they don’t care that there even are components and stacks to trace!

It takes conscious effort to write message people can care about, or at least understand. And it’s not because the userbase of a given product are dumb: they’re just not developers. Doctors surely are not dumb as a group, but that doesn’t mean they’re qualified to understand a stack trace on the EMR system.

Developers need to take a step back from their work and remember that there are other people in the world beyond just them, and if the more easy and friendly a system is to use and interact with, the more likely people are to want to use it – which might just keep them employed

Apple as $70 billion in cash on hand.

Google is buying Motorola.

I think Apple should buy Sprint. And they should stop distributing the iPhone via Verizon and AT&T in the US.

• guarantee a distribution channel for media which Apple proffers
• boost Sprint’s value
• accelerate the deployment of 4g (and better) network technologies (a la LightSquared)

It would also give, in my opinion, a strong leg-up for Sprint on their suit against AT&T’s proposed acquisition of T-Mobile.

Terms and phrases we all hear and pretty much pass over in our day-to-day lives. Right up until we want to move to a new/better job or performance reviews roll around.

But what do they mean, and how can you advance your career (presuming, of course, that you want to)?

This is by no means an exhaustive list – indeed, I’d appreciate any other ideas / feedback / improvements y’all may suggest

For a software developer:

• be the documentation KING of your code – if it’s not right, make it right
• own every bug in your code – even when it’s not “yours”
• be The Guy™ who learns a new component of the code/product (at least conversationally) every few weeks
• write at least one tutorial a month on the internal wiki/kb about something you found or did with the code
• write at least one tutorial or similar a month externally (maybe a personal blog) in a general fashion about something you learned or did

For a systems consultant:

• be the documentation KING of every project you work on – make ABSOLUTELY sure the next guy can do more after you leave
• own every issue you find, even when it’s really somebody else’s problem (no throwing it over the fence)
• the The Guy™ who learns something new about the environment or product every couple weeks
• write at least one tutorial a month and/or give an overview talk of something you learned/did
• write about what you’ve done (changing names to protect the innocent) on a blog or elsewhere
• teach as many people as are willing to learn what you know (in your company / on your team / etc)

Focus – decide where you want to be, and plot a course to get there.

Finally, NEVER make yourself “irreplaceable” – the instant you make yourself irreplaceable, you also make yourself unpromotable: after all, if you’re the Only Guy™ who can do your job, why would your boss/manager/supervisor even think of moving you into a new role?

^{As a side note – if you’re ever working at a customer site, don’t take calls from anyone other than the customer while you’re at your desk/cube/workspace: even if it’s project related, take it in a different room}

The Itanim should have been Intel’s chance to totally walk away with the processor market – but they blew it by totally breaking x86 compatibility, and not in a good way: their bungle allowed AMD to develop the x86-64 extensions that are now ubiquitous – even on Intel’s own processors (though they call them EMD64).

With the multi-core industry in full swing, Intel has a chance to make the Itanium relevant once again – package it along side x86-64 cores in a new CPU, a la IBM’s Cell processor.

With Microsoft now looking to branch Windows onto ARM with Windows 8, the x86 architecture is no longer the only [major] game in town.

If Intel were to co-package the Itanium and x86 cores on one chip, or at least in one package, they could start to reap the benefits of both worlds – keep the high-end, “mission critical” market they have that lives on HPUX (though “mission critical” and “HPUX” don’t jive in my head), and bring into that realm the x86 world.

Hey, it’s a thought.

Novel idea, isn’t it? The typical Support team is driven by stats – the number of tickets in their queue, age of the ticket, number solved/closed, number escalated, etc. Support is driven by these numbers because managers don’t think of any better way to do it.

All things being equal, if you can close 40 cases in a week, that’s a lot better than your podmate who “only” finished-out 12. But what about the complexity of each of those cases? And how much effort did each engineer put into them? Did the customer come back and ask for it to be closed because it’s either no longer an issue, or they solved it themselves? Is it a question that can be answered with a reference to a specific page/section of a manual? Or was it a problem that took multiple webex engagements, and dozens of contacts back and forth to find a solution because it was a deep bug?

Theoretically, the goal of “support” is to, well, support - get the problem reporter a solution of some kind they can use. That solution may be a bug fix, an RFE, a reference to a tutorial, reconfiguring, or a work around / alternative approach to their problem. A big problem with this setup is that the reporter rarely asks the right question. They ask what they have pre-determined to be what they think is a question – but by biasing their initial report, they can often end-up dragging-out the solution process far longer than it should take. I recently wrote a guide on creating effective support tickets, based on my experience working in support, and interacting with various support organizations both before and since.

Reporter bias is the hardest issue to overcome, in my opinion; engineer bias is easier to get past because (hopefully) there are folks you can bounce the problem off of in the team who can help narrow-down the problem and find a solution … or at least figure out where to try looking next.

Communication is the key to solving problems – when I was at Opsware we utilized internal IRC channels and (gasp!) talking with each other to try to find solutions to customer issues. We also spent a lot of time wording inquiries to the reporter to try to gain as much information as possible on each iteration of the communication process.

Another key to solving problems was to make records of cases with the following:

• initial reported behavior (or lack thereof)
• actual problem
• solution

Those records were sometimes on wiki pages, sometimes in our Plone internal KB, and sometimes got “promoted” out to the customer-facing KB. All of these approaches helped us get problems solved faster – either by offloading the “work” to the customer (via a KB reference), or by being able to apply previous answers more quickly when new-but-similar/identical problems were reported.

The end goal of a support team is not to outdo one another on how many cases one engineer has in his queue, or how many another has closed – the end goal is to solve customer problems. “Works well in a team setting” is a qualification typically associated with support engineering employment listings – but all too often that gets reduced to a cliche that practically means “tries to outdo his cubemates by closing more cases than the next guy”.

I’m as much a fan of personal responsibility and action as the next red-blooded capitalist, so don’t take this next section to imply I’m promoting communalism.

The way a support team should work is the way [good] sports teams work, or the way a Nascar team operates: yeah, it’s the driver of the car who gets the “glory”, but without his pit and maintenance crew, he’d be no better than you or I going to the grocery store. Any given support engineer gets to have his name tagged to the case for posterity – both with the good things he did, and the not so good ones. But since the goal is really to get the customer’s problem addressed, the ego of the engineer needs to be removed from the equation.

Bob Smith might be “the guy” who informed his customer of a solution, but generating the solution involved the other 7 people in his office. He gets the “fame” from Universal Widgets LLC, but he was just one of the [important] cogs in the process of resolving the issue.

The number of cases Bob has in his queue should have [almost] ZERO correlation to his skill as an technical engineer: it’s the 7 people behind him whom he can ask and brainstorm with that get the job done.

Maybe Bob gets to handle most of the “customer” action, but the other 7 are writing bug reports, solutions articles, etc. When evaluating that team, management needs to do just that: evaluate the team first, and the individuals second.

What would need to go into an assessment tool for a virtualization initiative?

A:

Typical factors may include:

• current CPU load per server
• what’s running on each server
• current hardware of each server
• expected percentage increase in usage
• OS usage – homogenous or heterogeneous
• new hardware or re-use current hardware
• storage needs
• vendor for virtualization (VMware, Microsoft, Xen)

And don’t forget the all-important:

• BUDGET

My experience is all related around VMware, but what I’ve seen and used in the past is the following:

• look at all CPU utilizations currently
• add those average and peak percentages in two separate columns
• plan for ~10% overhead from your hypervisor of choice
• for every 40% of ‘average’ or 80% of ‘peak’, use one server of the type you now consider “high-end” (ie, if you have a total of 687% of ‘peak’, you need 9 physical servers running your hypervisor of choice)

Other thoughts:

• I like to plan for 1 full spare physical server per ~6, so that I can utilize Vmware’s Vmotion for migrating servers around
• plan for buying/utilizing SAN storage of some form so your VMs can be moved to different physical servers easily

^{_{I originally answered this topic ~2 years ago on serverfault.com.}}

He asked about where to find “mini” packages of laundry needs.

Here’s what I do, I hit the dollar store if I’m going to be somewhere more than a few days – $3 and I have detergent, bleach, and fabric softener.

I wonder what folks would think if car manufacturers put more-powerful computing components in their cars, and while the vehicles were driving around, they contributed to something like Folding@Home? When the vehicles were within range of either an open hotspot, or if they used some “catch-all” cell internet service like the Kindle does, they could be checking-in their work frequently.

Ignoring the obvious privacy invasions this will add-to (if your cell phone is on, it’s trackable already – so having your car on means squat), this could be an interesting revenue stream for auto manufacturers: sell the vehicles to consumers for less money, but then rent time on their computers to folks who need massive computing resources. Of course, the buyer would have to agree, and there needs to be a way to opt-in/-out. But it’s still an interesting idea, I think.