Pissing off a candidate before you even talk to them

I recently had the joy of hunting for a new job. Its not a new experience for me, quite frankly I've done it more often than I care to admit. I took the same tactics I always have in the past. Updating my resume, posting it out on some job boards, reaching out to my network and contacting some recruiters that I have worked with in the past. The thing is, during this most recent hunt I became aware of what seems to be a new tactic among some recruiters that quite frankly pisses me off.

I have a good resume, and a lot of experience with all the right buzz words for certain positions. In short to some recruiters I am a dream candidate, and in that respect I can understand why it is they are doing what they do... and that is call me TWO OR THREE TIMES IN A ROW.. or call me EVERY SINGLE DAY FOR THREE WEEKS STRAIGHT!!!

Allow me to explain why this is a problem. I have had a pet at the vet undergoing surgery. Im waiting for them to call. The thing is I get so many calls from recruiters EVEN WHEN I'M NOT ACTIVELY LOOKING that I CAN'T pick up my phone on the first call. EVER. My pet could be dying on the table and I have to look at my phone and ACTIVELY choose whether its worth the risk to answer the phone. I have a child that may or may not need to contact me from a strangers phone in case of an emergency... Guess what? same problem! What if my wife gets into an accident? Bank needs to get in touch with me? Any one of these scenarios!

Look, I get it, you guys are trying to make a living... But heres the thing, I used to be able to just assume that if I got one call from a number it was a recruiter, I'd listen to the message and then decide if I wanted to call them back. I mean hell that's why I have a phone... MY CONVENIENCE... not yours. If someone called me twice in a row I'd assume that person had a legitimate reason... NOT ANYMORE!

The most frustrating part of it is that I have had people call me like this, AND NOT EVEN KNOW MY NAME OR MY RESUME. I'm sorry, that's just lazy, and if you are doing such a shitty job recruiting me, you can be damn sure I'm not going to hire you to put my in front of a business... After all by agreeing to let you submit my resume, that is what I am doing!

So to summarize, stop calling people non stop. If they aren't into what your offering, they aren't into it. Calling me 30 times over the course of the week isn't going to change my mind. If I don't call you assume I'm not interested. I have 10000 things going on in my life and the reality is that my time is valuable. I am very choosy as to where that value goes, and in that respect try to create a relationship with your recruitee. I may not choose the position that you are trying to recruit for this time, but I am going to be in the market again at some point, and a good recruiter is worth their weight in gold. And for fucks sake know the name and resume of the candidate you are trying to contact. When you don't you just look like incompetent and useless.

Software Development and Quality Engineering

I can't tell you how many times I have heard developers and managers pay lip service to quality and testing. I cringe every time I hear the words "quality is important to us, but we need this done ASAP!" from management. I likewise cringe every time I hear a developer say "I did a quick test on it, QA will catch anything I missed". Both of the previous statements are just wrong. More importantly they are idiotic and a total fucking cop out. If code quality is of any importance whatsoever, it is absolutely VITAL that you think about the quality of the final product before you even start coding.

There are two huge hurdles that most organizations must overcome if they want to produce a quality product. These two hurdles are going to sound so idiotically simple, that you may stop reading, but please bare with me, as I explain. One hurdle is time, the second is terminology. I know those sound kind of silly but hear me out.

Time

We all know that there are deadlines that must be met. Sometimes we absolutely positively MUST get a deliverable out the door. The thing is, this does not happen in a vacuum. Working more hours, eating into testing time, sacrificing writing unit tests, throwing in hacks that will be "fixed later" all ends up sacrificing code quality. 

I'm sure as developers we've all at least heard of the mythical man month. The idea that throwing more developers at a project actually makes the project last longer. Yet this same phenomenon seems to be completely ignored when it comes time to complete Quality or User Testing! You cannot compress testing time and throw more testers at a problem and expect a quality result! It doesn't work that way! Have you ever seen a large group of testers testing functionality? It's a logistical fucking nightmare to begin with. Duplicate bugs are regularly reported leading to multiple developers trying to fix the same code from multiple different spots, which either leads to wasted time and duplicate effort and frustrations by both developers and testers!

Yet it seems in many places when a testers say we need two weeks to test some critical part of the system, it's viewed as a nice to have. This is simply not the case! Good testers understand that what they are doing is making sure that user doesn't have a "what the fuck" moment. Ultimately I hope you realize what a user with too many "what the fuck" moments can also be a called an "ex-user".

Terminology

This brings me to my next point which is terminology. I purposely used the word "tester" in my previous section, but you know what, that's the wrong word. In Software Engineering we are so fortunate to have a vocabulary that allows us to express abstract concepts to quickly convey meaning. Language, Object Oriented, Classes, Methods, Interfaces, Factories, Constructors, Compiler, Scripts all great words, and for the most part universal for developers. These words are important in their own ways, and yet it seems for some reason when it comes to code quality and testing we don't have quite the same vocabulary.

I absolutely abhor the word "Tester" to describe what these individuals do. Oh sure, they run tests, but that just makes it sound like something a monkey could do, and quite frankly that's just very, very wrong. Likewise I dislike the term Quality Assurance as that term seems to express the idea that quality is something that should be bolted on to the end of a project. Which in turn leads to the perception that you are "testing" the deliverable. This too is wrong.

Quality should be the focus throughout the process. Quality of the code written. Quality of the design and architecture. Quality of the final deliverable. This is not an process that can happen at the end, but a process that should happen THROUGHOUT the cycle! So since this is something that should happen throughout the process, the job description and name should change. I personally like the term that my friend and boss Pat Richards uses: Quality Engineering. After all that is what this process is aiming to do! 

Most importantly though, by changing the name to Quality Engineering you change what it is you are actually trying to accomplish. You are engineering quality right into the process. It makes much more sense to have someone who is called a Quality Engineer being a part of the initial design and estimation sessions, and that is a huge part of why Terminology is so important! 

Changing what you call something can totally revamp the way you look at its function. Equally important is making sure that everyone uses the SAME terminology. I have had a developer say to me "I am in the process of unit testing my code." That to me meant they were writing automated unit tests, since that's the terminology I use. What they meant was that they were doing developer testing on the module they had just wrote. They weren't wrong with how they phrased it, but because we weren't on the same page with terminology, I made some very wrong assumptions on the code base.

The same problems can arise on the transition from Development to Testing cycles. This too is why it is so important that Quality Engineers be involved in the whole process from beginning to end. By being embedded with the team that is developing a module, they come to use the same common terminology as the team, thereby decreasing communication problems and increasing understanding and thereby productivity. After all not having to circle back to make sure you think you understand whats going on is a huge time saver. 

 So bottom line is if you want to make sure you are delivering quality products, you have to be sure that you have a process in place that supports it. Robbing Peter to pay Paul by giving developers more time to write code and sacrificing final testing time is a quick way to failure. Likewise treating testing like it is something that CAN be sliced and sacrificed is a quick way to doom you deliverable to failure (or at least poor results). Never underestimate the importance of your choice in wording, and naming. Names have power that create preconceived notions in others. If you want to ensure quality, make sure the terminology that you use empowers that agenda. In addition make sure everyone is on the same page and speaking the same language. Anything short of that is a quick road to a bad result.