Face it, the IT world is a tiny tight-knit community where everyone knows everyone either directly or indirectly through our own private game of 6-degrees of separation. So, why do most employers treat potential recruits more like pesky cold-calling-vendors than like valued potential future clients?
Think about this; how many resume's do you think an average company receives & reviews for a given IT job before they hire? Of all those candidates, you pick only one, and you treat them as a part of the family (as you should), while the remainder of the people in that stack of papyrus are discarded and readily forgotten like some non-winning lotto ticket.
However, the same is not true for the applicant. They remember how you and your company treated them during the application & interview processes. They tell their friends, and any time your company comes up in conversation in the future, they still have that (often first) impression of what it is really like to work for your company. How do you think your company would fare in such a conversation?
Being professional while recruiting means treating your candidates respectfully and with care. This includes basic things like giving them a simple acknowledgment when their resume is received, a timetable for the hiring process, and a subsequent response notifying them if they were not chosen. Also, sometimes things come up; Positions are put on hold, hiring delayed or canceled for various reasons - those too are times the applicants should be notified.
So, for all you IT people out there;
- How many times have you received acknowledgment after submitting your resume'?
- How many times have they thanked you for applying for the position?
- How many times you been notified if they hired someone else? (assuming they didn't hire you)
- After interviewing for a job, how many times have you left without even a
basic understanding of how long the interviews will continue and when
they will make a hiring decision?
For me, I can't count the number of times I have received little to no response from a potential employer either before or after an interview. Recently, I was talking to a friend with a highly successful career who was looking to change jobs and he related a similar experience. In his case, he was really interested in a job for which he applied, and even took the time to followup asking for an update as weeks turned into months. He received only some basic responses with little detials, which failed either to inspire hope of future employment or to let him know it wasnt going to happen.
When this happens, at best it makes you feel apathetic towards the company, but it can also make people resentful at such a lack of professionalism, and at worst when the process is really mishandled it can leave you with a very bitter and negative feeling about the entire company.
When this becomes a consistent problem, this reputation builds over time as we in the IT community meet at our various conferences and share these stories. Eventually, you and your company may become labeled with negative terms such as "unorganized, "sweat shop", "elitist", "beurocratic", "political", "ma-and-pa", "rinky-dink", etc.
This initially may impact future hiring, but later it can begin to affect your entire brand, especially if your company sells IT products to those same IT professionals. In this case, you may have added some unnecessary pollution to your very customer pool that can, over time, begin to errode your company's bottom line.
Moral of the story; follow the Golden Rule, consider hiring (or assigning) an HR person (or staff) to manage these important relationships, or even outsource your recruiting altogether rather than create such a reputation. Simply acknowledge these people and treat them like human beings rather than a stack of papers.
IT's a small world afterall.
The Try/Catch block is the source of many of my pet peeves, here is one of my favorite petty annoyances:
Eating Exceptions:
try
{
… do something meaningful
}
catch(SomeException ex)
{
// eat exception
}
This is an example of a block that is intended to eat exceptions (for the sake of argument, lets assume there is a valid reason).
[remark: i'll save my lecture on the pitfalls and evil of eating exceptions for another day]
I see this in many projects. In and of itself the code isn’t bad, depending upon its usage. I just dislike seeing the “ex” variable hanging out there. The variable name is redundant and generates the warning “The variable 'ex' is declared but never used.” Instead, just omit the variable name, and keep the exception type filter like this:
try
{
… do something meaningful
}
catch(SomeException)
{
// eat exception
}
More than anything else, what bothers me is the REASON why the “ex” variable was left-in. Usually, developers leave it so they can see the exception when stepping-through code in the VisualStudio debugger.
I wonder if the following should be done:
A) Make the Visual Studio debugger treat catch blocks differently and always step "onto" that line and give you a smart tag with the exception instance being caught/eaten.
B) Add a new keyword to C# (and other languages) to make “eating” exceptions more explicit. Ex: try/eat or try/catch/eat instead of try/catch
[update: pruned this post to avoid conveying the sentiment that eating exceptions is a good thing (thanks to Paul for making me smack myself upside the head)]