How to engage with recruiters

recruiter photo

Photo by JimsFlicker

If you are a software engineer or developer right now, you are in demand.  There’s a dearth of software developers, and so you are probably getting calls from recruiters.  This is location dependent–my understanding is that the SF market is white hot, and the market for software developers in Yuma CO is softer.

When I first was approached by a recruiter, I was flattered.  Here was a stranger trying to find me a job.  Quickly I realized that recruiters were not working for me (they get paid to place a candidate, so they are working for the company) and that most recruiters didn’t have a technical background at all.  This made me feel less charitable toward recruiters, and I have found that common amongst developers, especially now that they have so many job options.

Older and wiser, now I have a more balanced approach.  Here’s my tips for dealing with tech recruiters:

  • Communicate what I want.  This means knowing what I want in a new job or contract, which can include availability (both hours and start date), minimum rate, location, work condition (remote), technology, sector.  Tell the recruiter all this up front.  I often state: “hey, at this point in time, I’m rather picky, and I don’t want to waste your time.  Here is what would interest me: …”.  This lets them self select out quickly, before the “get to know you” phone call.  I should probably put this on my Hire Me page, now that I think about it.  Just need to make sure I keep this up to date.
  • Realize I am in in their database forever.  I gave my resume to someone in 2004 who I lived with who worked at a recruiting firm.  I still get calls from that same firm.
  • Make sure I am treated like a professional, and don’t put up with non professional acts.  Do they respond when I ask them to, answer my questions, and treat me with respect.  I actually had to hang up on a recruiter recently who, after I had told her I was busy and couldn’t talk right then, in an email and earlier on the call, continued to ask “just a few questions” about my skill set.  It wasn’t fun, but she was not being respectful of my time.
  • The other side of the coin is that I need to treat them with equal respect. That means being honest with them about needs and skills and responding to emails in a timely, respectful fashion.  It also means if I hear of someone with a needed skillset, doing an intro (wearing my informal recruiter hat).
  • Make the exchange of information a two way street.  Whenever I get contacted by a recruiter, they always want “5-10 minutes to talk to see how I can help you in your career”.  When I get them on the phone, I make sure to ask them questions about the market, other skills they’ve seen in demand, what specific technologies they’ve seen needs for, what kind of companies are hiring.
  • Thank them for supporting various meetups, if they do.  The local Java Users’ Group has pizza and soda provided every month by a recruiting firm.  This actually makes me more likely to respond to recruiters from that firm, because, while it’s not caviar, it’s nice to have dinner paid for.
  • Realize the difference between being sought for who I am (that’s being headhunted, and is reserved for senior folks and niches) and being sought for my skills.  I’ve never been in the position of having a stranger seeking me for who I am (I imagine internet famous folks like Matt Raible probably have), but I have had former co-workers do so.  Incidentally, the former is by far a better way to join an organization.
  • I keep my linked in profile up to date.  This makes it very easy to send recruiters a resume, should they ask for one.
  • I realize the tables may turn.  Right now, and for the near future, development is in great demand.  But I’ve been through one ‘software recession’ and I expect there will be more.  Beyond the basic dignity I ascribe to every human being, recruiters can get me a job.  So, except in the cases where recruiters aren’t respectful, I treat them with respect.
  • I don’t take random recruiter calls or requests on LinkedIn.  LinkedIn emails are different–if a recruiter has paid for a premium account, it’s easy enough to respond with a quick ‘not interested’ if the position isn’t for me.  But if a recruiter is trying to connect on LinkedIn without having met me at all, they are not serious.  If a recruiter is serious about getting in touch with me, I can be found in about a thousand different ways online.  I think recruiters who send LinkedIn requests are lazy and not worth responding to.
  • As above, I respond to recruiter emails, even if is just ‘no thanks’.  Again, basic human dignity.
  • Finally, I’m trying to cultivate a few good recruiters.  Whether these are referrals from a friend, or recruiters that I’ve met at an event, there are a few that stand out.  One recruiter (Dave from Technical Integrity) actually introduced me to a few of his friends so I could ask some exploratory questions about a different sector.  You better believe that I’ll recommend him and think of him when I have friends who are looking for work.  That company focuses on startups and full time employees, so I haven’t had the experience of working for them, but when my needs change, I will certainly see if they are looking.  The idea is to have the relationship last longer than a single contract.

Reviewing my list, I boil it down to:

  • recruiters are human beings, treat them like it
  • they don’t work for you
  • set your expectations and boundaries
  • software development is hot now, but won’t be forever

Any tips you have on engaging with recruiters?


Mis en place

Professional chefs have a concept termed ‘mis en place’.  While I know very few professional chefs, the idea appeals to me.  It basically means ‘keep your workplace in order, before you start doing anything important’.  (Of course, you can read about ‘mis en place’ more on Wikipedia.)

I find that this is very true of software development as well.  If you don’t have your workplace in order, you will suffer.  Now, the definition of ‘workplace’ varies–someone building a webapp has a different work environment than someone building software that will run on ASIC chips.  I’ll speak to my workplace, but I challenge you to review your workplace and see what, if anything, is out of sorts.

I’m going to break this up into three different segments.  First is the physical, then organizational, then the coding environment.

First off, the physical workspace.  This includes your desk, your monitor and computer setup, your work environment (headphones, bull pen), and your view.  It also includes your body–how you are sitting, how often you move around.  My current physical workspace is a desk with perhaps a bit too much clutter on it, a desktop machine (I know! they still sell them, apparently.  And you can get a lot of machine for not much money), and a view outside.  My work environment, since I’m working from home, is alternately morgue like and circus like, depending on who comes down to the basement.

Then there’s the organizational component.  Since I’m now contracting, this is something I have less control over, but it is important to organize your working environment in terms of the organization as much as you can.  Are you working on the right things?  Are the right people on the team?  Are they spending the right amount of time on the project?  In business speak, is everything aligned?  If the answer is no, how can you fix this?

Finally, there’s the actual hands on coding environment.  This can include everything from having a continuous deployment environment to your shell aliases to your software stack to your IDE (if you lean that way).  This is what I originally thought this post was going to be about, because this aspect of the workplace is where the rubber meets the road, so to speak.

Problems with any of these can cause a project to fail.  So make sure your work environment as clean, ordered, and ready to go as possible before you start a new project, or if you are in the middle of one, take some time to clean things up as you go.  You’ll be happier and more productive.



The Tragedy of Mobile Development

unicorn photo

Photo by Origamiancy

The web, for all its warts, pushed a major advance in software construction.  The separation of concerns.  This is the idea that, just as you wouldn’t have the same person paint a house as lay the foundation, you should have different people design the user interface and the internal guts of software applications.  The skillsets are simply different.

Since modern web applications exist in the browser and are primarily CSS and HTML, with some amount of javascript, it is fairly easy to split up development between designers and developers.  Designers could focus on beautiful, functional user interfaces and developers could focus on making the application work.  HTML and CSS were the common interface, and they weren’t complicated (neither is a full featured programming language).

This separation is more difficult to maintain since the rise of the single page application, which pushes a lot of logic and functionality into the browser with javascript, but is still possible.

But, the mobile device, with its native apps, is a huge step backwards.  Sure, there’s still plenty of scope for people who just want to make things work–APIs and server side logic are a large part of most mobile services.

But for the client side, it’s not enough for designers and UX folks to be fluent in the traditional tools.  They can still do mockups, but the UI for mobile devices is constructed in code (objective C or android java, primarily).  That means that the finer points of UI must be added by developers.  No longer can they be delivered by HTML and CSS.

And hence, the rise of the proverbial unicorn, who can do mobile development, design and UX.  And makes very good money, since there are very few of these.

Is this sour grapes?  Nope.  I know that one of my limitations is my aesthetic sense.  (If I harbored any illusions about this, my wife would be quick to disabuse me.)  And I think that the unicorns should ride this market for all it is worth.  It just frustrates me that we came so far with web applications and separate of concerns and now are taking a huge step back.



Denver Bootstrappers Lunch

boots photo

Photo by liftarn

My friend and former colleague Corey Snipes has been working to get a Bootstrapper’s meetup off the ground in Denver. This is a small group (limited to 12, I believe) of people who are building products (typically software) and self funding. I believe most of the members are in the solopreneur mode (I know Corey is).

I imagine this kind of support group would be fantastic–certainly I had a similar group when I was a consultant in the past, and bouncing ideas off of others in similar situations made the struggle much easier.

I’ve not made this meetup yet because, a) I’m not sure I’m bootstrapping (and you know what, if you aren’t sure you’re bootstrapping, you aren’t bootstrapping!), b) I live in Boulder and Boulderites have a hard time leaving the Boulder Bubble, and c) Wednesdays in general are tough days for me to do anything outside of the house.

If you are a bootstrapper in the Denver area, take a look.


A Useful, Tested Git Work Flow

knot photo

Photo by fdecomite

I’m working on a project with a number of developers (about 9 checking in code) that is moving rather fast and we’re using git and github. It’s actually really interesting to me, because most of my experience has been with smaller teams (and centralized VCS) where having everything on HEAD is perfectly fine. I was even able to branch using CVS because the chance of merge conflicts with no one else doing development was small.

I remember having lunch with a friend who worked at Rally and we talked about git. He said that they were heavy users, and “once you use it, dude, you’ll never go back”. At the time I thought–how great can git be? I’d been using it for a small project I was coding by myself, and it seemed nice enough, but not revolutionary.

But, now that I’m using it in a fast moving team with a large number of developers touching lots of parts of the system, the branching and merging capabilities of git are starting to shine. The project lead, who has used git before, recommended the Driessen git flow (from 2010), which is more complex than the github flow.

We’ve been using this for a few weeks and I’ve found it be clear, fairly easy to understand and still flexible enough to let development move forward at a breakneck pace. The supporting branches, along with master (always what is in production) and develop (always works, what is coming down the pike in terms of features), seem to be a nice compromise between the strictures of traditional, centralized VCS and the free-for-all that is possible with git.


Settle the Routine, Focus on the Important

IMG_20141016_165308295

My Bike Lock

This is a picture of my bike lock.

There are many bike locks, but this one is mine.

I always put my bike lock on as seen.  My helmet with the lock running through the styrofoam (because, on the off chance someone wants to steal a bike helmet, they’d have to destroy mine to get it).  The lock running through both the front wheel and the frame, so that the wheel can’t be stolen–nothing sadder than a locked bike with a missing front wheel–quick release works well.  The actual lock (where I put my key) sheltered from the elements, both because the helmet protects it and because it is facing down.

After commuting on my bicycle hundreds of times and leaving it overnight a handful of times, I’ve determined this is the optimal lock procedure.  Not that I’m not open to new ideas–a few years ago I took my helmet with me, but then I saw someone lock their helmet like this and thought “what a wonderful idea!”.  But once I arrived at what seemed an optimal solution, I just put it on autopilot.  This frees up my mind to pursue other things.  It also means I have not analyzed the way I lock my bike in a deep way until I started to write this blog post, and once this is done, I won’t think about it for the foreseeable future.  The bike lock setup is settled.  I’m always looking for other aspects of my life to settle, while still being open to possible improvements (if you lock your bike differently, let me know!).

There’s a similar tension in software development.  On the one hand, I want to be open to new ideas, frameworks, concepts and solutions.  On the other hand, it can be easy to go after the newest ‘shiny thing’ every time, spin my wheels, and not accomplish what I need to accomplish.  One way to the latter issue is to make some decisions in my work life.  This can range from the trivial–I have used the same aliases file for over a decade–to foundational–I only work on the unix stack.

Sometimes settling constraints are imposed by the project–it’s a RoR app that needs to be upgraded, or there are already extensive java libraries that this application will use (and that can mean that you won’t get the gig or the job).  Time also can be a limiting factor–deadlines have a wonderful way of focusing you to work on the problem at hand, rather than running off to explore that new library.  It’s also important to realize that you can settle the trivial–what shell you work in, what OS you use, how you lock your bike–which lets you focus on the important–the app you are writing, the restaurant you biked to.

(Of course, what is trivial for some projects may be foundational for others.)

When you are working on a side project, sometimes settling on a technology can be hard–it is more exciting to explore that new XYZ rather than grind away at a bug or a new feature in an app that I’ve already written.  But, in the end, extending and shipping an existing app almost always is more rewarding.

We software developers live on a knife edge–on one side is irrelevance, though it may be profitable (COBOL), on the other side is flitting from new technology to new technology (whether it is Erlang, Haskell, NodeJS or something new) but never mastering them.


Fun stuff I’ve done

amusement park photo

Photo by Loozrboy

One of the companies I’ve met with wanted a bit more context around work I’ve done, so I wrote up some of the ‘greatest hits’ of tech work I’ve done in the past couple of years. It was so much fun, I thought I’d post it here so I’ll remember it in a few years.  This is just some of the tech highlights, and doesn’t include other things I’ve learned (managing folks, softer development skills, etc).

  • Colorado CSAs.info is a directory of Colorado CSAs. This site received 28k visits in 2013, and 26k visits so far in 2014. You can view the source. The source has some quick and dirty aspects, since this is a side project.
  • Home valuation processing software output. This was a fairly simple algorithm (linear regression among geographic datasets) but involved some interesting processing because of the number of records involved (1M+) and data sources. The graph shown here was generated by code I wrote. The content is human generated, however. I worked directly with the CEO on requirements for this v1 project.
  • I wrote an ebook about an aspect of mobile app development last year:
  • I built large chunks of COhomefinder (which has not been touched in 2 years, because the business has decided to move forward with an outsourced home search solution). The last code I touched was replacing google maps with mapquest. I also built a widget for featured home listings that could be dropped into other websites. You can see both on the search results page.
  • I wrote a hybrid mobile app that displays news and info about neighborhoods in the front range. This never really got much traction, unfortunately.

It’s fun to look back.


Parents In Tech Interview

baby photo

Photo by paparutzi

A few months ago I was contacted by Morgan who read a comment I’d made on Hacker News about reshuffling my work life balance.  He was starting a site for parents who work in technology, and was looking to interview such people for tips on parenting.  After a flurry of emails, we finally found a time that worked for both of us and were able to skype for an half hour.

My interview is up here.  Morgan doesn’t do a ton of editing, so it is a little rough, but you get a sense of my thought process:

M: Has having a Baby changed your worldview, beliefs, or how you treat other people? How so?

 

D: Sometimes I wonder how my parents can take me seriously, given that they saw me as an infant. You put it nicely, getting some empathy, starting out as something that just cries, poops and sleeps.

Full post here.

If you are a parent who works in technology and want to chat with Morgan, let me know and I’ll do an intro.



© Moore Consulting, 2003-2017 +