Technology Made Simple for the Technical Recruiter: A Technical Skills Primer

Technology Made Simple for the Technical Recruiter: A Technical Skills Primer

by Obi Ogbanufe

View All Available Formats & Editions

This guidebook for technical recruiters is an essential resource for those who are serious about keeping their skills up-to-date in the competitive field of technical resource placement.

Recruiting can be challenging with little background in technology, technology roles, or an understanding of how the two interact. In this book, you will learn the fundamentals of


This guidebook for technical recruiters is an essential resource for those who are serious about keeping their skills up-to-date in the competitive field of technical resource placement.

Recruiting can be challenging with little background in technology, technology roles, or an understanding of how the two interact. In this book, you will learn the fundamentals of technology from basic programming terms, to database vocabulary, network lingo, operating system jargon, and other crucial skill sets. Topics covered include:

• What questions to ask candidates
• How to determine when someone is embellishing his or her skills
• Types of networks and operating systems
• Software development strategies
• Software testing
• Database job roles
• And much more!

Armed with indispensable information, the alphabet soup of technology acronyms will no longer be intimidating, and you will be able to analyze client and candidate requirements with confidence. Written in clear and concise prose Technology Made Simple for the Technical Recruiter is an indispensable resource for any technical recruiter.

Product Details

iUniverse, Incorporated
Publication date:
Product dimensions:
6.00(w) x 9.00(h) x 0.81(d)

Read an Excerpt

Technology Made Simple for the Technical Recruiter

A Technical Skills Primer
By Obi Ogbanufe

iUniverse, Inc.

Copyright © 2010 Obi Ogbanufe
All right reserved.

ISBN: 978-1-4502-1646-3

Chapter One

The Technical Job Requisition

In This Chapter

Anatomy of a technical job requisition Request for information from the hiring manager Questions for the candidate based on the job requisition The recruiter's take

This book starts with the job requisition because it's the beginning of the process of recruiting. It's the purchase order, job order, or intent to purchase that a client provides to a recruiter that tells the recruiter the profile of candidate to look for. In order to do this successfully, the recruiter needs to really understand what the client wants.

This chapter reviews a typical job requisition, analyzes the demands and skills sets for clarity, and then rates the possibility of finding a candidate that fits the requirement. We will also take a look at the correlation between the job requisition and a resume to see when a resume has been edited to mirror skills from the job description and when a resume truly represents the capabilities of the candidate.

In technical recruiting, as in most professions, the best practice is to stay within a defined expertise. Choose an area of technology to focus on and recruit candidates in this or closely related areas. With focus in a specific area, the technical recruiter is able to dive deeply into an area to learn all there is to know. It also makes it easier for the recruiter to quickly review requisitions and identify (mis)matches. Areas of specialization may be based on specific vendors, such as SAP, CISCO, and Oracle, or may be based on technology implementation phases such as software development, database administration, network administration, and software testing.

There are two reasons why you want to understand the job requisition. One is the ability to assure the hiring manager that you understand their environment and their need and can locate a person for the current position and possibly others. Another reason is the ability to translate this understanding when describing the job role to a potential candidate. Whether you are a contract or corporate recruiter, you must be able to describe the position requirements to a candidate as if you were the hiring manager.

Anatomy of a Technical Job Requisition

When you review a job requisition, you should have a few questions in mind: questions pertaining to the platform, the network environment, the size of company or number of users, the current team if any, the level of expertise sought, any skills mismatch, and the experience of the hiring manager.

Looking at the job requisition in Figure 1.1, Sample SharePoint Consultant job description, a few of these questions have been immediately identified and answered. The level of expertise sought is senior level.

Hiring managers and their human resources representatives know what they want and spend time creating job descriptions that capture their wants and must-haves. Your job as the recruiter is to understand these wants, desires, and must-haves, and be able to separate them to come up with a description that captures realistic demands (based on current talent pool and market forces) and attracts the right kinds of candidates.

When reviewing the job requisition, the first step is to underline or highlight every skills set. You can see these skills sets underlined in Figure 1.1.

The second step is to start identifying answers to the main questions that revolve around the technology environment in the organization-answers that reveal the organization's platform, network environment, existence of legacy systems, number of users, level and type of expertise, and current team.

The platform: During review you must identify the platform, which is usually the main environment in the company. From this requisition we can identify that this company is a Microsoft shop; this means that the company requesting the SharePoint Consultant has a major investment in Microsoft technologies.

How do we know that? It's revealed through the mention of Microsoft technologies all over the job description-.NET, SharePoint, Microsoft SQL Server, BizTalk, Visual Studio, Microsoft CRM, Silverlight, and Microsoft certification. All these point to the fact that this company is heavily invested in Microsoft. So to answer the platform question, you can see that this shop is a Microsoft platform. Because the client is a big Microsoft user, it is possible that the client may also have a partnership with Microsoft. One of the requirements for Microsoft partnership is that a company employ X number of certified individuals. This may account for the desired requirement for the requested candidate to have a Microsoft certification (more on certifications in Chapter Thirteen).

Network environment: Once the platform is identified, the network environment is just an extension of the platform environment. In our example requisition, we identified that the platform is Microsoft; this should point to the fact that this client uses Microsoft network operating systems (more on operating systems in Chapter Five).

Interoperability with legacy: The requisition does not identify any legacy systems in its environment. But you cannot conclude from this that the client does not have a legacy system. It just points to the fact that this is an area that must be clarified with the hiring manager, with a question like, "Do you have any legacy systems in your environment or any non-Microsoft applications that require interfacing with the current applications?"

Number of users: Some requisitions give you an indication of how many users are in an environment; our current example does not, and so it needs to be clarified with the hiring manager, with a question like, "How many users are in your SharePoint environment?" The answer to this question will tell you how many SharePoint users the selected candidate will support. The answer to such a question will also help create a picture you'll use when describing the environment to your potential candidates. Another question you may consider asking to ascertain user growth is "What is your plan for migrating additional users to SharePoint in the future?"

Level of expertise: Notice that the requisition is requesting a Senior SharePoint Consultant, but the reference to direct SharePoint experience is "1+ years of SharePoint experience (MOSS 2007)." (MOSS stands for Microsoft Office SharePoint Server.) This may seem like a mismatch, that the client is seeking a senior consultant in SharePoint but requires only about one year experience in the software itself. But reviewing the job requisition further, you will see that the client is looking for a core .NET developer with some experience in SharePoint software. The main development area will be the SharePoint software, hence the title SharePoint Consultant. While the current title may be popular, a more accurate title to engage prospective candidates may be ".NET Developer (SharePoint)."

Type of expertise: This requisition has the title "Senior SharePoint Consultant." The consultant title is usually a confusing one because it can mean different things to different people, so it's wise to clarify the intent from the hiring manager. A consultant can focus on one of three things-development, administration, or project management. This requisition refers to a consultant that is focused on the development phase because of the requirement for development skills and experience in software development tools like Visual,,, and C#.

Current team: The requisition alludes to the fact that there are people with different skills sets in this company. Skills sets in this company include Portal implementations, Extranet implementations, custom application development, eCommerce, Business Intelligence, Data Warehousing, MS CRM customizations, and Application Integration. This sounds like a consulting company with engagements with other companies. For some candidates, this is an ideal company where the candidate is exposed to different work environments and industries from month to month, where candidates are never bored. For another candidate, this may be a nightmare because he may prefer a place where he is allowed a learning curve and the ability to learn from teammates, which is not always the case in consulting environments.

Request for Information (RFI)

After careful review of the job requisition, it is time to compile the list of questions and clarifications directed at the hiring manager. The purpose of the request for more information is twofold: to gain clarification on any ambiguity and to confirm your understanding of the needs of the hiring manager. The clarification may include questions not answered from the job requisition, questions that may be asked by potential candidates in regards to the position, and questions to ascertain the most important skills and what makes for the near-perfect candidate.

It may sound as if you are interviewing the client when you start with these questions. In reality, you are. Figure 1.2 illustrates RFI questions for the hiring manager. You want to know as much as possible about the job in order to find the right candidate.

Three most important skills: When reviewing a job requisition, you must identify the three most important skills in the order of importance to the hiring manager. If you are recruiting in an area of focus (e.g., software development), you probably already know the three most important skills, though it still needs to be confirmed with the hiring manager. This will help you identify the required baseline for potential candidates and helps qualify and eliminate candidates quickly.

Average work week expectation: This is an important question to ask the hiring manager. It's important because there are candidates that will not work more than a specified number of hours per week, give or take two hours here and there. There are also employers that require (albeit indirectly) their employees to work an average of fifty hours per week. This may seem irrelevant, but it has caused a number of employees to leave an otherwise great job for another. This also relates to the next question, what the pace of the company is like.

Pace: It's almost a given that a technology or dotcom company is fast paced, though some are more fast paced than others. So it's imperative that you ask the hiring manager the pace of the company.

The pace of the company can be identified in this way for a software development or Web-based company. You want to find out the frequency of code propagation in their production environment by asking this question (meaning how many times they move new and updated programming code into their production servers, including hot fixes-which is the software fix of broken code): "What is the average frequency of code prop to production, including hot fixes?" The answer will tell you the number of cycles of code a software developer or tester goes through per week. The answer from the hiring manager may range anywhere from "once a week," "twice a week plus one or two hot fixes," "once every two weeks," to "once a month."

Latest technology implementation: Most developers enjoy and look forward to working with the latest of technologies or methodologies. So it will be good information to share with the candidate if you, as the recruiter, know that the client has implemented any project using the latest technologies. The possibility of working with the best and latest technology is an attractive option for the candidate. Here is how you frame your question to receive the answer you seek.

Development tier: For the purpose of division of labor, application development can be divided into many layers, such as presentation, business logic, data access, and database. See Figure 1.3 for how these layers are separated. A key benefit of keeping these application layers separate is that it allows parallel development of the different tiers of the application. One developer can work on the presentation tier, while another builds the business tier, and another works on the database tier.

Working on separate tiers also allows for less complicated maintenance and support, this is because it's simpler to change and upgrade a single specific component than to make changes in a one-tier application. If the business rules of a multitier application are changed, it's only necessary to change the software logic in the business tier on one server. With this in mind, seasoned developers prefer working on multitier applications, where every layer has been separated. It's easier to update and troubleshoot. So as a recruiter, you want to find out from the hiring manager (that is looking for a developer) the development tier in place in their organization. Here is how you frame your question to receive the answer you seek.

Structured process or ad hoc-driven: Some technology organizations are more process driven than others; in these organizations, documentations are done and written processes are used for streamlining projects and for every change request. Some candidates would want to know if this is the case for the organization he is being recruited for. In my work experience as a developer, I thrived better when there was a set and known way to write code. This does not mean that one cannot deviate every once in awhile when there is a need for it, but it does mean that there is uniformity in how things are done, thus making it easy for the next developer to pick up where the other left off , with little wasted time. As a recruiter armed with this information alongside all the rest, you are able to keep your arsenal full with information, not only for this position but for this organization as a whole, making you the recruiter of choice for other requisitions that may arise from this company. Here is how you frame your question to receive the answer you seek.

Criteria for choosing one out of two: There are those occasions where all you have for a job requisition is one candidate; this question would definitely not work there. But the occasions where you have two to three good candidates for a job, you would want to know the hiring manager's criteria for choosing one person out of the two or three candidates presented. Whatever the answer is, it will help you fine-tune your search. Ultimately you want to save your client's time and make the choice easy for the manager by finding one or two great candidates where the hiring manager picks one of the two. The converse is to inundate the hiring manager with ten candidates, where she rejects nine out of the ten, resulting in diminished confidence in your abilities as the recruiter. Here is how you frame your question to receive the answer you seek.

Certifications or no certifications: As noted earlier in this chapter, there may be a specific reason why an organization requires certification, such as a partnership with a software vendor where the client organization is required to have one or two personnel with certain certifications. This is the case for Microsoft partnerships. Another reason may be that the client organization just wants to ensure that the candidate has done due diligence in a certain technical expertise. Speaking from experience, I have the Microsoft Certified Database Administrator MCDBA in SQL Server 2000 and the MCBMSP Microsoft Certified Business Management Solutions in Microsoft Dynamics CRM 4.0; these are tough exams to pass. The study and practice involved are painful, but I'm happy I did them because there are foundational skills I have from the process of training and studying for these exams that I probably would not have had otherwise. Having such certifications will show value proposition to organizations or a hiring manager, demonstrating the competency of the candidate.

Whatever the reasons are for an organization's need for certification, you would want to know these reasons. If there are no special reasons, then the job requisition may be better served if this requirement is removed. For candidates that have this certification, it's a foot in the door for them, but there are candidates who do not have the certification but have in-depth experience in all the other requirements who are really turned off by an organization's need for certification (for more on certifications, see Chapter Thirteen). Here is how you frame your question to receive the answer you seek.


Excerpted from Technology Made Simple for the Technical Recruiter by Obi Ogbanufe Copyright © 2010 by Obi Ogbanufe. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Meet the Author

Obi Ogbanufe is a trainer, former technical recruiter, and computer science and engineering graduate who has held many technical positions in the private sector. She began her own technical recruiting company in 2006 and lives in Dallas, Texas. This is her first book.

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >