How To Recruit And Retain Developers
"The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint enough to keep from meddling with them while they do it."
Theodore Roosevelt
Whenever you open a computing newspaper these days, you see more job advertisements than ever before and within them, a higher proportion of Visual Basic positions advertised than ever before. This trend will certainly continue with version 6 of Visual Basic. To date, 10 percent more jobs have been advertised in 1998 then there were during the same period in 1997. Big increases in salaries and contracting rates are evident. Three out of every 10 positions remain permanently vacant. So how does an organization differentiate itself so that it can attract and, more importantly, retain great developers?
The first thing to say is that it's very tricky! But an organization can take some practical steps to overcome some of the problems and difficulties of finding good developers. In this chapter, we will outline some of the techniques that we at The Mandelbrot Set (International) Limited (TMS) have used successfully over the years. This is not a classic Human Resources view, but more a summary of what works for us at the business end of the recruitment process. Perhaps some of our ideas will be useful to you.
First things first, we split our staffing process into the three main steps:
Recruiting (including assessing)
Retaining
The key to hiring great developers is to recruit the right people in the first place. While all three steps are important, we feel it's worth expending a lot of effort on Step 2, as you'll discover in this chapter.
First discuss with others in your organization the main attributes you are looking for-whiteboard the "spec," in other words. Be clear about the type of person you want and the skills required to do the job. For example, we at TMS look to hire developers. Not coders, not programmers. Developers, in our vocabulary, don't just write code or simply program someone else's technical design-coders and programmers do that. Developers are able to develop the designs and architectures needed for themselves or other programmers. They never hack code; they think about the code's structure and form first, and then write it down. Developers can test and have broad development skills. Now please don't get fired up if you call yourself a coder or a programmer and disagree with the definitions of these terms. They're simply the definitions we use at TMS. That's all, so please don't be offended!
Generally, if we're looking to recruit great developers, we look for people with a good track record in development. It's up to you to decide whether the developer's experience should be in, say, Visual Basic or in Java (that is, whether it's "the brain" and general programming experience you're seeking or whether it's all of the above) combined with experience in the language you're using. When we're recruiting Visual Basic developers we normally expect them to have extensive knowledge of Visual Basic, although if the person were exceptional in every other area, we'd almost certainly take them on and give them the necessary training. The best developers are generally those with logical, methodical minds. They're also usually thoughtful, precise, and, we hope, not impulsive-the best developers think first and act later. We're after the people who think algorithmically (people that understand the necessity of a good algorithm and have the wherewithal to implement it), which is not to say that they should think only in algorithms. A thorough knowledge of algorithms is useful but can always be replaced by someone who "thinks right" and who knows where to look for an existing algorithm.
We are also after people who are in tune with our culture. For TMS, this means they should be first and foremost a team player. If they use too many "I"s instead of "we"s, we have to consider whether they are more comfortable going solo. We have to feel they will fit in with the rest of the family.
Remember that technical people are a bit different from other staff. Typically they'll want plenty of exposure to the new technologies, such as Visual Basic 6, as well as having some fun while they're at it. Technical people tend to hate bureaucracy, administration, and filling out forms-they can also be harder to manage.
Soft skills (such as interpersonal relations, communication skills, and so forth) are also vital. It's important to be presentable, personable, and coherent.
These are some of the things that we think about. What's important to you? Be clear about what you want.
The qualifications you seek depend on your own personal or company preferences, so, as always, we speak here from our own experiences at TMS. In an ideal world all applicants are vastly experienced and well qualified. Often, obviously, this isn't always the case.
Naturally we look for experienced and capable developers first. If the candidates are well qualified, it's a bonus, but we don't discount people who fail to meet some sort of qualification threshold. However, we consider a degree a plus and we're particularly interested in someone with a relevant degree, preferably in computer science or mathematics.
Having a degree versus not having one If someone has an advanced degree it normally means that they have a proven ability to solve complex problems and absorb information (although we've seen some interesting exceptions). Somebody with a degree naturally carries more credibility than someone who doesn't have a college degree, and a college graduate is generally easier to propose to our clients.
Of course, the best person
for the job isn't necessarily the most academically qualified-after all, a
degree from the
MCP certification Microsoft Certified Professionals (MCPs) have a proven level of competence with Microsoft technologies and tools, so certification is usually viewed as a positive attribute. As a services company, we find an MCP certification is a positive sales feature. However, don't rely on it too much. Conduct your own independent skills assessment.
Ideally we'd all like to hit what we call "the red zone"-well qualified, lots of experience, and good personal skills. (See Figure 17-1.)
Figure 17-1 Nerdvana: the ideal skill set
But what's ideal for your organization is for you to decide. Which of the three qualifications is most important to you? Brainstorm about what you want and then move on.
Now that you know the sort of person you're looking for, you need to document your requirements. This is vital.
The cornerstone to any employment decision begins with job analysis, which is the systematic assembly of all the facts about a job. The purpose is to study the individual elements and duties. All information related to the salary and benefits, working hours and conditions, typical tasks and responsibilities are required for the job analysis. Competition and equal employment opportunity legislation (the myriad laws, guidelines, and court decisions concerning equal employment opportunity make job analysis necessary) has made job analysis a mandatory organizational consideration for most businesses.
Job descriptions are written based on job analysis information. A job description describes a job, not an individual doing the job. The job description is derived from a requirement in an organization and is an essential element in the correct selection and evaluation of employees. Job descriptions are also the basis on which a job advertisement is written.
Every job should have a job description, which can be mailed to any interested parties before the interview. The job description might help you easily filter unsuitable candidates as some will drop out once they've had a chance to see what the job will entail.
Job descriptions should be written using brief, clear sentences. The sentence structure should follow the "implied subject-verb-object-explanatory phrase" format. It's generally to your advantage to use action verbs like "programs" and "analyses," for example.
A job description is a written description of the major duties and responsibilities for any job applicant. Here's a sample TMS job description for a developer based on the well-known Hay/MSL format, although we have also included a "person specification" so that everything we want is contained in one document:
Job Description
JOB TITLE: Developer
REPORTING TO: Project Manager
DATE: As Required
PURPOSE: Work with and mentoring the client's own staff on specific projects, and equally for internal company projects. Provide high quality, cost effective technical services within given timeframes and budgetary constraints to ensure optimum customer satisfaction and business driven solutions.
PRIMARY RESPONSIBILITIES
The key areas of responsibility for the employee are as follows:
Ensure that a high quality technical serv 19519k1019t ice is provided to both the external client and for internal projects in the specific areas of design, programming, and software testing.
Write technical documentation for external clients and whitepapers suitable for publication on the company Web site or in technical magazines as requested by any of the company's managers, in order to maintain the company's profile within the industry and to promote the company's services.
Contribute to the development of technical training courses and running briefing sessions on technical issues for the clients' staff as required.
Accompany TMS consultants on client visits as required and provide in-depth technical support as necessary in order to maximize all sales opportunities for the company and to ensure the highest quality service for the prospective client.
Contribute to company Technical Days by giving formal presentations or leading more general discussions regarding current projects or case studies and ensuring that the overall objective of "knowledge sharing" with colleagues is achieved.
Ensure that the company's vision to provide the highest quality software development and client services is achieved and maintained at all times.
ORGANIZATION CHART:
PROFILE OF EMPLOYEE
Essential requirements include:
Minimum 8 years experience of having worked within the IT industry, preferably within a software services company or consultancy, in a role requiring multiple external client contact and service provision
Minimum 5 years hands-on Windows development experience
Minimum 4 years hands-on Visual Basic development experience
Minimum 4 years hands-on database/SQL programming experience
Desire and ability to work relatively unsupervised on external client sites
A self-managing, self-motivated individual who can demonstrate a successful history of remote working
A quality, focused individual with proven customer interaction skills
Desirable qualifications include
Graduate-level degree in computer science or other science subject
Appreciation of software engineering disciplines and methodologies
Knowledge and experience of traditional or object design, architecture, and implementation
Working knowledge of any of the following: SQL Server, Access, and MSOffice suite/VBA
Knowledge and experience of client/server systems development
Working knowledge of any of the following: Windows NT, Java/J++, C/C++, Active X technology, COM/COM+/DCOM, RDO, ODBC
Microsoft Certified Professional (versions 4, 5, or 6)
Clean driving record
Research the industry standard remuneration for the position you need to fill and then add 5 to 15 percent if you want to be competitive. Research salaries regularly and make sure your current workforce benefits from this research as well as any new developer. Also, develop your own company salary policy stating where you want to be in terms of the salaries and benefits you offer to your staff. For example, do you want to pay at the median level, the upper quartile, or the top decile for the IT industry or for your geographical area? Decide where you want to be and then compare where your current salaries fall, and then adjust if necessary.
The two best ways to locate the right people for your organization are the two that pop immediately into the minds of most people: word-of-mouth recommendations and advertising.
Better to hire the devil you know (or at least someone you know) than the one you don't. We're always interested in personal recommendations from existing staff members. More often than not, like attracts like, and usually a good developer will recognize someone from the same stock. It's a kind of "it takes one to know one" philosophy. When someone is recommended to you, ask the person providing the recommendation to qualitatively summarize the skills and qualifications of the potential new recruit. Would the "recommender" be willing to manage or work with the person they're recommending? Also, consider paying a finder's fee to your staff-we do and it works well. Even if we receive a personal recommendation, we still put the candidate through our standard assessment procedure. This step is essential.
If you decide to advertise, you'll generally use the job description to compose the advertisement. All the essential qualities must be included in the advertisement so that any potential applicant can decide whether the job is worth applying for.
It's essential to advertise in the right places. Make sure that you advertise, in detail, the role/position you're recruiting for. Don't make the advertisement too general, figuring that if you cast the net wide enough, you might catch other people of potential interest to your company. In other words, don't advertise for Windows developers if you're only looking for Visual Basic 6 developers but might also be interested in attracting a C++ developer sometime soon. Advertise for the C++ developer later, when you actually need one, and again, make it clear in that advertisement what you're looking for. By casting the net too wide you will all too often dilute the information deemed necessary by a potential candidate. You'll also make it appear as if you're trawling for résumés.
People should be interested in the position as described in your advertisement, and you should start the filtering process at this stage. For example, if the position requires long hours, or perhaps working away from home, state this up front in the advertisement-anyone who isn't interested won't apply. Those who do shouldn't mind travelling and working long hours. See? You've already started optimizing the process by generating a shortlist!
Places to advertise The primary places to advertise to get the best response are as follows:
The Press. We use the specialist press for advertising key positions. For the more junior positions we mostly rely on word of mouth and on the Web.
Agencies. We rarely use agencies. While they perform a very useful role in certain circumstances, we prefer to do our own thing when it comes to recruiting people. No one else knows our business and who we're after as well as we do.
Once you start receiving résumés, what do you do next? It is essential to have a very well defined process so that you are professional, efficient, and responsive with the applications-good people aren't available for long, so you must quickly assess and rank the résumés using an efficient filtering process.
We handle only "soft" résumés, meaning that we have them e-mailed to us. We have a strict set of criteria (based on the job specification) that we filter the résumés against. People who are immediately "rejected" are thanked for applying and informed of our decision right away. We speak to other candidates over the phone to thank them for applying and to assess some of the attributes that are impossible to pick up from a résumé, such as oral communication skills, phone manner, power of description and explanation, and so on. We also ask a small number of (carefully chosen) technical questions. Again, people who are "rejected" at this stage are thanked for applying and informed on the spot. Otherwise, we tell them that we would like to invite them in for interview.
We tend to interview people in batches, on what we call "recruitment days." Normally we see eight people at hourly intervals. Each candidate gets a general interview, a technical interview, and takes a technical test.
The whole procedure takes about half a day. This is quite a lot of time to give up and some people say they can't afford to do so. We do lose a few (what look to be) good people this way, but we regard this as another important part in the filtering process. If a candidate can't give up a reasonable chunk of time for an interview, how keen are they on joining us, really?
At TMS, we have a three-person team, comprising two interviewers and one person to administer tests.
We always bear in mind exactly what we're trying to achieve during any interview. Our objectives are as follows:
To assess the likelihood that a candidate will share our company's values, goals, and culture
To assess how well a candidate matches the position being interviewed for
Always keep these points in mind: make them your interview mantra. Also, ensure that you have a structure to your interviews, which accomplishes the following:
Is essential for accurate and consistent measurement across a group of interviews
Is efficient
Interview preparation This is how we prepare for interviews at TMS:
Scan-or better still, study-the applicant's résumé-are there questions we would should ask about what we see?
Make sure that we have a pad for taking notes. This is important, because it'll reduce the amount of information that we have to hold in memory.
Ensure that the interview room is adequately prepared.
Be sure that we have all the materials that should be given to the applicant.
We always take an instant photo of any prospective employee. We staple this to the notes and résumé so that our recollection is made easier at the end of the day and in the future.
Controlling the interview Remember that the interviewer controls the interview. Prospective employees should be given an opportunity to ask questions at the end of the interview-inform them of this structure before you start asking them questions. It's important that you separate these two phases, the formal "pull" part of the interview from the more informal "push" part where the candidate usually asks his or her questions.
Sometimes we find it useful to have at least two people attending each interview. For one thing, it gives one of you the chance to "observe" the candidate while the other interviewer is asking a question or listening to a response. Of course, it's also useful to have a second opinion during the debriefing.
Remember that as well as being your chance to assess a candidate, the interview is the candidate's chance to assess your company and you as an individual. It's unwise to arrogantly assume that they'll take any job you might offer simply because they turned up for an interview. It's also an opportunity to sell your company. If the candidate isn't made an offer, or if the candidate turns down an offer from your company, you still want them to have a lasting and positive impression of your company. Keep in mind that the candidate might have an opportunity to do your company a good turn-if they've been impressed with you, that is.
Here are some important things to tell the interviewee about the open position and about your company:
Tell the interviewee where the company is going, what its vision and mission statement are. These are what make your company unique.
Give the candidate details about the position that's being interviewed for, because the advertisement is likely to have been sketchy and perhaps a little vague.
Tell the candidate what makes your company special: quality, management style, employee care package, company car policy, and so forth. These details combine a reiteration of the company's vision plus factual information that might otherwise have to be gleaned from an offer letter.
Perhaps most important, tell the interviewee about the reality of the company, warts and all. Neither you nor they want to be surprised further down the line.
Sample interview questions Here are some of the interview questions we use:
Describe the best boss you've ever had.
Describe your ideal development environment, everything from the tools you'd use to the philosophy you'd apply.
Given your personal goals and limitations, what job would be your dream job?
Having just walked in, what do you think of [company name] so far?
How did you choose your last job?
If it were in your power, how would you like to see your current main development tool improved? Have you informed anyone of your views, especially the tool vendor?
In what ways do you think you can make a contribution to our company?
What are you reading currently? What have you read recently?
What are your two favorite technical books? Why?
What are your own special abilities?
What do you consider to be your most important contribution or accomplishment in your current position?
What do you know about [company name] and why are you interested in joining us?
What does success mean to you?
What kind of people appeal most and least to you as coworkers?
What's your definition of a team? Of cooperation?
Why should [company name] hire you?
Looks for attitude as well as ability. Be careful to spend as much time as possible listening; don't do too much of the talking yourself.
It is important to take notes during the interview and write up a summary as soon as the candidate leaves the room. Do it while your thoughts and impressions are fresh.
We feel that testing a candidate in a number of different ways is vital. Here are some of the things we do at TMS.
As we've mentioned, whenever we're interested in recruiting an individual we'll arrange to phone them at home to discuss the position further. At the same time, we'll take the opportunity to probe their technical skills and generally attempt to gauge their personality and how they motivate themselves. As much as possible, we'll effectively conduct an interview with them right then and there. The idea behind this quick phone interview is to optimize the screening process and to save time-both theirs and ours. If you suspect the candidate is less than honest about his or her abilities, you can verify this quickly by asking one or two leading questions about some general development issue or about some appropriate technology. Like any company, we get a few "fakers" applying for jobs; some might be guilty of nothing more than creative writing, whereas others might be trying to deliberately land a job for which they're simply not qualified (figuring that they'll learn the skills on the job and at your expense). Telephone testing is inexpensive and a good way to start the relationship between the prospective employer and prospective employee. We recommend that you always take the time to do this prior to conducting the in-person interview.
At TMS, every potential developer we interview is also technically evaluated at a recruitment day. Mostly we use a paper-based written exam, which lasts more than two hours (the Visual Basic 6 exam currently contains 45 questions). The test is conducted under examination conditions, which means it's completed in a quiet, supervised room. Those who pass the test and eventually join TMS usually refer to the test as "the test from hell." To pass this test is to feel like you're joining an elite club. Make sure you tell the candidate that there will be a test before they come for the interview!
Introduction and About the Test
This test paper, once completed, summarizes our understanding of your technical comprehension of Windows' programming using Visual Basic and additionally provides us with a good indication of how you:
Work under pressure and to strict deadlines
Go about solving complex problems
Improvise and form educated guesses
And most importantly, think
No one is expected to deliver a perfect test paper at the end of two-and-a-half-hours (indeed, the design of the question paper and the time limit conspire to prevent this from happening), and candidates with various levels of expertise are of equal interest to us. Given this, and the fact that your completed test paper may be referred to during one of your interviews, it is essential to make an impression during the test. We repeat, however, that it is not necessary for you to know the answer to every question, or be a Visual Basic guru, to do well.
It is vitally important to understand and answer the question (and to do it as fully, yet at the same time, as both space and time are limited, as economically as possible). Additionally, it is vital to be verbose and fully suspicious of the questions. Read the wording of each question carefully and try to ascertain what the questioner is after. Always assume that each question is a loaded question, potentially harder than it might at first appear. Once you've written your answer, reread it. Is the answer you gave ambiguous or clear? If you were marking this paper objectively, how would you score the answer on a scale of 1 to 10?
The testing room, and therefore the candidate(s), are "computer-free," so they don't have access to Visual Basic or to any help file text, nor do we provide any manuals. We're not really interested in whether someone can remember the number and order of the parameters to MsgBox, for example. That kind of stuff most people look up anyway. No, we're interested in how someone codes and generally solves problems. To give you an idea about what the test aims to find out, here is the title page from our test:
Although we want you to answer the questions in sequence and not jump about, it is always a good idea to read through the entire question paper before attempting to answer any individual question (10 minutes have been allowed for this). Often, something referred to in a later question helps in the answering of an earlier one-reading the question paper first therefore often has real advantages. This paper contains 44 questions and you have two-and-a-half hours (plus 10 minutes pre-reading time) to answer as many questions as you can. This gives you on average just over three-and-a-half minutes per question and answer (for all 44).
Each question is awarded around 10 points (some are higher, some lower). A total of 440 is the highest possible score. As your paper is being marked two scores are produced. One score is simply based on how many marks you scored out of 440 (an unanswered question scores 0). The other score is calculated on the actual questions you answered. That is, it indicates how well you did on the questions that you answered (unanswered questions are therefore ignored).
Once again, remember that this is not just a technical assessment-we're looking to see how you perform here in more general terms. After all, detail can be easily found in manuals and in help files! Now, get a fresh cup of coffee, breath deeply, make a real effort to relax, and tell yourself to enjoy the test.
After the test, maintain your own industry average and your own preferred score, the percentage that you would expect someone in your company to attain. Derive this score by having your current employees take the test. (Be sure that they didn't help write the test!) Log their scores and define your passing score.
The technical test we have works well for us and we always advise potential employers to evaluate candidates with something similar, whether they're looking to hire contractors or permanent members of the staff. Even an oral test might be sufficient, just so long as it's not too easy. Remember, you're looking to recruit great developers, so, while you might ask someone to explain what Option Explicit is all about, you'll probably want to probe a bit deeper as well. Here are some examples drawn from our current exam to give you a feel for the level of probing and what we think works. The answers are shown in Appendix B in case you want to test your own skills.
The TMS Exam
Q1. Given the following code fragment, what will be output by the Debug.Print statement? Explain your reasoning
Q2. Assuming that lstResults is a standard Visual Basic list box control, what is the meaning of the following code fragments?
A. Debug.Print lstResults.List(3)Q3. Write the function sNumToBin. This function is passed an integer and returns a string (assume 16 bits in the integer). The string contains the binary equivalent of the passed integral value. For example, if the function were passed 42 it would return the string "0000000000101010," and if it were passed -1 it would return "1111111111111111."
Q4. Write the function itoh. This function is passed a value and returns a string. The string contains the hexadecimal character equivalent of the passed integral value. For example, if the function were passed 14 it would return the string "E," and if it were passed -1 it would return an out-of-range indicator.
Q5. State how you would position a Visual Basic form (as it is loaded and before it becomes visible) in the center of the Windows desktop. Should the form appear centered irrespective of the screen resolution used?
Q6. State what descriptive, "Hungarian" prefix you would place before the following identifiers (there is no right or wrong answer to this question):
|
Identifier |
Type |
Scope |
Answer |
|
BM010 |
Form |
Form | |
|
FileOpen |
Menu | ||
|
RecordCount |
Integer |
Global | |
|
FirstName |
String Array |
Modular | |
|
VehclNum |
Long |
Local | |
|
Vehicles |
Combo Box | ||
|
Time |
Label |
Q7. Part 1: Provide a full explanation of the following code fragment. Part 2: What, if anything, would change if we simply passed a constant instead of passing x both times? Part 3: Would changing the line SomeSub(X) to Call SomeSub(X) affect anything? Part 4: Would using ByVal cause a change? Part 5: State why Visual Basic employs a pass by reference parameter passing mechanism instead of a scheme based on pass by value.
Private Function SomeFunc(n As Integer) As IntegerQ8. Part 1: Write a small Form_Load event handler to multiply instantiate and suitably position a CommandButton control called cmdDigit to form a kind of calculator keypad. (Label the controls with digits, 0-9.). Assume that at design time a single cmdDigit control exists and that its Index property is set to 0 and its Caption is "0." Part 2: Write a cmdDigit_Click event handler to display any selected digit in the caption of a label control called labDisplay.
Q9. State as many ways as you can to search a source string for some substring in a case-insensitive way (so that the strings "Tms" and "TMS" match, for example).
Q10. Write the function NTrim$. This function is similar to the ?Trim$ functions (where ? is nothing, L, or R) already present in Visual Basic, except that it removes any NULL character in a string. A NULL character is a character whose ASCII value is 0.
Q11. Write the function bFileExists. This function has a single string parameter and returns either True or False. The function determines whether a file, the fully qualified name of which is given by the string parameter, actually exists or not.
Q12. Part 1: An item of data declared Public in a class can be treated as a property of the class. Additionally, properties can be defined using property procedures. Explain the differences between the two. Part 2: Which elements can be "exported" (made visible) from a class?
Q13. What events will the following code fragments cause to be invoked on Form1? In code fragment C, how many instances of Form1 exist once the code is executed?
Code Fragment A
Sub main()Code Fragment B
Sub main()Code Fragment C
Sub main()Q14. A project consists of two forms, Form1 and Form2; a module, Module1; and a class, Class1. Form1 is the start-up form and Form2 contains a single button called Command1. Each item in this project (except for Form2) has the following in its general declarations section:
Public n As IntegerAdditionally, in Module1, o is declared as Public o As Class1.
Form1
Private Sub Form_Load()Form2
Private Sub Command1_Click()Is the code above legal? Negate any illegalities you see in the code (if any) and state what is output to the debug window.
Q15. Write some code to give an example of all the following:
Optional arguments
Parameter arrays
Collections
Q16. What was VBCP (as shipped with Visual Basic versions 4 and 5) and how was it used?
Q17. What does this code do?
Form
Private Sub cmdTest_Click()Class
Private This As Class1Q18. Part 1: Given the precedence rules detailed just below (taken from the Visual Basic Help Files), add parentheses to the following code showing clearly how it will be evaluated in Visual Basic. Part 2: What does the code print?
Dim n As IntegerWhen several operations occur in an expression, each part is evaluated and resolved in a predetermined order called operator precedence.
When expressions contain operators from more than one category, arithmetic operators are evaluated first, comparison operators are evaluated next, and logical operators are evaluated last. Comparison operators all have equal precedence; that is, they are evaluated in the left-to-right order in which they appear. Arithmetic and logical operators are evaluated in the following order of precedence:
|
Arithmetic |
Comparison |
Logical |
|
Exponentiation (^) |
Equality (=) |
Not |
|
Negation (-) |
Inequality (<>) |
And |
|
Multiplication and division (*, /) |
Less than (<) |
Or |
|
Integer division (\) |
Greater than (>) |
Xor |
|
Modulus arithmetic (Mod) |
Less than or equal to (<=) |
Eqv |
|
Addition and subtraction (+, -) |
Greater than or equal to (>=) |
Imp |
|
String concatenation (&) |
Like Is |
When multiplication and division occur together in an expression, each operation is evaluated as it occurs from left to right. When addition and subtraction occur together in an expression, each operation is evaluated in order of appearance from left to right. Parentheses can be used to override the order of precedence and to force some parts of an expression to be evaluated before others. Operations within parentheses are always performed before those outside. Within parentheses, however, operator precedence is maintained.
Q19. Where would you normally use a GoTo statement?
As an alternative to the written test (and if you have the resources) you could instead have the candidate write a Visual Basic application in the allotted two-and-a-half hours. Simply set the goal, give the candidate a fully-loaded machine, and then see what they come up with. While this has certain advantages, it also requires more subjective scoring of the applications, and therefore it's harder to compare apples with apples.
These days (even with the skills shortage) any potential TMS recruit could be forgiven for feeling like they're under the microscope. They're likely to have submitted a detailed résumé, been grilled over the phone and will have probably attended two interviews, and, of course, taken a technical test! In addition to assessing someone technically at interview time, we also assess the probability that they will fit in with the company culture. For both their sake and ours, anyone that we feel won't fit in with the way we work simply won't be hired. It makes sense that if a developer is a great technician but perhaps also a total soloist, then, sad as it might be to not have their skills in the company, we won't make an offer. In order to help us ascertain these qualities, we sometimes include some form of psychological profiling, usually in the form of a psychometric test.
A psychometric test is a selection tool used by an ever-increasing number of (typically) graduate employers to reduce their shortlist. Tests usually cover areas such as numerical and verbal reasoning; they're not just "psychobabble." In a nutshell, a psychometric test is a standardized sample of behavior that can be described using a numerical or categorical scale. The tests have an advantage over all other forms of assessment in that they are highly standardized. In other words, the test is the same for everyone who takes it. Therefore, all candidates are observed under identical conditions and their performance is measured objectively against a known and common standard. Also, the methods of interpreting the test results are standard and, once again, objective. There should be no room for error.
The bottom line is that the aim of the test is to match a prospective new employee with both the advertised position and, to a lesser extent, the corporate culture of the prospective employer. For example, if three already successful developers were tested within a team, and a pattern emerged that identified each of them as a highly dominant and extrovert individual, it is unlikely that another developer who is subservient or introverted would fit easily into that same team-or even, for that matter, become a great developer.
Remember to use psychometric tests selectively, and don't become too reliant on them or treat the results as gospel. Mix the tests with the other forms of assessment we've mentioned. Psychometric tests confirm your recruitment decision and support your assessment of each candidate to date. The tests should not be used as the decision-making tool. Unfortunately, many inexperienced interviewers fall into this trap.
As part of your overall recruitment process, you should also decide whether you plan to let each candidate have a copy of the results. Some companies do, some don't. It's human nature that most candidates will want to see their results, and many of the psychometric tests around at the moment will allow you to release selected parts of the results.
Once all the assessments are complete, the interview team needs to get together immediately to consolidate the information and make decisions. People who haven't made the grade should be informed as soon as possible. We normally do this over the phone and explain the reasoning behind the decision and give plenty of feedback. This is nearly always appreciated, so long as it is done in a positive and constructive way. We also take the opportunity to listen to what the candidate thought of us. We find this approach much better than a brief "thanks, but no thanks" letter.
For people we would like to employ, we always phone and discuss our level of interest and listen to their views. If there is a match, we discuss the remuneration package and reach verbal agreement. (This might take more than one call, obviously.) We follow up in writing as soon as verbal agreement is reached.
You might be left with a strong impression that it is extremely difficult to get a job at TMS. We put candidates through a lot! We are aware that we might be missing out on excellent developers by this very stringent selection process. We realize that many techies are primadonnas and are not prepared to go through all of this when they believe that they can walk into any large corporation and get a job. But for those who persevere, we believe TMS is a good company to work for, and part of the reason for this lies in how we treat our staff once they are with us and the perks we provide: Personal Development Plans (PDPs), regular 1:1s, performance reviews, regular market research on salaries, our family atmosphere, our company culture, our beliefs and values, our commitment to training and development, the opportunities to be exposed to leading edge technology, and so forth. That takes us to step three.
Too often, staff can be forgotten once they've been recruited. It's important to have a well-planned induction process and an ongoing career development process. Once you've hired someone you usually don't want to lose him or her! This employee cost a lot of money to find and train and, after a surprisingly short period of time, accumulates an intrinsic worth that's hard to quantify-the employee's knowledge is of high value (for example, they know how the company operates and all about its clients). All in all, you really don't want to lose good people. One of the ways to address this issue is to realize why people up and leave. People generally do this because:
They feel they're not valued in some other way
They're not being stimulated or challenged in their current role
They're not getting the recognition they feel they deserve
They can't see how to progress within the organization (or feel that they can't progress, period)
There are other reasons, of course. Typically, remuneration is not the main reason people leave; so long as they're getting a fair rate and they don't have any of the above complaints, they're happy.
Natural attrition and turnover of staff is healthy for any organization. A company must ensure that they manage to retain the people they want to keep and for as long as they want them. It should be someone's job to make sure that nobody leaves unexpectantly. If anyone leaves like this, that manager has failed in his or her job. Through effective communication and human resources (HR) processes, and in an open, honest, attentive environment, this kind of surprise just shouldn't happen-if it does, something's gone wrong. Did the company not deliver on its promises? Did someone oversell the company's vision and then not deliver on it? Find out the departing employee is dissatisfied and then put steps in place to rectify the situation so that no one else leaves.
In other words, make sure that you have effective and efficient exit interviews, but remember that by the time you get to an exit interview, it's too late to "save" this person. They have already made up their minds to leave and will almost certainly already have another job lined up. Proactive management of your staff while they are employed is absolutely key to staff retention. Be aware of, and deal with, their issues before they get so big as to force them to look around for something else. In some circumstances, it will be right for all parties that the individual leaves. But if you know about it early enough, at least you have plenty of time to manage the situation and to recruit and train his or her replacement. In this way, it's a win-win for everyone, and you can mitigate any possible damage.
This HR management needn't be a full-time position, especially in a small company, but make sure someone is responsible for it and that they give it a very high priority.
We carry out regular human resource reviews via discussions with our staff and questionnaires. Below are some of the issues that we, as a small(ish), distributed, software services company, have identified as being of prime importance.
High-quality communication is vital Here are some of the ways we ensure that we're giving our employees enough feedback:
Only one developer writes a monthly report each month instead of everyone. This monthly report is comprehensive.
Quarterly Technical Days are arranged and planned a year in advance. Technical Days are when all the developers get together for a whole day of technical presentations given by the staff to the staff.
Monthly social get-togethers are arranged, and we schedule a whole year's worth in the calendarin advance.
We're always available for ad hoc contact and impromptu discussions.
Reducing isolation: site visits and reviews A schedule of regular site visits and reviews by managers is necessary to evaluate employee performance. Each manager visits each developer a minimum of five times per year for full-day reviews. These visits are a mix of technical visits and more personnel-focused visits. The technical visits are in the minority, but regular technically-focused telephone conferences are also scheduled. The manager takes the opportunity to speak to the client on the visit, too, but this should not be the focus. The technical visit includes reviewing the work being carried out by the member of staff. Feedback is provided to the member of staff in writing. All site visits are written up and published so that all members of staff are kept in the loop. The entire program of visits and phone calls is scheduled into manager and staff calendars.
Tools to do the job It is necessary to provide a comprehensive toolkit for each member of staff that enables them to do a better job than anyone else around. This toolkit comprises a set of software tools and utilities provided on a number of CDs. Also included on the CDs are TMS's code libraries (see the appendix note on the TDF), coding standards, a copy of our Web site, and other useful documents. Basically, the toolkit contains everything "soft" that might be of immediate use to our developers.
Incentive We find that giving people a stake in the success of the company, whether through bonuses, shares, share options, profit sharing, and so on is absolutely vital to encouraging their productivity and their commitment to our mission.
Human resources It is necessary to have a formal process to ensure quality career development. We use two principal mechanisms:
Performance reviews
These and other specific processes are discussed in the next section.
The PDP is a contract between the employee and the company that identifies and agrees on specific developmental needs for the employee over a given period of time, the idea being that performance can be improved through these additional skills and experiences.
To facilitate the PDP, companies need to define a training and development policy. We would suggest something similar to ours, which is: "We will develop the skills of our employees at all levels, to meet the needs of our customers, both internal and external as well as the requirements of our business, taking into account the personal goals of our employees wherever appropriate."
First let's examine how training and development fits in with the PDP.
What is the difference between training and development? All training is development but not all development is training. Development is the bigger picture, within which there are formal elements of training. All learning experiences, including the formal elements, are called development. A PDP doesn't just concentrate on formal training courses, but includes any experience where the individual learns something.
How do I define the development needs of my staff? You should use and refer to a number of different sources. These include:
The performance review (both the Individual Preparation Form and the review form itself). The Individual Preparation Form is a form containing a set of performance and goal-related questions, which are answered by the person being reviewed and then read by the reviewer prior to the meeting. This form forces some pre-thought and pre-planning.
Individual goals and targets for the year
Company goals and targets for the year
Call these the "tools" if you like. Your PDP is pulling together all these development needs into one plan of action, linked to which should be an agreed upon set of objectives and outcomes that you and the employee expect to get from the development experience. In this way, you are able to justify the cost of any development against your development budget.
How can we ensure continuity of approach? Here are a few things we do at TMS to ensure continuity:
If any of the tools are missing or incomplete, then there is little point in attempting a PDP.
Everyone should use the same language. For companies with large development budgets and/or a large number of staff, it is useful to categorize the development needs as follows:
Soft skills: time management, stress management, assertiveness skills, presentation skills
Management development: management of supervisory skills, team building, leadership skills, finance for non-financial managers
Technical: Windows NT, Java, SQL programming, Object Oriented Design, NetWare courses
Commercial: marketing, finance, human resources
Quality: courses relating specifically to ISO 9001 procedures and processes
Professional qualifications: Certified Novell Engineer (CNE), MCSE, advanced degree, MBA, etc.
If you break down your development budget into fields, it becomes easier to track and analyze your development spend against a particular category of development.
Everyone should categorize the development in the same way. For example, your categories should include mentoring/coaching, on-the-job training, training temporary replacements to fill in while staff is away, cross-departmental training, internal/external training, conferences/seminars, professional accreditations, industry-specific readings, writing for magazines and books, and orientation for new employees.
10 essential points for managers We would like to give credit here to Training and Development: Analysing the Need, Developing the Plan, and Implementing the Strategy by Sue Mathews. She suggests these 10 key objectives and strategies that managers should be sure to follow:
Clarify the overall and specific objectives. Overall objectives refer to the company's development strategy and objectives and specific objectives refer the individual's objectives, both job related and personal. Make sure that any development need identified can be linked to the achievement of company objectives, otherwise the development will not be cost effective. The individuals can see what the company is doing and how, and how their own development requirements fit in with the overall strategy and achievement of goals.
Make sure that everyone understands the expected outcomes. Communicate to staff that every development activity carries outcomes with it; that is, make sure the staff knows what is expected to be different as a result of the development experience, and that staff will be measured in relation to how well those outcomes have been met.
Realize that all problems cannot be resolved by training or development. Realize that some problems are not development issues but might be linked to other things, such as inadequate resources or inappropriate systems or structures. Lack of knowledge might contribute to these problems, but training and development will only deal with the symptom-not the cause-in such circumstances.
Set clear and measurable performance criteria. Make sure that all development activities perform to agreed upon standards and criteria before they are implemented and the cost is incurred.
Recognize that training and development are corporate issues. Bring training and development off the sidelines and into centerfield. Don't merely pay lip service to it or to PDPs: make sure that a senior manager or a director owns it, and put it on the agenda for management and board meetings and for one-on-one (1:1) meetings.
Development should not just be for the "stars" in the company. Development opportunities should be genuinely available for everyone; not just a few favored staff members. PDPs and the development budget must ensure that all staff have fair and equal access to development. If they don't, the PDP isn't working.
Don't make training and development an additional organizational "stressor." If you want staff to get the most out of their development opportunities, make sure that they are supported in managing their workload. If you don't ensure this, staff will not want to attend because of the sheer volume of work waiting for them upon their return-a major development demotivator!
Be prepared to sell your development ideas. Everyone should be prepared to sell the benefits of their development needs, because not everyone else will share their enthusiasm. Be prepared to think laterally about the best way of learning (this need not be just through formal training courses). All development ideas should be justified, because there will always be a cost attached.
Correlate the development activities with the bottom line. If you can clearly demonstrate how closely the development need or plan is to profit and other corporate issues, the more likely it is to be accepted. Always be prepared to argue the business case.
This section contains a step-by-step guide to identifying a development need for a principal accountability in the job description. The aim is to give the employee every opportunity to achieve individual goals and enhance performance in the job.
Within the job description there will be a number of primary responsibilities. These are the key duties of the job (note that these do not cover every duty, just the main ones). Normally you would expect to see between five and eight duties depending on the seniority of the position.
Look at each primary responsibility in turn. Consider what goals or objectives should fall out of each primary responsibility. There might only be a few goals for some primary responsibilities, but others might have numerous goals. The goals are linked specifically to the person doing the job, and will therefore reflect their abilities and length of time in the position. Achievement of the goals should be linked to the performance review period whenever possible. Employees should have 12 months in which to achieve their goals, or as many months as possible within the performance review period. Obviously, if this exercise is not carried out until halfway through the review period, the goals must reflect the time the employee has to achieve them. Then decide how far in advance you are looking at development needs-a quarter, six months, or maybe the full year.
Transfer the goals to the PDP sheet.
For each goal, agree what development need or needs fall out of this. You're looking for any additional support or knowledge the employee feels they must have in order to achieve the goal. In other words, you're committing to this development (whatever it may be) so that the employee will be confident that he or she can achieve this goal within the time indicated. Development does not need to be a formal training course. Think laterally and look for the best way of satisfying the need.
Agree on a date by when this development should take place. Be realistic and link this date to the date by which the goal must be achieved. Obviously, the development process needs to take place well before the goal is to be achieved.
Decide who owns the action for ensuring that the development process is organized and takes place. If it's written down, there will be no confusion, and the person owning the action will make sure that the process takes place because they are accountable for it.
Agree with the employee what outcome is expected from the development experience. All development (even mentoring) will have a cost to the company and, so look at what return on investment can be expected from the cost incurred. Clarify the reasons why the development is necessary and double-check that the development decided upon is actually the most appropriate one to help the jobholder achieve the goal. Both parties now have something concrete to focus on now and at the post-evaluation stage.
The PDP should be on the agenda for review at every 1:1 meeting, just to see if any updates or changes need to be made. If a development process has been completed in between meetings, you need to complete the post-evaluation section and jointly agree how well the original objectives have been met. There will be occasions where the development process has not delivered what was expected, in which case you and the employee must agree what should be done. Don't hold the post-valuation meeting too soon after the development process-give the employee time to put their newly acquired knowledge into practice.
The employee owns the PDP, not the manager. The employees are the ones who should drive the process in conjunction with the manager, not the other way around.
When you get to the performance review itself, this form, along with your notes from every 1:1 meeting, will be invaluable. If this form has been completed properly, most of your preparation work for the performance review will be contained here. The ideal scenario is one in which every development process has taken place and every process has had the desired outcome, so every goal has been achieved or even over-achieved. If any goal has not been met, this form should give you a record of the reasons why. Whatever the reason, the circumstances should be contained in some way in this form.
You might want to modify this form for your customer. Agree with them what the primary responsibilities and the goals relating to the project are, and agree on development needs with them, if appropriate (you might even get them to share the cost). This form could serve as an excellent record of performance per project, and if the employee completes more than one project in a year, all the forms must be considered at performance review time.
This system will be of value only if regular meetings are held to review progress and if the preparation work is carried out in the first place, meaning that current and accurate job descriptions are prepared, primary responsibilities are agreed upon with the employee and reviewed regularly, and the goals are reviewed to ensure that they reflect the business needs as well as the needs of the individual.
Here's an example of a PDP within the six-month period between January and July 1998 and for goals that were set before January 1998.
Sample PDP
|
NAME: LES ARMWELK |
||||
|
JOB TITLE: HR MANAGER |
||||
|
DEVELOPMENT FOR THE PERIOD: JAN '98 - JULY '98 |
||||
|
DATE OF REVIEW: 3/29/98 |
||||
|
PRIMARY RESPONSIBILITY: Improve company recruitment process and recruit all new heads per Plan '98. |
||||
|
Goals |
Development needed |
By when |
Owner |
Outcome expected |
|
Ensure that all new heads are recruited in time, at the right quality and cost. |
Project management training (external) |
End Jan '98 |
LA |
Ability to project manage the whole company's recruitment process (100+ heads per year) |
|
Advanced Interviewing Skills course (external) |
End Feb '98 |
LA |
To participate in and make decisions on at least 50 percent of all second interviews by the end of March '98; 70 percent by the end of July '98. |
|
|
One-hour sessions with each departmental manager to understand and assess company's Headcount Plan |
End Feb'98 |
LA |
To be able to recommend to the Board the proposed recruitment strategy for each quarter in advance and to make recommendations for change to the Headcount Plan. |
|
|
Introduce psychometric testing to the company's recruitment process by Aug '98 |
Research an appropriate battery of psychometric tests and present recommendations to the MD |
Research complete by end May '98. |
LA |
To gain MD's approval for tests to be introduced at first presentation. |
|
Presentation to MD by end June '98 |
To have a working battery of tests in the company that adds value to the recruitment process. |
|||
|
Presentation to all Dept Managers by end July '98. | ||||
|
POST EVALUATION |
||||
|
Development need |
Actioned |
Objectives met? yes/no |
If no, next step |
Actioned |
|
Project management training external) by end Jan'98 |
YES |
Will not be known until end of Plan year, but initial signs are good (Project Plan has been prepared). | ||
|
Advanced Interviewing Skills course (external) |
YES |
YES Les is participating in 50 percent of all second interviews and is on course to exceed the 70 percent target by end July '98. | ||
|
One-hour sessions with each department manager to understand and assess company's Headcount Plan |
YES |
NO Les requires more detailed financial training in order to understand departmental recruitment budgets |
Two 1-hour sessions with the Finance Director on Profit & Loss and Budgeting & Forecasting |
YES Completed by 15 March '98 |
|
Research an appropriate battery of psychometric tests and present recommendations to the MD |
NO |
NO Research is unlikely to be complete by end May '98 |
Research to be complete by end June '98. |
YES |
|
Presentation to MD by mid June '98 |
YES |
|||
The performance review is intended to summarize the development meeting (which can occur annually or more frequently) between the manager and each of his or her direct reports, during which each jointly reviews training and development activity and work achievements during the past review period and agrees to action plans for training, development, and work-related goals for the coming review period.
The review meeting itself should be seen as a two-way process: as a tool that enables you to assess past performance while also looking ahead at future goals. It helps to guide everyone towards optimizing their abilities so that the end result is that both company and individual goals are met.
The only way company goals can be met is if everyone carries out their own role properly, and so it follows that efficiency and effectiveness must be monitored on a regular basis. The manager and the company should provide every assistance to the employees to enable and allow for optimum performance.
There are many different ways of measuring performance, but the one used most frequently in performance reviews concentrates on measuring achievements against specific goals (or performance indicators). Within the job description are a number of primary responsibilities. From those, the employee and the manager agree to certain performance objectives, or goals, with the intention that shared goals result in a commitment to those goals. The performance of the employee is assessed against these goals over a specific period of time. The overall performance level for the period under review is summarized in one performance rating. Any percentage increase to salaries is directly linked to the performance rating as well as to the company's ability to pay (this is where the company's revenue and profit come in).
In general terms, the main purpose of a performance review system is summarized below, although not in any particular order:
To set performance objectives for the future
To help improve current performance
To set and agree on future goals
To assess increases or new levels in salaries (salary levels can go down as well as up, or even stay the same, depending on performance)
To assess training and development needs
To assist in career planning decisions
It is another aspect of communication and an opportunity for you to build a closer relationship with your staff, and as such should be seen as a positive step forward.
The review meeting The following are guidelines for conducting the performance review meeting:
The meeting should be conducted with tact, diplomacy, sensitivity, and above all, in a professional manner
The manager should never talk "off the record" during the meeting
The manager should never make promises during this meeting unless they have been discussed and agreed upon beforehand
The manager should not get drawn into discussing salary reviews during the main part of the review; rather, the manager should have an authorized percentage increase to give to the employee when they receive their performance rating. (After all, that's really what they're waiting to hear!)
At the start of the meeting, the manager should briefly outline the format and structure of the meeting and give the employee an idea of the duration. (It's a good idea to schedule at least an hour per review meeting if the review period is six months; otherwise, schedule two hours if the review period is one year.)
The manager should let the staff member know that he or she has reviewed all the 1:1 notes, as well as all client feedback, and their own individual comments in reaching the conclusions contained in the review form itself. Have these forms available during the meeting for reference purposes.
The manager should work through each section of the review form in turn. The employee should be given the opportunity to comment on what the manager has said and make notes of their comments for the manager to consider before finalizing the wording of the review form.
The manager should finish the review meeting with details of the overall performance rating and the percentage increase to be assigned to the employee's salary.
The manager should let the employee know that he or she will write up the form and get it to them within two working days of the review meeting for them to sign. Once the manager has the review form back, he or she signs it and makes copies as appropriate.
Follow Up The manager is responsible for these action items after the review meeting with the employee:
The manager should review those points where follow-up action has been agreed upon and ensure that the action happens.
The manager should ensure that any follow-up action that he or she commits to during the review is documented and the individual informed.
The Individual Preparation Form and the review form don't cross-reference each other or follow the same lines in the questions they ask. This might make it more difficult to use any information from the individual preparation form in preparing for the review meeting.
1:1 meetings The objectives of regular meetings between managers and their direct reports are to provide a regular and focused opportunity for mutual communication, feedback, and exchange of information in the following ways:
Performance feedback
Review of training and development needs
Communication of information to allow both the manager and the employee to improve their performance
The upward flow through management of concerns, information, or requests for improvement
Maintaining and improving the relationship between the manager and the employee
The frequency of the 1:1 meetings depends on the preference of the employee and the manager, but as a guideline, these meetings should be held a minimum of every six weeks, preferably every four weeks. More frequent meetings might be necessary for new employees or for staff undergoing difficulties or tackling steep learning curves. Each meeting should be long enough (usually an hour; no more than two) to cover difficult issues and build enough rapport for open and honest feedback (top down and bottom up). The meeting should be held where there are no interruptions, preferably on neutral territory. The style of the meeting depends on the individual concerned and the areas to be covered in each 1:1. The meeting can be semiformal, very formal, or informal. You might need to use different styles depending on the performance of the employee and the areas that you need to address. Most important is that the style is an effective one.
Try to keep to the same framework (per the template) so that a certain discipline is instilled into the meeting, and so the employee has a chance to prepare beforehand. The actual content of each meeting will vary depending on performance issues. Always agree on any follow-up actions arising from each 1:1. Give the employee a copy of any notes immediately after the meeting for his or her records and as a reference for the next meeting.
The 1:1 process is absolutely key. You should capture any PDP issues within the agenda for any 1:1 meeting. If you hold regular meetings and follow the agenda, your preparation for any performance review will be relatively simple. Similarly, you will give yourself an opportunity to address any problems before they become big issues. Managers who implement regular 1:1 meetings with their direct reports and conduct them properly can ensure an almost 100 percent zero-defect rate in appeals, performance review surprises, grievances, and disciplinary matters.
Performance reviews should be viewed as a project, and as such, a project plan should be developed over the whole performance review period, culminating when all performance reviews are to be held. For the purposes of the table below, let's assume that the performance review period is a year that starts in March and ends in February with the review itself. A basic Critical Path Analysis might be as follows:
Preparation Work
|
Area |
Action |
Timeframe |
|
Job descriptions and primary responsibilities |
Write and agree upon job description with employee focusing on the primary responsibilities |
End of Feb |
|
Key objectives (or goals) |
Isolate agreed-upon goals from each responsibilities and discuss the timeframe for achievement over the 11-month period with the employee Make sure that you also link the goals to the Individual Preparation Form Consider asking the clients to give feedback on the employee against the performance areas listed in the Individual Preparation Form; otherwise, you will have no objective feedback on performance in these areas other than the employee's own |
End of Feb |
|
1:1 meetings |
Set up 1:1 meetings in your calendar for every month from March to January |
End of Feb |
|
Budgets |
Board to agree on amounts to be assigned to (a) performance review increases for total company, and (b) percentage increases to be assigned to each performance rating |
Dec |
Preparation Over the Performance Review Year
|
Area |
Action |
Timeframe |
|
1:1 meetings |
Make sure that you hold regular 1:1 meetings with the employee every month to review progress and performance against every one of the goals and objectives Obtain regular feedback from the employee's client on his or her performance against predefined goals Rate the employee's performance against each goal every month using the same criteria as in the performance review form (for example, A, B, C, D) Make sure that the goals and timeframes are reviewed and revised in line with the changing business needs so that they are always current |
Every month from March to Jan |
|
PDPs |
Identify any development needs that are agreed upon during these 1:1 meetings with either the employee or the client and transfer these needs onto the employee's PDP form, ensuring that the development process actually happens (this gives the employee every chance to achieve or surpass their objectives) |
Every month from March to Jan |
|
Booking performance review meetings |
Book a review meeting in your calendar for every employee who reports to you. You should assume one review in the morning and one in the afternoon (more than this is too many in one day) Book an appropriate venue Let each direct report know the date, time, and venue for their review throughout February |
First two weeks in Jan |
Preparation Just Before the Performance Review Meeting
|
Area |
Action |
Timeframe |
|
Individual Preparation Form |
Each employee should complete and return their preparation form to you at least 10 working days before the performance review meeting |
Mid Jan |
|
1:1 meeting notes |
If you have held 1:1 meetings every month and assigned a performance rating against each goal as you have gone along, you will have comprehensive records of performance throughout the year. You need only to average these to come up with a rating covering the whole year. It should be a simple process. |
Mid Jan |
|
Individual Preparation Forms |
Read each person's Individual Preparation Form and determine (a) those areas where there is consensus of opinion between you and the employee, and (b) those areas where your opinions on performance differ. Where you differ in opinion, determine why and decide which opinion you will discuss at the review meeting. |
Second two weeks in Jan |
|
Client review forms or notes |
Review all the client notes you have for the 11 months and compare these with your 1:1 notes and the Individual Preparation Form notes. As above, determine (a) where there is consensus between the client, you, and the employee, and (b) where the opinions differ Where there is a difference of opinion, decide which opinion you will discuss at the review meeting |
Second two weeks in Jan |
|
PDPs |
Review the employee's PDP and make a note of any development that had been requested and agreed upon but that had not taken place. |
Second two weeks in Jan |
|
Appraisal form |
You can either complete an appraisal form in note form or make comprehensive notes and complete the form after the review meeting. Remember that meeting the employee will still have a contribution to make at the meeting, so don't make it look as though you've already decided what will be included. Wait to hear the employee's side of the story before finalizing the form, although very little in that meeting should be a surprise to either you or the employee if you have held regular 1:1s |
Two working days before the review |
Follow-Up from the Review Meeting
|
Area |
Action |
Timeframe |
|
Finishing the performance review |
Write up the performance review form and send this to the employee for his or her comments and signature. As soon as you have their signature, you should sign the form as well. When this is done, the performance rating is authorized Give a photocopy to the employee and keep the original in his or her personnel file |
No more than the three working days after the performance review |
|
Assigning salary increases |
Follow up with a semiformal letter to the employee stating (a) his or her performance rating (b) the percentage increase that has been assigned to this rating, and (c) his or her revised salary with effective date. The original goes to the employee and a copy goes into his or her personnel file Actual salary increases should be incorporated into your budget. |
Immediately |
|
Setting new goals |
Sit down with the employee and mutually agree to new goals and objectives for the coming 11 months, and start the process all over again |
Complete by mid-March, so that employees have 10.5 months to achieve new goals |
Some companies are offering "golden handcuffs" (stock options) in response to the Year 2000 situation, meaning they hope the money will keep their employees around. Others are putting off the decision as to whether to offer cash inducements until the situation unfolds and possibly worsens. Many experts, however, feel that golden handcuffs will not have the desired effect. As we've said above, money, typically, will not be enough to keep people. People leave because of unsupportive management, lack of opportunity and/or a lack of fit between the company's and the person's values. A fulfilling career, challenge, and fresh skill acquisition are what keeps people. We feel that payments based on people staying is really a just form of bribery, and proper career development and training are more important in the long run.
Of course, if you follow all the advice in this chapter no one will ever leave. Well, er, maybe they will. Inevitably an employee is going to leave sometime. When this happens you should treat this as a good opportunity to get some frank feedback about how the company has performed. For example, is the person leaving because they've been offered the job of their dreams elsewhere, or are they disillusioned with their current employer? (You!) If they're leaving for the latter reason, others probably are, too. This is your chance to find out.
People do come and go-that's life. Don't be disheartened if they go. Just treat it as a valuable opportunity, learn the lessons, and go back to Step 1 all over again!
Microsoft Certification and the Testing of Developers
Mark Pearce
Regardless of how much or how little they are paid, bad software developers are always extremely expensive. Hiring developers can all too often be a hit-or-miss affair. You talk to a guy, ask him some questions about his current and past work, and then ask him to answer a few ad-hoc technical questions. He seems personable, maybe even enthusiastic. Perhaps he stumbled over some of the technical questions, but he answered a couple of the others in convincing detail. He certainly seems to be able to "talk the talk," at least superficially. He knows all the latest buzzwords-COM+, MTS, ActiveX servers, polymorphism, etc. But if you don't have, for example, TMS's "Test from Hell," how do you know if the person that you're about to hire has constructed a facade of technical knowledge specifically to cover up his lack of real-world experience? And how do you measure him technically against the developer that you interviewed yesterday? Given the extremely large sums of money that can be commanded by developers nowadays, what would you give for some form of objective and comparable measurement of a candidate's job skills?
One approach is professional certification. Microsoft offers several different types of technical certification in their products, each designed to show a high level of competence in performing tasks related to the skill being tested. From our point of view, the most important qualifications are Microsoft Certified Professional (MCP) and Microsoft Certified Solution Developer (MCSD). The other popular qualification is Microsoft Certified Systems Engineer (MCSE).
An MCP has passed a mandatory product exam, for our purposes either Visual Basic 4 or preferably Visual Basic 5 (exams #70-065 and #70-165, respectively). Note that these are due to be replaced in the latter half of 1998 with the new Visual Basic 6 exam. The MCSD certification is more advanced and aimed at developers who have to design and develop custom business solutions with Microsoft development tools and technologies. It consists of two mandatory core exams, Microsoft Windows Architecture I and II (exams #70-160 and #70-161), and two elective exams from a list that includes Microsoft Visual Basic 5 (#70-165), Microsoft Access for Windows 95 (#70-069), and Implementing a Database Design on Microsoft SQL Server 6.5 or 7.0 (#70-027 or #70-029). Finally, the MCSE qualification is aimed mainly at people who implement and support networked information systems with Microsoft NT and Microsoft BackOffice. It consists of four mandatory core operating system exams and two elective language/product exams.
Most of these exams cost $100 each to take, are closed-book and computer-administered, between 60 and 90 minutes in length, and consist of a series of multiple-choice questions. They are designed to test the specific skills needed for the job functions being tested. Obviously every job function requires different levels of skills, from memorizing facts to analyzing scenarios, designing solutions and evaluating options. The exams aim to measure a candidate's performance in these job functions rather than just a candidate's knowledge of a product or terminology. In my experience, the questions are, on the whole, well researched and well written and do indeed perform a reasonable job of measuring a candidate's specific job skills. Microsoft insists that none of the exams contain "trick" questions. So let's just say that occasionally a candidate has to read a question very carefully and probably several times-a few questions are more about reading comprehension than about knowledge of the product or skill.
While the exams do have some professional standing in the IT industry and are considered to be fairly demanding, they also have a couple of inherent drawbacks. The first is that each exam is designed to measure general competence in a particular area. Often more useful is the measurement of a specific competence, such as the use of DCOM or an understanding of how to implement ActiveX servers efficiently. As Visual Basic becomes larger and more complex, there is a need for developers who specialize in specific parts of the product. If you're building small teams, with each team specializing in one area, construct your own tests (verbal, written, or computer-administered) to measure thorough competence in that area. By all means follow the Microsoft test format if you want, but engineer your questions to concentrate on the specific areas you need. Refine the questions over time based on candidates' results and feedback. Eventually you will have a test suite tailored to your own requirements.
The second drawback is that the Microsoft exams all use a multiple-choice format. This enables computer grading of tests, without the need for human involvement. However, it is sometimes useful to present open-ended questions, such as asking a candidate to write Visual Basic code to solve a particular problem. Although these types of questions are more subjective and require expert human input to judge the answers, they can also give you more insights into a developer's thought processes and way of working than those questions that use the multiple-choice format. You can also ask more unusual questions. One of my favorites is to ask a candidate what question he or she would add to the test, and how would he or she answer their own question.
My advice is to use the Microsoft exams as a useful tool, and then supplement them with a test of your own design to refine your knowledge of a candidate's technical competence. Be prepared to spend some time constructing your test to ask the right questions in a non-ambiguous manner. You are likely to be paying any new hire tens of thousands of dollars, or even hundreds of thousands. It makes no sense to hire just on gut feelings or on inadequate testing.
|
