At any rate, the good news is that we’re hiring.  Job descriptions below – if you know someone that might be a good fit, I’d certainly appreciate any referrals.

Immediate opportunities (details for each are down below):

• Enterprise Project Manager
• Network Administrator
• System Administrator
• Business Analyst
• Java/J2EE Developer

StarPound provides an on-demand, open-source platform for enabling large enterprise customers to design, deliver and adapt communication-enabled business processes. Additionally, we provide an entire PBX and call center suite built on top of our core platform.

Successful candidates must be comfortable wearing a lot of hats in a fast-growth, emerging startup company (venture-backed).  And, they must be passionate about your job, and willing to do whatever it takes to be successful.  If you are interested, please visit our website (www.starpound.net) or contact Dottie Thornton via email with your resume (dthornton at starpoundtech.com).

Enterprise Project Manager

Requirements:

• Project reporting, monitoring, and milestone success on complex enterprise projects
• Experience within contact center, CRM, telecommunication services, or e-business industries is desirable
• Experience with web services, web integration is a plus
• Leadership and mentoring experience.
• Minimum 7 years relevant project management experience required.
• Excellent communication, presentation and interpersonal skills.
• Strong organizational and time management skills.
• Project Management professional (PMP) Certification a plus
• Bachelor’s Degree or equivalent Project Management work experience

Network Administrator

Requirements:

• 3+ years of professional experience in networking field
• One or more of the following industry recognized certifications (or equivalent experience)
  • Cisco CCIE (R/S, SP, Security, Voice, Storage)
  • Cisco CCNP, CCIP, CCDP, CCSP, CCVP
  • Juniper JNCIE (M/T, ER)
  • Juniper JNCIP-MT, JNCIS-M/T, JNCIS-ER, JNCIS-FWV
  • Foundry FNCNE, FNCNP
  • ISC2 CISSP
• Deep Expertise in at least one of the following areas:
  • Data Center Network Architectures and Design
  • OSPF, BGP, MPLS, QoS
• Highly Desirable Skills:
  • Advanced understanding of IP/MPLS communications theory, design and functionality – Advanced understanding of VoIP technologies, such as H.323 & SIP
  • Experience designing and implementing QoS standards and technologies across platforms to ensure strict service guarantees (SLAs) for Voice and Video.
  • Strong working knowledge of network management and testing tools (at a minimum ethereal/wireshark)

System Administrator

Requirements:

• 3+ years of experience required
• Linux, MySQL, load balancing routers
• Asterisk, shell scripts, cron
• Distributed architectures, Fault tolerant clustering
• SIP, telephony experience a plus
• Performance tuning

Business Analyst

Requirements:

• Experience within contact center, CRM, financial services, or e-business industries is desirable
• Minimum 3-5 years relevant experience required.
• Excellent communication, presentation and interpersonal skills.
• Strong organizational and time management skills.
• Experience with CRM systems and processes is desirable.
• Experience with process modeling tools is desirable.
• Must have strong experience with J2EE Middleware
• At least a basic understanding of BPMN

Java/J2EE Developer

Requirements:

• 3+ years of experience required
• JBoss, MySQL, JSF, Struts, Linux
• GWT, WSDL, XML, Eclipse plugin development
• Asterisk, VoIP, SIP, PBX, ACD, IVR, CTI
• VoiceXML, UML, BPMN, Model-driven development

Cheers.

FYI – we are hiring engineers against the profile below. If you or someone you know is interested in working in a cutting-edge Atlanta-based game studio, we’d welcome the opportunity to chat. PlayMotion is an exciting young company, and one that enjoys a marquee client list, including Atari, Nike, Google, Nokia, AT&T, Disney, Red Bull, and others.

Position: Experience Engineer (software)

PlayMotion is seeking a skilled software engineer to create computer vision-based entertainment experiences. PlayMotion creates a large spectrum of interactive entertainment experiences ranging from full-body interactive large displays (projected, LED, etc) for 3-8 players to large networks of massive screens capable of entertaining 250+ guests with games and artistic experiences. In addition to full-body interaction, PlayMotion works with kiosks, novel input devices such as wands, large multi-touch displays and auditory displays. Rather than calling our software creations videogames or toys, PlayMotion uses the term “Experience” to describe the variety of works we produce.

As a PlayMotion Experience Engineer, you will be responsible for the software design and programming of PlayMotion experiences. The task at hand is to write well-designed videogames using our SDK (Python-based, uses Panda3D engine) and our custom C++ based platform. You will work with a small team including Experience Designers and Engineers to create experiences that balance fun, laughter, challenge, visual beauty, and reward… for both single-player and large multiplayer (50+ simultaneous players) environments.

You must be proficient with the following tools and languages:

• Python
• C++
• OpenGL and Direct3D
• Networking (Sockets, or higher level API)
• Multithreading (OpenMP, Windows Threads, Pthreads, etc)
• Windows programming with MS Visual Studio

Above all, we value smart, creative, and driven people with a desire to learn new skills and the tolerance, tenacity and patience to function in a rapidly mutating work environment, dealing with world class customers and major installations.

Relevant skills include:

• storytelling & storyboarding
• foundation in design
• 2d design: PhotoShop & Illustrator
• videogame design

Helpful background experience:

You will work closely with a highly skilled team of visual effects and computer vision programmers, who create the engines upon which you design your experiences. You will also manage interactions with third party content development studios and contract 3d, 2d, and sound artists.

Please visit our website at http://www.playmotion.com in order to see examples of the types of content experiences you will be creating (and beyond!).

If you feel ready, please send your CV and work samples to:

PlayMotion!
ATTN: FunLab Studios
100 North Point Ctr E, Suite 305
Alpharetta, GA 3002

Cheers.

I will admit this up front – this post is going to ramble a bit.

At one point in my career, I was guilty of this as well. I was poking around some old boxes here in my office the other day, and I came across some of old interview notes I made on several candidates. Here are some examples of questions that I used to ask of senior level C/UNIX programmers in a job interview:

What does the use of the raise() system call accomplish?

What is the difference between the dup() and dup2() system calls?

Given only a shared memory key and shared memory flags, how can you attach to a shared memory segment if you do not know the size?

How (specifically) can you install an ANSI-compliant, unreliable signal handler?

I’m surprised that (A) anyone passed my interviews (surprisingly, a few folks did), and (B) that I had the ridiculously narrow view that all “good programmers” memorized every little niggling detail of every system call and library function available to them. I should point out that the ones who did actually ace those old interviews usually turned out to be very strange workmates. Think about that for a second, and we’ll move on.

While a certain amount of detailed questioning is useful, it really isn’t an all-encompassing way of measuring a person’s potential value to your organization. Sometimes, the best answer of them all is simply knowing where to turn to find out more. This is one of the first things they teach you in the consulting world. When placed in a new client situation, it isn’t important to know the perfect answer on day one. Instead, the focus is on understanding what the problem is, inventorying the assets that you have available to you, and then filling in the gaps on-the-fly. I am reminded of one of the unofficial mantras of the U.S. Marine Corps: “Improvise, Adapt, and Overcome”.

Now for some jobs, being able to readily and completely recite the answers to life, the universe, and everything (a la Douglas Adams) is probably a handy skill to have. Say, for instance, a nuclear physicist. However, I am not a nuclear physicist, and I doubt you are either. So, read on.

One of my original mentors, Russ Miller of The Knowledge Tree, used to quip:

To be a good computer programmer, you simply need to know three things: One, what the data looks like. Two, how you can access the data. And three, what to do with the data once you get it.

Reduce it to the simplest form, and research the things you already know. The rest will generally work itself out. Russ Miller’s simple little rules have always served me well.

Instead of asking those granular questions I listed above at the beginning of this article, I should have been asking questions that focused on their accomplishments, work ethic, and programming philosophies. I should have focused on discovering their aptitude, and not every facet of their skillset. Thankfully, I learned this lesson a while ago, and now have a much more “balanced” approach to conducting technical interviews.

Sure, I want to know whether or not this person can “walk the walk” from a technical standpoint. However, I am equally interested in cultural fit, critical-thinking and problem-solving skills, communication style, and passion/commitment levels. In fact, if the truth be known, I would rather have someone with more of the soft skills, and raw aptitude. I can teach you library calls and syntax. I can’t begin to teach you how to communicate effectively, or how to find the path of least resistance. But I digress.

Back when I was a technical instructor I used to constantly reinforce the utility value of the single most important UNIX command/tool available: The man command. For those of you not familiar with UNIX (or Linux, BSD, et al), the “man” command allows you to access the online “manual” pages. Think of it as the UNIX equivalent of the F1 key in Windows. You can find out just about anything related to the operating system, tools, libraries, etc. with one single command. Nice. And if you don’t know what you are looking for, but you know what you are trying to achieve, the “man” command allows you to search based on keywords as well.

Instead of asking a UNIX programmer to recite all of the possible arguments to the ioctl() system call, I simply ask them to tell me what the single most important UNIX command is. If they say anything other than “man”, I start to question their ability to improvise, adapt, and overcome, as it were.

By the way, the above is a great tip for you junior UNIX techies out there. If you are ever asked a UNIX-related question that you are not sure of, just respond that you would look up the answer using “man.” Nine times out of ten you’ll get a pass.

You don’t know the answer to everything. No one does. The good news is, you don’t need to know the answer to everything. You simply need to know where to go to find the answer. Do you know where to go to find the answers you seek?

Cheers.

The other day, a colleague of mine forwarded a rather interesting Atlanta-based CIO opportunity. This particular opportunity was for a $20-25M logistics company focusing on the railroad industry. One of the key requirements was some experience working within either the logistics, railroad, or supply chain industries. Since I have some supply chain experience in my background, I thought I would toss my name into the proverbial hat and learn a bit more about what they were doing.

Now I should point out that from what the job description stated, this firm needs some serious help. They’ve gone from $6M to $25M in 4 years, and as a result of that rapid growth, their technology systems are, well, quite “varied.” They have 5 different platforms, and my guess is, its all held together with bubble gum and bailing wire. Hence, their need for someone to come in and straighten out the mess, and position them for growth by consolidation and migration.

I sent the recruiter a nice but succinct introductory email, along with my resume. She replied to me several days later with a rather interesting email. In this email, she pasted a lengthy questionnaire, along with some instructions.

I took a quick look at the first few questions, and they seemed routine enough, so I thought I would take some time to compose a nice response. Given that recruiters can quickly become overwhelmed with candidates (and also having personally hired hundreds of candidates over the years), I completely understand the various screening techniques that they use.

NOTE: Be sure to ANSWER all the questions below, as well as:

*where you LIVE NOW…local Atlanta candidates will be given FIRST consideration!!

*when you are available to interview,

*when you are available to start and

Your MINIMUM annual salary requirements.

NOTE:
** Experience in transportation, logistics, rail, distribution or supply-chain industries is absolutely required for this position.If interested, write back with the number of years of experience and a brief explanation of that specific experience in each of the following:

# Years in logistics software (name of software)
# Years in supply chain software (name of software)
# Years in railroad
# Do you consider yourself an expert in Microsoft Project, Excel, Access, Word, PowerPoint?
# EDUCATION: from where? in what?

Please go through this technology…and let me know how much experience you have in each:
# .Net
# ADO
# ADO.Net
# ASP
# ASP.Net
# BCP
# BEAM Resources
# C#
# COM
# Crystal Reports
# DTS
# HTML
# IIS
# JavaScript
# MDX
# Oracle Database
# PowerBuilder PFC
# SQL OLAP
# SQL Server database
# VBScript
# Visual Basic
# XML
# XSL

**NOTE: Also be SURE that if you have a particular experience from the above listing..that you have reflected that technology under the specific job(s) where you used it on you resume…not just in your technical skills section!

Trust me when I say that you don’t need to know how many “years of experience” a CIO has with HTML, or whether or not they have direct experience in two dozen other technologies (which is what this questionnaire asked). Technology executives need to understand 3 things about a given technology: what it does, what it costs, how it integrates. They don’t need to have memorized all of the attributes of HTML table tags or CSS options.

In order to make this post a bit more fun, I sent this job description to a retained executive recruiter who is an associate of mine, and asked him to rewrite the job description. This is what he sent back:

———————

Scott, this one is bad. Real bad. Very unprofessional.

First, we push our clients to write the job description. That way we can validate what they asked for. However, probably half we have to write for them.

Couple of things to look for at first and avoid …

1. Any job opportunity with out a compensation range is a red flag
2. Any job opportunity which point out negative aspects of the job – “Downtown” , “fallen by the wayside”
3. Any C-level opportunity that talks about parking dollars or riding Marta hints that it is very small
4. Any C-level opportunity that list detailed low level requirements that our required

The following is a big sign that this is being handled by a non-executive recruiter:

Also provide me with your availability to interview, when you would be available to start and your minimum salary requirement. When you are available to interview, when you are available to start and Your MINIMUM annual salary requirements.

OK here goes the rewrite. This is difficult because I don’t know what the client is really looking for …

Position: CIO
Location: Atlanta, GA
Compensation: $150k-$200k
Summary:

A world-class provider of Logistics and Supply Chain software products is looking to fill a CIO position. This client provides Logistics Management and integrated Supply Chain tracking systems to customers on five continents. The client has been in an accelerated growth mode and is looking for a leader who can set strategy and bring structure to an organization which has grown very rapidly. The CIO will be responsible for an organization that manages a variety of technologies such as … Visual Basic, Crystal Reports, .Net, Oracle, IIS and ASP, PowerBuilder/PFC, XML, XSL, JavaScript, VBScript, HTML, and DHTML.

Requirements:

• Experience in transportation, logistics, rail, distribution or supply-chain industries is needed
• Experience setting IT Strategy
• Experience consolidating multiple IT platforms and architectures
• Experience reorganizing and motivating IT organizations

If you are interested or know someone who might be, please call us at …
————-

What a difference!

At any rate, this is what can happen when you let a body shop staff your CIO role. If you are in the market for a CIO, CTO, or some other technology executive, you owe it to yourself to partner with a recruiter or firm that specializes in handling executive-level hires. Retained firms are the best, but more expensive. Many contingency-based firms can also handle your requests with skill and care. If you insist on going with a body shop to find your CIO/CTO/Tech VP, take some time to review their process – make sure that they are looking for the right things – the things that will matter to you in the end.

By not doing so, you run the risk of running off decent candidates, and fostering the perception that your firm isn’t serious about its executive-level technology hires.

Cheers.

A plumber provides a service, much like a CIO. The plumber is there to support you in your operations, not tell you how to run the convenience store. A CIO is also a service provider, albeit an internal one.

One of the things that I have noticed is that CIO job descriptions are often crafted under the same guidelines as other executive positions (sales, operations, finance, and marketing). First, they want the skills – okay, this is obvious. You have to know technology. In addition to that, however, they often want domain expertise – generally, deep domain expertise.

For a CFO, this makes sense, as each business and industry has different financial treatments.

For a COO, this also makes sense, as each business/industry can have a varied, complex, unique operational model.

For a CMO, again, this makes complete sense, as each industry tends to have its own marketing demographics and quirks.

For a CSO (sales), this also makes perfectly good sense, as you want to tap into their industry relationships to capture sales.

However, technology can be a slightly different animal. It is most often an enabler, and not a vertical leg. This isn’t always the case – so before you send in a comment to this post telling that there are exceptions to this – I agree!

There are basically two types of CIOs. The first works in an organization where technology is the core of the business – the core competency that is centric to everything they do. Examples of this type of environment are generally software, hardware, e-business, and other such technology companies. Technology can run very vertically within these types of firms.

The second works in an organization where technology isn’t at center stage, but rather is an enabler for the rest of the organization. Examples of this include manufacturing, retail, and transportation companies. In these environments, technology is a horizontal support structure – critical to the business, yes – but not a vertical leg within the firm. Most firms with CIOs fall into this category.

Call me crazy, but you wouldn’t need to know anything about the doughnut industry or desert “manufacturing” in order to provide technology services throughout Krispy Kreme. Don’t get me wrong, I think if you actually found that CIO candidate who had “doughnut industry” experience, you should court them, if nothing else than for the intangibles. However, there are a lot of extremely qualified CIO candidates that get passed up due to lack of domain experience.

From the CIO’s perspective, things such as call centers, servers, data centers, VOIP, technology budgets, hiring profiles for technologists, interconnectivity, ROI/IRR/EVA, and the Rationale Unified Process don’t change merely because you change business cards. These are staples found within the toolbox of any decent CIO.

A while back, I was fortunate enough to land in the mix for a CIO opportunity for a large mortgage firm. I was ultimately ruled out due to my lack of experience within the “mortgage industry.” Now, the last time I checked, CIOs don’t approve mortgage applications. Pay no mind that I have worked within the financial services sector for much of my career (consulting to Goldman Sachs, Chase Manhattan, Zurich-Kemper, Citibank, and several other firms). Heck, I even started my career as a computer programmer years ago working for one of the world’s largest credit card processors.

I should also add that I wasn’t bitter about losing out on this opportunity. This is business, and I’m a big boy – c’est la vie. I am simply using my own experience to illustrate the point.

Sadly, this has not been my only experience in seeing this line of thinking. A fellow technology colleague was recently ruled out for a position as a CIO with a large furniture manufacturer, because he did not have any experience working within the “furniture manufacturing” space. “You’re a fantastic candidate, but we need a furniture guy.” Uh huh – if you say so, Sparky.

Dan Gringas, a partner with Tatum Partners, summed this up nicely in a recent article entitled “How to Hire the Best CIO” over at CIO Update.

Business Knowledge vs. Domain Knowledge

No, you don’t need someone who comes from the cement-mixer industry. Guess what, manufacturing is pretty much the same whether you make cement mixers or cake mixers.

This drives me crazy and it’s endemic in CIO hiring. I once lost the competition for CIO in a company I had a real passion for because they wanted a “shoe guy.” I had deep knowledge of distribution, manufacturing and their core architecture, but I came from a different manufacturing background.

Most businesses should try to find someone from another industry well known for their strategic use of IT rather than trying to find someone from their specific industry. Hospitals are notorious for this, feeling that they are so different that they have to get someone from another hospital.

The ideal CIO is quite often not an industry zealot, but rather, someone who brings a consultative approach to solving business problems through the smart deployment of technology. Frankly, I would prefer someone who has worked in a variety of industries (e.g. a consulting background), and is used to looking at problems from a multitude of angles. There are actually very few scenarios in which deep domain expertise is going to make or break a good CIO.

Umesh Vasistha is the CIO of Jindal Stainless, the largest manufacturer of stainless steel in India (USD $4B in revenues). In an interview by The Financial Express, he shared a great response to one particular question:

Q: Are CIOs participating in the company’s strategic decisions?

Industry experience is a critical factor in operating the company. A CEO often comes from the operations/sales side in the same industry, while a CFO usually has finance/accounting experience in similar industry. Conversely, CIOs often come from technology careers from cross-functional industry experiences. A CIO wears many caps and is expected to take care of business methodically and use proven formulae of success to generate positive results for the company.

Client: “We are in trouble, and we want you to fill our CxO position. The last guy fit in great but the firm is still in trouble. So find us someone just like us and he will fit in well”.

Recruiter/Business Consultant: “Wouldn’t you prefer someone someone very qualified, yet possibly different? His diverse experience could bring new ideas and solutions to the table?”

Client: “No!”

The good news is, I’m not alone in my thinking.

• Dan Gringas (Tatum Partners), How to Hire the Best CIO, November 2005
• CIO Magazine: A CIO is a CIO is a CIO, March 2006
• Don Curt/TechLINKS: The Right Process for Hiring a CIO, April 2006

If you are hiring a CIO, do yourself a favor and read these articles before you publish your job description and start seriously interviewing candidates. And stay tuned to The Pothole, as I have an upcoming article which will discuss the “hidden” qualities of a great CIO! Keep an open mind as you screen your CIO candidates, and remember that the CIO is there to provide a service to the organization, not run your business.

What say you? How important is industry experience? Which industries are more stringent than others, and would it be better to have someone who is more well rounded that brings new ideas to the table?

Cheers.

- Scott Burkett

I got a call recently from a recruiter here in Atlanta. I won’t mention her name, or the firm she was with. Even though I’ve had my doubts about this firm for some time now, it really isn’t important who they are. As this is already starting to sound like YARS (Yet-Another Recruiting Story), you may be wondering why I’m filing this in the “Business Networking” category here at The Pothole. Read on – I promise this has to do with networking!

This gal called me in a bit of a panic. She went on and on about a wonderful CIO-level opportunity that she had with one of their clients, and how she was convinced that I was absolutely, unequivocally the right person for the job. Listening to her describing it, the role certainly sounded interesting, so I told her to move forward with presenting me to the client. I routinely get calls from recruiters, and while most of the time I decline to move forward for one reason or another (relocation, too much travel required, not a good fit, etc.), she did a fairly convincing job of selling the role to me. She called me a half hour later and told me she would be FAXing over some important candidate paperwork, and that I should complete this as soon as possible (i.e. now) and FAX it back to her so that we could move forward.

I dropped everything I was doing (which happened to be quite a lot that day – I was negotiating the terms of a major asset sale to an international company). I filled out the paperwork, which was no casual affair – it must have been 15-20 pages long, and really got down into the nitty gritty. Nevertheless, I clamped down on my bit and hacked my way through it. I FAX’d it back to her, anxious to go to the next level, as this role really sounded like something worth exploring. At the time, I felt that the distraction was probably worth the expenditure of time and effort. She phoned back and confirmed receipt of the FAX and promised to keep me posted.

I then proceeded to wait. And wait. And wait. One day became two, which became a week, which became two weeks. All along the way I kept telling myself that she was probably busy, or trying to lock the client down for an interview time. By the end of the 2nd week, I decided to call her back and see what the holdup was.

After finally tracking her down, and asking her very directly, she responded with “Oh, I’m sorry, I should have told you this, but the client decided to put the position on hold for the foreseeable future.”

Ya think?

I dropped everything I was doing that day, and made time for her urgency, and she didn’t have the common courtesy to at least phone or email me when the situation took a turn in a different direction. As business professionals, we are all taught, and indeed expected, to follow common etiquette when dealing with one another. When I expressed my frustration to her, she essentially blew it off and dismissed me. I was willing to give her the benefit of the doubt, but when she blew me off, all bets were off.

Note: Before you post a comment or send me a flame email exclaiming how recruiters are inundated with resumes and candidates, you should know that I agree with you! I fully realize that recruiters cannot possibly respond to each and every candidate with the same level of attention (I should know, I personally hired over 200 people one year). But when you are well into the pipeline for an opportunity, things change – or at least, they should. Busy is no excuse.

I have several good friends that are retained executive recruiters. They will be the first to tell you that recruiters these days get inundated with resumes and emails, and will rarely respond to bulk job applications, unsolicited resumes, and even normal responses to job openings. They simply don’t have the bandwidth. I understand this completely. However, they called me. They made me their customer.

As a third-party recruiter (nice way of saying “headhunter”), she has two customers in every deal – the hiring manager and the candidate she is presenting. SOme would argue that she only had one customer, and that was the hiring company (who is paying the bill), however, I disagree. I feel that as a broker, recruiters have to work both sides of the equation. Sell the candidate on the company, sell the company on the candidate.

Apparently, one of her customers (me, in this case) didn’t matter to her in the end. Candidates, executive-level or otherwise, should not be treated as “commodities”, yet many recruiters seem to fall into this trap these days. If you are right for the deal in front of them at that particular moment, you are the best thing since sliced bread. Otherwise, you are merely a number to them. A simple email or phone call would have changed the entire complexion of the situation.

Since that time, (and due partially to some lesser, previous offenses by this firm), I have made it a point to not recommend their services to my colleagues (many of whom are active hiring managers within Atlanta firms). I know of several instances where this firm more than likely lost out on business because of the way they treated their customer. I would never recommend them to an associate of mine, only to run the risk of having them be treated in a similar fashion. I value my contacts (and their time) more than that.

There is a lesson here – probably more than one. By not mentioning their name in this article, I’ve already shown them more professional courtesy than they showed me.

I want to reiterate that not all executive recruiters conduct themselves in such a manner. Most recruiters realize the importance of working both sides of a deal. The good ones realize that clients become candidates and candidates become clients. As Jerry Recht said in his recent guest blog spot here at The Pothole:

You should have several good quality recruiters in your tool belt and leverage them often. There is no substitute for quality!

It takes both sides of the equation to reach a successful conclusion for each deal. Irrespective of which side of the equation you are on, remember to be courteous. Whatever your actions are, they will come back to you – and they will either help you, or haunt you.

Cheers.

I received an email in my inbox today that started out something like this:

I came across your name as I was doing research for a client of mine who is looking to hire. Based on a review of your resume, I believe you would be a good fit for a possible career opportunity and have listed below the job description for your review. Please contact me by sending me your current resume in Word format and a telephone number where I can reach you at your earliest convenience.

Job title: Entry-level Java Developer

Which line on the candidate’s resume would make a better candidate for a Java developer?

1) Directed staff of 75+ developers in a Java/Oracle environment

or

2) Over 8 years of experience with Java and Oracle.

If this were an isolated incident, it would be easy to dismiss. But I’m currently getting dozens of these each week. I suppose their thinking is that casting as wide of a net as possible is a good strategy. Historically, I’ve only seen this type of inquiry from contingency-based recruiters with mostly line-level roles, although lately, I’m getting some from certain people proclaiming to be on the retained/executive side of the business (which I highly doubt).

Irrespective of this, as is the case with the recruiter’s time, the candidate’s time is valuable as well, and recruiters should keep this in mind. Most do, in fact. Most recruiters are good, decent, honest folks, who really are trying to make good fits. However, it appears that a fringe minority is doing a reasonably adept job at tainting the profession.

Cheers.

Lead image originally posted on Judy’s Book.

Five minute jobbing was apparently the brainchild of Andy Sack, CEO of Judy’s Book, which is a site aiming to combine the value of social networking and directory services, into a new form of Yellow Book. It really is a neat site – you should take a look if you haven’t seen it.

Sack wanted to come up with a creative way of recruiting IT talent in the Seattle area, and suggested that by using the same techniques as speed dating (something I had fortunately never heard of until now), hiring companies could quickly filter through a large number of candidates in a very short period of time. So he teamed up with a few other companies and came up with the concept of having these “5 minute jobbing” events.

I must confess that any time there is mention of a potential new efficiency, I am all ears. Especially when it comes to something like recruiting, which can be a time sink in certain instances. While I applaud their efforts to come up with a new twist on things, I think there are some fundamental problems with this hiring approach.

First and foremost, I simply don’t feel like you can truly get to know someone in five minutes. For some people, perhaps they feel that five minutes is enough time. As I opined in my discussion of the circle theory, I feel that each team member is a critical link to the integrity of the group as a whole. As such, I would spend quite a bit more time digging into a person’s skillset, background, and personality, among other things. Getting to know them better should be the first task at hand when hiring someone. There is only so much you can learn about a person in five minutes. Since when has it become advantageous to know less about a candidate prior to making a hiring decision?

If the idea behind the events were to spend five initial minutes with a candidate, and determine whether or not you wanted to bring them into the office for a second interview, then I would be all for it. However, I don’t see any mention of this on the 5minutejobbing.com web site. All I see is the tagline “Get a job in 5 minutes”, so I am left to assume that tendered job offers are the objective of the event.

I would be very interested to see some mid-to-long-term statistics on the track records of people hired through this “speed hiring” process. If you hire someone in this way, and after a few months, they don’t work, then what have you really gained? If anything, you’ve lost time and money. This is not to speak of the opportunity costs with lost project time, slipping dates, re-recruiting costs, and bringing a new person up to speed on the project environment (again).

Another problem is the fact that people tend to work in 3-5 year job cycles now. Granted, technology has made them more productive than employees in previous generations, but when you hire someone today, as a hiring manager, you automatically assume that they will not be there for the long haul. Given this, it is important that you hire people who will at least stay through the cycle, and hopefully beyond. Thus, another reason for getting to know them better.

Giving someone only five minutes (or even 15) in a job interview is quite frankly an insult to their intelligence. If I am going to commit a substantial portion of my life to working for a particular firm, I expect to be treated with some dignity and respect. I do not want to be made to feel as if I am walking into a cattle car or a fast food line. “Hi there, John. I know you are a very qualified candidate, but we are only going to give you five minutes.”

The 5minutejobbing.com web site describes the event as “fun and low stress.” Quite frankly, if I told a candidate that they had five minutes to convince me to hire them, there is simply no way that the candidate is going to “have fun” or feel “low stressed” about it. They are going to be nervous as hell, and most likely are going to flub something or another during the interview – this is human nature. Interviews are nerve-racking enough as it is for candidates – we don’t need to start putting egg timers over their heads.

I will say, however, think this approach could have merit in situations where you are hiring subcontractors. I am careful here not to use the word “consultants” – IT consultants and IT subcontractors are two entirely different animals, although for some reason, some people like to use them synonomously. If I am looking to do some staff augmentation, and I need a junior database analyst to come in for a few months, then I suppose this approach may have some merit, although I wouldn’t use it personally.

There is also still a glut of IT workers floating around in the larger marketplace. Irrespective of the size of the hiring company, finding able-bodied IT staffers is quite easy.

The companies that are listed as sponsors of the current “five minute jobbing” events in Seattle are all what I would call small or upstart companies (one is the up-and-coming real estate valuation play at zillow.com). I can’t see larger, more established companies using this sort of approach. The time savings is simply not worth the potential aforementioned opportunity cost.

Having worked in several startups, I would also argue that each new startup hire is exponentially more important to the lifespan of the organization. As such, I wouldn’t use this approach in a startup mode either. Truth be told, I’d probably spend even more time scrutinizing them. As I’ve said before, I’d rather spend $1,000 hiring the right person, then $10,000 fixing their mistakes.

For more info on this concept, here are some informative links:

• 5minutejobbing.com
• Judy’s Book
• Andy Sack’s Blog
• http://blog.seattlepi.nwsource.com/venture/archives/100745.asp

Cheers.

Essentially, I liken the team to a circle. The circle is continuous, strong, and unbroken at any point. Everything inside the circle (the team members) is protected by the circle itself (the whole of the group). Each time we add a new team member, the circle expands. The circle, like a chain, is only as strong as its weakest link.

I extend the opportunity to all of our team members to interview each and every candidate that makes my second cut (my personal interview with them). This peer-level interview is done in a group, usually in a conference room. The candidate sits at the head of the table, and the most senior member of the current team present in the room serves as the moderator. I am not present. Team members all have a copy of the person’s resume, and are free to ask them questions. The candidate is warned ahead of time that anything goes – there is nothing sacred in this interview – anything and everything on their resume (and in our job description) is fair game.

The team has their marching orders ahead of time: don’t violate the integrity of this circle - do whatever due diligence you feel is appropriate, because if the integrity of this circle is broken, you have no one to blame but yourselves. If you wake up three months from now, and realize that the person working next to you is a hack, then we have all failed as a group. As such, during the interview, the team is free to ask the candidate anything they wish. The candidate is fully briefed on this interview ahead of time, so this shouldn’t come as a surprise to them.

I recall this one fellow who made some rather lofty claims on his resume. Specifically, he claimed a number of certifications and practical experience with Java/J2EE at the senior developer level. His paperwork and initial HR screen went well, so we brought him in for an interview. He seemed like a congenial enough fellow, and certainly talked the talk in his interview with me. However, once he entered the group interview, his “paper castle” imploded about as fast as it was constructed. When one of our senior developers handed him a whiteboard marker and asked him to solve even a simple J2EE logic problem or architecture issue, he was unable to do so. Hiring him would have clearly been a mistake.

Most candidates don’t have a problem with this sort of interview. Granted, a few of them have walked away, refusing to subject themselves to such a rigorous interview. However, just as many have relished the opportunity, and jumped in head first. But I should point out, my number one objective here is not to coddle the candidate, but to build an efficient, mobile, and agile team that is grounded in trust.

After the group interview, we hold a team AAR (After Action Review) to discuss the candidate’s standing. Any member on the team can voice their concerns, from the most junior level software developer to the most senior level sales type. Then, together, we come to a consensus on whether or not we wish to widen our circle, and introduce this person as a new link. We discuss the candidate’s strengths and weaknesses, and determine whether they will be a good technical, as well as cultural fit. There doesn’t have to be a unanimous decision to hire a person or not – after all, that is why I get paid the little bucks to make command decisions – however, it serves as a forum where everyone can participate, and be heard.

The key to this process working properly is to solidify what it is that you are hiring (the hiring profile), and ensure that all team members have a thorough understanding of what that entails. You wouldn’t want to apply “senior-level” standards to an “entry-level” position, and so forth.

The theory here is that by empowering the team to play their role in protecting the circle, we will reduce the number of ineffective hires (which has a direct dollar savings in terms of opportunity cost), as well as make the need for justifying new proposed job openings more pronounced. This process not only works, but serves as a powerful filter, not to mention a powerful team-building exercise. Candidates that pass this group interview are accepted as a member of our “family” from day one, and no one questions them. They are most always ready to hit the ground running, which means a better ROI against that hire for the company.

I will state quite candidly that this technique is not for everyone. I have been in organizations where this technique would not work if attempted. Company culture, team makeup, and tenure of staff play a large role in the success of this and other group interviewing techniques. Your mileage may vary. However, all things being equal, I’d rather spend $1,000 making sure I hire the right person, than $10,000 fixing their mistakes.

Cheers.

He had originally called me to gauge my interest as a potential candidate for this role. As it turned out, I was not a good fit for the position, as the industry involved was not something I had direct experience in. I did, however, offer to learn more about the position, in hopes of turning him on to someone who would be a better fit.

When I asked him to describe the responsibilities he envisioned for this person, he initially told me that the CIO would need to really be able to jump into the fire and help the development team with the day-to-day development effort. I told him that it sounded to me like he needed to hire a “software development manager”, not a CIO. Hiring a good development manager would provide more focus on his software engineering efforts. Additionally, it would be more cost effective than hiring a CIO, and the savings could then be put back into the budget for other things.

He pondered this for a moment, and proceeded to inform me that this person would also need to be responsible for keeping the network and data center up and running. This would involve network availability monitoring, and management of all of the routers, switches, servers and other big glowy boxy-looking thingamajigs in the data center. I told him that it sounded to me like he needed to hire a “network operations manager” to work in conjunction with his software development manager.

He muffled a small sigh, and replied that he was also looking for this person to manage the strategic alignment with their technology partners, and provide architectural oversight for the company’s core software product line. I told him that it sounded to me like he needed a “chief technology officer”, or CTO, to work in side-by-side with the network ops manager and the development manager.

I thought about his burgeoning list of needs for a moment, and realized that his expectations were a wee bit out of skew. I posed the questions “what are the priorities here? Which tasks are more important than others?” He replied that they were all equally important, and that he was hoping to find them all in the same person, as he only had room in the budget for a single hire. Suffice it to say, I don’t think he liked my advice.

I realize that smaller firms need employees that are able to wear many hats, but in this day and age they can’t conceivably wear them all at once. I suppose that it is possible to find someone capable of doing all of the things he wants, it just isn’t very probable. 10 or 15 years ago, it wasn’t only probable, it was easy. That is simply no longer the case.

Back then, you could wear all of those hats with very little effort, as the technical environments we worked within back then were not as sophisticated and as complex as what we have today. Technology folks back then, even at the executive or managerial levels, were not required to become intimate with the business drivers – no longer the case. In addition, the standards against which we had to adhere were sparse or nonexistant (for example, HIPAA & Sarbanes Oxley).

In situations like this, it is probably more advantageous to prioritize your needs by aligning them with your overall business strategy, and hire accordingly. At some point, it may make sense to bring on a CIO-level hire, however a tighter focus on operational-level hires is probably going to have a better ROI in the short-term. In addition, you avoid the risk of putting someone too junior in a role that will eventually require someone more senior (as your business scales).

Cheers.