Good tech recruiters rock, bad ones…well Monday, 05/14/2012
Posted by Percy in Work.3 comments
So, after reading The Three Laws of Robotics (for tech recruiters) and going through a recent job search, I thought I would throw my two cents in. It’s been a few years since I’ve gone this route in looking for a job, and things have changed a lot. I guess the field is a LOT hotter and the number of recruiters must have grown exponentially.
Now, before I go to far, there are a number of wonderful tech recruiters out there. I’ve dealt with many recruiters that try to get to know you, know your local area, and represent both you and the company they are trying to place you with well. They actually care about their job and do their due diligence. Too, they take the time to understand your current situation, and they act accordingly. Truly, they are a pleasure to work with. I would even start to call some of them friends. I know who they are just as much as they know me. If I’m ever looking for a job again, these are the guys and gals I’d go back to in a heartbeat. Too, some will even give you honest advice about opportunities that other recruiters are bringing your way. Too, if you’re in the job hunt, let me know because I’ll send them your way and you won’t be dissapointed.
Too, I realize the this is beyond a first world problem. This is a problem that’s even rare among first world people. I realize that having people knocking down your door with viable job opportunities is something that a lot of people would be glad to have. Trust me, I’m extremely grateful and thankful as I go through this process.
However, for every good one out there, there’s about ten polar opposites who do everything wrong. They make you feel like you’re in a meat market and you’re just a number to them. They’ve seen one word in your resume that might line up with one word on some job description. So, they pounce and start sending you jobs that don’t even interest you. They really give the technical recruiting business a bad name and a black eye. To them, I’d like to give out some friendly (or maybe not-so-friendly) advice. The good ones out there already do this, so you should learn from them.
Fair warning – what follow can be considered a rant. Continue at your own peril (<Monty Python and the Holy Grail Reference>unless you like that kind of thing</Monty Python and the Holy Grail Reference>)
Do your homework
This really comes down to one thing – know your candidate before you even contact them. As I started my search, I was explicit about wanting a full-time direct hire (as opposed to contract) position and I was not willing to relocate (i.e. I want to stay in Atlanta). If you see that on someone’s profile, don’t contact them with a contract opportunity in Timbuktu. Now, I’m sure Mali is nice this time of year, but I’m simply not interested and I’ve made that abundantly clear. Too, I know you got my info from one of the major job boards (b/c I use a certain e-mail address), and I’ve been explicit about what I’m looking for. So, there’s no good way to feign ignorance in this area.
Also, don’t contact me about positions at my current company – yes, that’s happened to me. I wasn’t looking at the time, but when I started up my job search this same person contacted me about opportunities. So, you’ve already proven to me that you don’t do your job very well. Do you really think I want to have someone like that representing me? What kind of quagmire would I be in if my current employer didn’t know I was job hunting and you presented me back to them? If you haven’t taken the time to read my resume and at least check out my LinkedIn profile, you’re not ready to contact me.
Too, if I’ve done .NET development for a few years, there’s a really good chance I still want to do that. So, don’t contact me about a Java developer position unless you KNOW that I might be interested. Too, you’ve got to know that I’m probably not interested in a sales position if I don’t have a single reference to a sales position on my resume.
Embrace e-mail as a viable channel of communication
If I’m looking for a job, and I currently have a job, it’s not the easiest thing to step away from my desk every five minutes to take a phone call. Plus, you’re recruiting in a field where e-mail is a viable, and sometimes a preferred, medium of communication. If you could, I would suggest using IM or even twitter, but that’s not realistic. If you call someone, follow up with an e-mail. Don’t limit yourself to only using the phone. I realize that there are times when you might need to have a real-time conversation. However, for most of the initial conversations where you’re trying to spark and gauge interest, e-mail is perfectly acceptable and usually preferable.
Use proper grammar/spelling in your initial call/e-mail
I’ve gotten multiple e-mails where random words were capitalized and sentences barely made any sense. Too, I have received voice mails where I could barely gather the point of the message. If you can’t communicate well enough initially to me, I’m not sure I want you representing me to other companies. I already have serious doubts about your understanding of what I’m looking for, so I’m already concerned that any further communication would be a waste of time on both sides.
Don’t misspell my name
Kinda goes along with “do your homework”, but I wanted to break this one out. Want a quick trip to file 13? Spell my name with three “t”s or call me “Persey”. Now, I know full well that I go by my last name (usually only to people I actually know and care about) and it does have a tendency to cause people spelling fits. However, you got my name from somewhere, and if it’s in a computer, chances are it’s right. Worst case, copy and paste. It sounds simple, but I have multiple examples of people missing this.
Either be local, or learn the geography
If I say I live in Acworth, and you present me with a job in Peachtree City, you’ll get that quick trip to file 13 again. Unless the job is paying WAY outside the norm, or the benefits are completely off the chain, that’s going to be a stretch for anyone. You have my address. Map it, and figure out what commute you would be willing to do from that location. Too, you’ve probably got my place of work (if I’m currently employed). Map that, and then use that as a guide. Then, and only then, present me with those opportunities. If you think I’m a really good fit, but it might be a bad commute, ask with that caveat. I’m not going to lie, I give less credence to a recruiter who isn’t from Atlanta. You’ve got to have a great opportunity, and do all of the above before I’ll start thinking about exploring your opportunity.
Don’t use tactics (buzzwords, mystery) to make your opportunity sound interesting
I had one opportunity that was looking for a “computer guru” and wanted someone who was “willing to … learn a new language every day”. In a half joke, I responded saying that I didn’t consider myself a “computer guru” and didn’t think learning a “new language every day” was feasible. I haven’t heard back from them. If I see words like ninja, rockstar, all star, guru, etc. alarm bells start going off. If you can’t spark my interest by using non-pseudotechobabble, there’s something wrong with the opportunity.
Along with this, don’t hold on to the details of the role or the company so that I will talk to you. If you’ve got to sell me on the role by talking to me in person, I don’t think I want it. As far as I’m concerned, mystery is not a selling point. The role and the company should sell themselves. Now, I’m fairly open to most opportunities. However, there are a few places where I know I’m not going to fit in at face value. Sometimes, the company is in a business I’m not going to get passionate about. Sometimes the company is located in a place where the commute would be awful for me. So, what’s the point of having a conversation about it if I know from step one that it’s not going to work out? That’s a waste of both of our times. Too, to my point above, I want to make sure you’re not submitting me to the company I’m currently at or to one I’m already in process with.
Take the hint
If I don’t return your call or your e-mail, I’m not interested. End of story. Let it go.
Too, if I need to reschedule a meeting, or if I decide not to follow an opportunity, you don’t have to try and nose around in my business to find out exactly why. If it’s turning down an opportunity, I’ll usually give you reasons why. If it’s rescheduling, it’s because something more important has come up. Either way, take what I have to say and move on. A few years ago, I interviewed for a “development” position, that turned out to not be that at all. Fortunately (or unfortunately as the case was), the system they had wanted me to use I had some experience with – I actually was a former employee of the company that wrote it. I didn’t really enjoy what I did at that job, and so I didn’t think it would make a lot of sense for me to jump back in. I declined the offer, which apparently set someone off, because I started getting all of these e-mails about “Why?” and “but you can write your own check”. If I’m not going to be happy somewhere, why try to convince me to come work there?
Put yourself in my shoes
As someone who was employed full time and looking for a job, it’s extremely frustrating when you set aside time to talk to a recruiter and they don’t call. Too, please don’t try and schedule something where I’m driving halfway across Atlanta in the middle of the day. Realize that I’m trying to schedule time into an already full professional and personal calendar. So, be flexible and don’t take it personally if I need to reschedule something.
Don’t make me jump through unnecessary hoops
So, this one isn’t so much about recruiters as it is about the companies that are looking to hire good people. If your interview process is six weeks long, and so convoluted you need to spend an hour explaining it to a candidate, you’re going to loose out on good people. The only people that make it through that process are only good at making it through that process. Too, you’re interview process represents your company. This would tell me that your company is deluged in red tape and process, and it takes way too much time to get anything done. I’m all about an appropriate level of process, but there are limits.
One company I interviewed with required a phone interview, an in-person interview and then a four hour, in house, code project test. So, I thought I’d at least give them the benefit of the doubt, and I had the phone interview. It was a very odd interview, and then to cap it off, when I was asked if I had any questions, I went through my usual vetting questions (tell me about your development environment, what’s a project you could see me contributing to, Joel Test, etc.), I was told that the interviewer couldn’t answer questions like that during this interview. Ummm….ok. So, there are questions I can’t ask? Really? Add that to the rest of the time I’d have to take in the interview process and I just called it quits with that opportunity.
Contrast that to the interview process I had at my current company. I walked in one morning, met with a recruiter, a tech lead and a group leader. Somehow, they all came to a consensus while I was between talking to people and I walked out with a good offer. It told me that the people at this company could make decisions quickly and effectively. There was no process for the sake of process – only process as it is needed. I agree that not all quick decisions are the right one, but on average I agree with Patton – “A good solution applied with vigor now is better than a perfect solution applied ten minutes later” and I felt like these guys agreed.
Anyways, for those of you looking – Good Luck! And if you’re interested, we’re hiring! 
To “this.” or not to “this.” – that is the question Tuesday, 09/06/2011
Posted by Percy in Programming, Visual Studio, Work.Tags: Code Style, Programming
1 comment so far
In my profession there are a lot of ways to accomplish specific tasks. Some of the ways to do things are better in a quantifiable way than others. Then, there are certain things which, while they may be drastically different, have no impact on the end result (efficiency, maintainability, readability, etc.).
There are also people in my profession that cling to the way they do things, to the point of ridiculing those who do it differently. Now, while the ridicule part is inappropriate, I don’t have a problem with someone having a different opinion. However, if you can’t prove that whatever idea/process/standard you’re advocating falls into the first category – quantifiable improvement – then what you are pressing is your opinion, and the one I have is just as good as yours. Further, if I can prove that my opinion actually is an improvement in a quantifiable way, then, realistically, mine is better than yours. At that point, it’s not an ego thing, it’s a provable fact. You don’t have to come to my side of things, but you do have to concede that you’re way is deficient in some way. The same thing goes the other way. If you can prove your way is better than mine in a demonstrable way, then usually I’ll concede and adopt you’re ideas as my own.
Developers get very passionate about code style, and, truth be told, I’ve been known to belligerently uphold those opinions of mine. I’d like to think I’ve mellowed in my maturity, but I have my moments. One of those code style conventions is the use of “this” or “base” to access object properties or call methods of the current or parent object. This actually goes along with using the object name in references to static properties or methods. The prevailing and popular thought on this is to not use either one of these conventions. I believe I can show that actually using these conventions can make your code more readable, if only slightly. If there’s an argument against using these that trumps code readability in this manner, I’d certainly enjoy hearing about it. I’ve actually convinced some people who held the popular opinion that it’s actually better to do things differently.
Just so we’re clear, the idea of increasing code readability is the practice of pushing as much information into the actual writing of code as possible so that ancillary information (usually in the form of comments) becomes unnecessary. You try to write your code in such a way as the meaning of the code and the information you’re attempting to convey leaves as few questions as possible. The idea is to be as precise as possible so that when people come behind you (and if you’re code has any chance of surviving past your own dev cycle, people will) they don’t have to infer or assume anything. Now, where there’s a rule, there’s the use of it in moderation. There’s a swing of the pendulum that goes too far when you have method or property names that start to crack four digits in length. I don’t think what I’m proposing goes that far.
So, here’s my proof. Let’s take a simple, yet extremely common, class called Customer, that has over 200 lines of code in it. I think we can all agree that any main entity in an app will probably have more lines of code than this, but this will suffice for the sake of this discussion. The point is that we deal with classes that are larger than our “viewport” more often then not.
Now, let’s say, you’re coming in after someone to fix a problem with their code, and you see this:
Now, the error you’re getting is that there is a null reference exception at line 166. Let’s take a step further, and say that the “Code before” and “Code After” constitute enough code that you don’t even have the method prototype on the screen (I think the argument works without this, but let’s take it to the extreme). Ok, what’s the scope of “Reference” in this context? Is it static or local? Is it a property of Customer, or is it part of a completely different object called Reference? Where is this property defined? Is it in this method, the Customer class, some base class or in a completely separate class? Should you be checking the constructor to see if it’s set (local scope) or some other entity’s process (static scope)? Now, you can use all kind of IDE features to find out that information, but you have no idea just by looking at the code. There are some questions that you can’t answer by simply reading the code – i.e, the readability of this code is diminished.
Now, what if you saw this, instead -
Then, I could answer those questions simply by reading the code. Reference is a local variable for the object Customer. It’s defined somewhere in the Customer class (given that with partial classes, that might be across multiple files). The same holds true for using “base”, except that you know the property is defined in another class. In this case, the readability of the code is increased over the previous example.
Or, what if you saw this -
Again, you could answer the questions. Reference is a static property of the object Customer. It’s defined somewhere in the Customer class. And, again, the readability of the code is increased over the first example.
Yes, I know you can just hold control, and click on “Reference” to go to it’s definition, or right click and “Go To Definition”. I’m not saying you can’t answer the questions I posed at all without using “this”, “base” or the object for static properties. All I’m saying is that it’s easier to answer those questions if you do use them. So, to me, that makes the code more readable. In my opinion, better code readability is worth the extra few keystrokes you have to use to add this feature in the long run – especially in the Intellisense age of development.
I know that some people can be passionate about these kinds of things. I like using this convention, and I think it makes my code better in a way that I can quantify. So, I’m going to use this every chance I get until someone convinces me otherwise. If you disagree, so be it. I’m not going to hold that against you. Even if I see your code not using it, I won’t change it unless I really need to. The only time I might question you a bit farther on it is if you’re entire rationale is based on “because MS/ReSharper/Visual Studio/my boss/[insert other authority figure here] says so.” Why do they say so? I think that even if some authority on a subject makes a statement, they need to back it up with something or we need to find out the reason behind it – it may be a good one or not. “Trust, but verify”.
So, what do you think? Agree/disagree? If you disagree, why?
