On Technical Recruiter Spam

I haven't updated my linkedin or dice.com profiles in about a year.  I figured by not updating those profiles that it would slow down the constant onslaught of recruiters phoning and emailing me about web developer positions.  It hasn't worked so far.  I really appreciate someone giving me the opportunity to apply to interesting jobs but the recruiting industry is just broken and full of lazy people who can't be bothered to do anything other than a simple keyword search.  I have a lot of experience so I'm going to show up in a lot of keyword searches but that doesn't mean those jobs are applicable to me or that I would be interested in them.

So if you're going to contact me anyway, you might as well try not to annoy me.  Here are some ways dear recruiter of not annoying me:

1.) If my profile lists that I'm not willing to relocate then don't send me a job clear across the state.  Or the country.   Or the world.   These would require relocation.  While I realize that New Jersey is one of the smaller states in the union, it is still 166 miles north to south and 57 miles wide.  Since I live towards one end of it as referenced by my address, it makes little sense to assume I can commute to the other end.  That's over a 100 mile commute.  A quick google map search could give you that.  

2.) If the job entails working WITH a "guru," "ninja," or "rock star" then I am not interested.  A real guru is much too enlightened to ever refer to themselves as a guru, nor would they allow another to refer to them as such.  So when I see "guru" as my potential boss/coworker, I read "asshole."  A ninja would have altered the job ad before it went live so as to preserve his identity.  And rock stars aren't developers.  They are girls named Kim that play bass guitar.

3.) If the position entails that I NEED to be a "guru," "ninja," or "rock star" then I am not interested. Please see above.

4.) If my profile lists I'm looking for full time work, then don't send me jobs that aren't full time.  I really don't get this one.  And I don't have anything funny to add to it either.  It's really just sad that people don't pay attention to this.

5.) If the position requires being an expert in some technology that I don't have as my primary skill set, then don't bother contacting me because I probably couldn't even do the job.  

6.) Stop asking for "excellent communication skills."  If I had those, I wouldn't be a developer, I would be a salesman.  Or Steve Jobs.  I can communicate well enough to get the point across the first time.  Is that excellence?  Perhaps to you it is, but you also think the world is full of gurus and ninjas so I can't really take your assessment at face value.

7.) If the position does not require me to write code to get a job offer then I'm not interested.  Because that means your other developers didn't need to write code to get their jobs there and probably two-thirds of those developers are terrible.  I don't want to work with terrible people.  The better job you do at weeding out the crappy developers, the more I will think of your organization.

8.) If the position is for a company whose name you cannot divulge until we've had several conversations then I'm not interested.  I understand not putting the name in the job ad online,  that's pretty standard these days, but if you're contacting me directly then you should give me the name of the company.  Otherwise it implies a lack of trust on my part, like I'm going to steal this commission from you somehow.  So, first, you're making contact with a stale account since I haven't updated my profile in a year.  So you're assuming I'm looking for job when I'm probably not.  And then to try and entice me into the job market, you neglect to give me the company name so I can do research on it?  That's pretty lame.

I could go on and on here, but what about you?  What are your suggestions for technical recruiters?

How to find all the distinct PHP session variables that your applications uses.

The short answer is a one line *nix shell command:

grep -hor "\$_SESSION\['[A-Za-z0-9_]*'\]" * | sort -u

This command: 

• looks through all the files in your application recursively for the PHP $_SESSION reference
• finds any variables named with capital letters, or lowercase letters, or underscores, or numbers
• sorts the list alphabetically 
• removes the duplicate items in the list

The long answer is that I found myself with an interesting dilemma recently.  How to find all the PHP session variables set in my application.  Some pieces of the application were new code, some were older legacy code.  I needed to get the full list of session variables because I needed to delete most, but not all of them for a certain usage case ( ie, the user is still logged in and has some properties, but the other session data could be safely destroyed ).

So I began with some command line greps on linux.  First I tried:

grep -r \$_SESSION *

This was  a decent list, but about 1000 rows long.  Too unwieldy to deal with.  Let's get rid of the filenames, I don't really care where the session values are set for my case.

grep -hr \$_SESSION *

This is a little better, but I don't need the whole line, just the session variable itself.  Let's see if we can start to grab the session var using a regex pattern.

grep -hor "\$_SESSION\[" *

That's getting us closer.  Now, I know ( or assume ) that my variables will only include upper/lower case letters as well as numbers and underscore.  Let's add those to the pattern.  ( you DO speak regex don't you? )

grep -hor "\$_SESSION\['[A-Za-z0-9_]*'\]" * 

Now we are cooking.  This is a nice list of the session variables ( albeit only one array level deep which is all I needed ).  Now how to remove the duplicates?  Maybe we should "sort" them first?

grep -hor "\$_SESSION\['[A-Za-z0-9_]*'\]" * | sort 

That is really close.  Is there a way to remove duplicates with the "sort" command?  Yes, there is.  Hot dog.

grep -hor "\$_SESSION\['[A-Za-z0-9_]*'\]" * | sort -u

There it is.  That's the final command I used which located around 50 variables in the old legacy code and new modular code that were used in the sessions.  The only really drawback to this code is it will not find multiple nested array values on the session itself, but you could add that as a separate regex if you need.