Job Req. Sanity Check

Let me start by saying I am not an HR guy. Nor have I ever been a full-time recruiter of any sort. So perhaps, I’m way off base with my thoughts on this topic. PLEASE straighten me out if I am because there are a lot of practices within this space that make no sense to me.

I.  The Skill Set Years Experience Mismatch

Lately I have seen a flood of open position postings on the various job boards that will say something to the effect of “Jr. Developer\Recent College Grad\1-2 Years experience” as the headline of the posting. Only to find in the requirements section, experience (which to me means more than just exposure or reading a help doc online) for some 30 different technologies. Maybe, yes maybe with the right set of circumstances a Jr. resource as described in the headline might have started in an environment where he or she was given free rein to provide solutions through whatever means. I was lucky enough to have started my career as the only software developer for a successful Insurance company where I was able to explore whatever new technology came along and experiment with different techniques. I think this is pretty rare. Some companies spend the first 6 months breathing over a new resources shoulder with weekly code reviews before they’re promoted to level on and the code reviews come when the developer is ready. Many companies only let their resources sustain existing code and teach them just the basics to troubleshoot the existing technologies while the more senior staff works on innovation.

So are the hiring managers or recruiters looking for 80% of the required skills? One or two? Software design and development professionals are detail oriented and precise personalities. If I can’t talk about every skill listed, I’m not going to apply for a position.

II.   Competing Technologies

Another favorite of mine is when the laundry list of experience includes market competitors. The posting is looking for someone with 5 years experience and expert knowledge of Oracle, DB2 and SQL Server, or Expert level .NET and Java. First, can you really become expert in 5 years, especially if the maybe 2 of those you were just doing maintenance work (i.e. spell checking websites)? Secondly how many companies invest tens of thousands of dollars in SQL Server and more tens of thousands on Oracle? As a vendor software developer your product may need to support more than one database platform. However, what percentage of the candidates the job market hail from vendor software companies? Are there really any transferrable skills between .NET and Java? It seems to me trying to grow one resource into an expert of both is far more expense than cultivating two specialists and most companies would do the latter.

These types or requirements lead to a lot of confusion for candidates. They don’t know if they should bother applying or not. The recruiters are inundated with resumes that don’t fit the request from the hiring customer.

III.   Automated Recruitment Phone Recruiting

This year in particular I have been flooded with outsourced call center recruiter calls. These calls always follow the same format.

  • I answer the phone to silence
  • A few seconds later someone in a very thick accent says, “Hello may I speak to George?”
  • “Yes this is George.”
  • Faster than any normal human being should be able to speak -“Uh hi. My name is gibberish. gibberish gibberish gibberish gibberish gibberish gibberish gibberish gibberish gibberish gibberish gibberish gibberish …”
  • Me, “Whatever you’re talking about I’m not interested. Thanks.”
  • Hang up.

It’s as bad as the campaign calls around supper time during an election cycle. Who in their right mind thinks this is in any way an effective means to find a qualified candidate? I seriously doubt these individuals understand the technical requirements well enough to successfully phone screen much less are able to fight through the language barrier well enough to have a real conversation about the candidate or the opportunity.

IV.   Don’t Read the Resume

Another new interesting fishing tactic is the mail blast, or I guess that’s what’s going on. Why else am I getting emails for Jr. or Intermediate 5 years or less positions from the job boards where my resume clearly showing 16 years of experience are posted? Or the expert Java Architect roles I was sent when Java J2EE doesn’t appear anywhere on my resume? Recruiters, does this tactic work?

I understand there is a perception in the US job market right now that a lot of people are out of work and some companies are hoping to cash in on getting better qualified candidates for less compensation. This perception has created a recruiter feeding frenzy atmosphere. The truth is most of the top ranked talent is aware of what’s going on and they’re sitting this cycle out, or contracting. The unemployment rate among software development professionals is not nearly as high as other skill sets like manufacturing and construction. I believe this tactics will not be successful, and my land your corporation with a lot of negative feedback on a site like GlassDoor.com.

GUID’s – Never for Clustered Indexes

Globally Unique Identifiers have their place in software development. They’re great for identifying a library in the GAC or windows registry. They are, however, huge data types from the database perspective.

Oracle, MYSQL, Sybase, and DB2 do not provide any special data type for fields storing GUID’s, for these vendors a GUID is a 34-38 character string (depending on including dashes and “{}”). SQL Server has provided a Unique Identifier data type which has some benefits in storage and access speeds over a 36 character varchar, or nvarchar field. However, they’re still huge…

Unique Identifier Data Type

http://msdn.microsoft.com/en-us/library/ms190215(v=sql.105).aspx

SQL Server’s Unique Identifier displays as a 36 character string (dashes and no “{}”) and stores a GUID as 16 byte binary value. There’s no argument that it’s nearly impossible (not mathematically impossible) to create a duplicate GUID, but how many data sources are going to outgrow a bigint (-2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807)) data type? That’s only 8 bytes, half a Unique Identifier. Hard disk space has gotten cheap, why do we care about data type size anyway?  In the article mentioned above, it’s mentioned that indexes created on Unique Identifier fields are going to perform slower than indexes built on integer fields. That statement hardly scratches the surface of performance implications with Unique Identifier indexes, and it’s all related to the size.

Pages and Extents

http://msdn.microsoft.com/en-us/library/ms190969(SQL.105).aspx

The above article explains how SQL stores data and indexes in 8KB pages. 96 bytes are reserved for the page header, there’s a 36 byte row offset and then 8,060 bytes remain for the data or index storage. If your table consisted of just one column, a page could store 503 GUID’s,  or  1007 BigInt’s, or 2015 int’s. Put another way, the smaller the amount of bytes in a row, the more you can store in one page. SQL Server doesn’t control where the Pages are written on the hard disk, the O/S and hardware decide. The chances of consecutive or sequential pages being stored in distant disk sectors increases with the more pages stored for each table or index in the system. As the number of index pages grows, the more out of sync they become with the data pages leading to index fragmentation.

Index Fragmentation

http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-1-the-basics/

http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-2-size-matters/

Let’s recap what we have so far,

  1. GUID’s are randomly generated values without any sequential nature or restrictions.
  2. GUID’s are twice as big as the biggest integer data types.
  3. The larger a tables rows are the more pages have to be created to store the data.
  4. The more pages an index has, the more fragmented they get.
  5. The more fragmented the indexes get the more frequently they have to be rebuilt.

Clustered Index Implications

Clustered indexes set the organization and sorting of the actual data in the table. Non-clustered indexes created on a table with a clustered index have to be updated with pointer changes as records are inserted or deleted, or the clustered index value updated because these changes require the data pages to be resorted and new keys generated. SQL Server Identity columns of an integer data type reduce a lot of I/O overhead and SQL server processing because the rows are always inserted in the correct order. GUID values are almost never inserted in the correct order because of their random nature. Thus, with a GUID clustered index every insert or delete or update of that field requires data page reorganization, non-clustered index updates, more pages to be created, and increased fragmentation.