Tagged: hiring
How Ben Accidentally Became a Developer
In early April I received a message from Ben, delivered to my Reddit account.
I’ve been reading /r/resumes for, well, the whole time I’ve been actively looking for another job. I’ve noticed your comments on other posts and respect your opinion. Even though I’m not a “programmer” per se, I do enjoy reading your site and appreciate the time you take to help folks like me who are trying to make the best impression possible.
Ben wanted some advice on his résumé and career prospects in technology, and he wrote a quick bio. He earned a degree in religion and worked in that field for seven years before deciding that his passion was for technology. During his tenure in the church he dabbled in web development and learned to solve basic networking and hardware issues to reduce the church’s technology expenses. He resigned his church position to pursue entry-level roles, and ended up spending a year in retail before eventually being hired as a Junior Computer Technician.
After spending three years in the technician role, Ben asked his manager for additional responsibilities. He was already performing light systems administration tasks for their small office, and was then entrusted to write a web application. Ben taught himself PHP, JavaScript, and SQL. The web app he built became a major revenue source for his company and a highlight of his career.
Ben, on paper
After learning about Ben’s work history, I reviewed his résumé. The two sentence profile atop his résumé mentioned troubleshooting, managing hardware and software, vendor selection and training. There was no mention of programming experience.
Below the profile was a listing for certifications. None of his certs were truly relevant to programming.
His experience section was next. The first role listed was Systems Administrator, which had descriptions of his accomplishments in that role.
I was now halfway down the page and I have seen nothing about what he saw as his most valuable professional accomplishment. And then there it was – Web Developer. He had duties in both sys admin and development, and chose to list the sys admin experience first.
His technical skills section led with several operating systems, servers, and virtualization tools. Below that, a mere two lines from the bottom of the résumé (just above his degree), he listed programming languages.
“…not a programmer, per se…”?
After I finished reading the résumé, I thought back to his comment from the original Reddit comment. “Even though I’m not a ‘programmer’ per se…” At this point it was hard to tell if Ben would be more marketable (or happier) as a sys admin or a developer, so more information was required.
Ben then sent me a random email to tell me about his blog, which he had recently converted from WordPress to Octopress and had subsequently picked up some Ruby along the way. I checked it out and saw he had a couple small GitHub repos. This was all news to me. I asked if he had any other programming experience he was hiding.
It turns out he had done some freelance front-end web development work for a bit. He added that he had also contributed to the development of a template that was adopted by WordPress as a stock theme.
Ben might not have considered himself a programmer, but I expected others would disagree.
The Intervention
I sent Ben an email suggesting he focus 100% of job search efforts on finding a development role, and that his experience should qualify him for intermediate level slots. Ben responded that he had been reluctant to seek programming positions because he’d been doing that work for the least amount of time, but acknowledged that he’d probably be happier (and better compensated) as a developer. We worked together over the course of a couple days to rewrite his résumé, which emphasized his coding accomplishments.
Results
Within five days of our first contact, Ben had a couple interviews lined up for web development positions. Fifteen days later Ben accepted a new job offer as a developer, which came with a 60% increase from his prior salary.
Ben now describes himself as a “Full-stack web developer” on his blog.
Why Hire Older Engineers
Another day, another article about age and technology. The comments of these articles usually escalate into some generational war played out with mythology and anecdotes regarding relative energy levels and productivity, work hours, the value of experience, and general competence. These discussions usually make no progress, while some useful topics are ignored.
As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. When doing business with clients, I find myself advocating on behalf of older coders regularly. During the first dot com boom multiple six-figure job offers were dealt to anyone at any age who could spell J-A-V-A, but the landscape is much different now.
Most companies I’ve worked with give candidates of all ages a fair shake, although I’ve witnessed some who have been less friendly to industry veterans. For firms that need additional justification for hiring older workers, here are a few additional considerations that may go beyond the more common topics of discussion.
Recruiting – So your efforts to scale your team came to a screeching halt? Inevitably the friends and family network dries up and firms rely on internal recruiters or outside agencies to identify talent. Although young hires may be more connected due to early adoption of social networks, older workers usually come with established professional networks. These contacts are not just other senior engineers, but will also include younger former co-workers. When you consider the costs of recruiting (not to mention the costs of a bad hire), the ability to tap into the network of highly experienced engineers might even justify paying a higher salary.
Beyond just the network a senior engineer may possess, having experienced talent on staff will appeal to young candidates who understand the value of learning and career development. A predominance of junior engineers will typically scare off older applicants, and it’s also likely to be a red flag for some subset of the young. Graduates are typically encouraged to find a career mentor, and they will seek experienced professionals to serve in that capacity.
I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires. The term I usually use is “hire magnets“, and those magnets may fit a few different profiles. The magnet could be a recognized authority on a topic, an involved tech community leader, or simply a knowledgeable and charismatic developer who enjoys sharing knowledge.
Fad recognition – Industry experience may give engineers a sharpened ability to sniff out the difference between a passing fad and the genuine article when considering new technologies. This of course isn’t by rule, but once an engineer has seen enough shiny things being hyped by marketers and evangelists it should theoretically become easier to evaluate trends with less bias. Hires with this skill may save a company time, money, and many developer hours.
Less performance unknowns – Older engineers with a documented work history, a list of credible references, and demonstrable work experience should be easier to vet than juniors coming from their first or second job. The ability to rely on past performance to predict the future is a benefit, though never perfect.
Retention/stability – Employee retention is a serious concern and cost for many firms, with demand for talent contributing to turnover. Older engineers and those with families should be less likely to consider relocation for new positions, which limits their other employment options to local or regional opportunities. Although both junior and senior level engineers may have bills to pay, the breadwinner concept changes perspective and may result in satisfied and fairly-compensated developers staying put.
Senior level developers often reach a point where compensation plateaus and money ceases to be an incentive to change jobs. Employees less driven by dollars are surely driven by something. It could be something as simple as proximity to their home or a desire to solve complex technical problems, but competitors are less apt to change these factors and often need to compete with pay.
From my experience, most engineers see fewer significant increases related to job change around their 15th year in the business, and by the time someone reaches that level of seniority it isn’t unusual to have once taken a pay cut. Junior level talent in competitive markets view job change as the most reliable means to salary increases, while the relatively minor compensation differential for senior engineers may not outweigh the uncertainty of a new employer.
Unique situations – There are some scenarios that happen in development shops that are nearly impossible to replicate in a classroom or lab setting, and the ability to face the unexpected comes from being there. This could refer to crisis management when a server goes down, handling difficult customers, or knowing how to navigate office politics. Prior exposure does not guarantee preparedness, but should make the second experience less shocking.
On-the-job learning – Older engineers may now be on their second or third set of platforms and corresponding tools. Developing the ability to learn new languages and tools in a work environment is a skill. It is quite valuable to know how much (or how little) to read before starting a project with an unfamiliar component, or which methods are most effective for you when seeking knowledge.
Any that I missed?
Would You Hire the CS Class of ’04 Today?
A comment in a Reddit computer science career advice forum got me thinking. There was mention about the high volume of advice in the forum coming from inexperienced people relative to advice from industry veterans. The comment that got my attention (which I believe was made by an experienced person) was:
And most of the people giving advice in this sub¹ are 10+ year veterans who, if they had only the skills they had when they first got hired 10 years ago, could never get hired in today’s market.
So could the college class of ’04 couldn’t get hired in today’s tech talent market? That’s an interesting topic for debate, and your age likely influences which side you choose.² Of course, ‘skills‘ could be interpreted as overall engineering chops (concepts that are language/tool agnostic), or ‘skills’ could refer to ’04 grads having dated skills for today’s market. I sense the commenter intended the former, as the latter doesn’t seem worth mentioning. Either way, my opinion is the same.
For most cases, my answer on whether they could get hired today is ‘Probably not’.
This is not to say that the class of ’04 or even 1994 were lesser engineers upon graduation, and those critical of our increased reliance on tools will make arguments to the contrary. The résumé of the typical ’04 grad would have difficulty getting interviews when pitted against today’s graduates, based on ’14 trends for entry-level candidates. Entering the work force with some level of perceived accomplishment (via internships or personal projects) is becoming a rather reasonable expectation even among average tech employers, to the point where graduates that lack experience or tangible evidence of their ability openly lament their (mostly irrational) fear of being unemployable.³
If we look at the difference between these graduates of ten years apart, we discover how quickly both available resources and industry expectations have changed. How would ’04 grads fare against today’s candidates? It’s interesting to explore how different things were.
How did they learn to code? How much ‘experience’ do they have?
It sounds kind of odd to me, but someone as young as 35 might not have seen a decent web browser until college. The class of ’04 hit puberty when Windows 95 was released, were likely to reference books/manuals (BBS/Usenet perhaps), had limited access to like-minded individuals, and coded on machines dwarfed in power and memory thousands of times over by today’s mobile phone.
The class of ’14 had fully functional browsers and search capability by middle school, and relatively cheap computing power. It would have required unique circumstances for those in the ’04 class to enter college with coding experience, but many in the class of ’14 could have had exposure at a younger age. When I ask recent grads when they started coding, it’s common to hear “in high school”.
What did they do when stumped?
Volumes of reference material and educational content were available to the ’14 grads that were not in ’04. Stack Overflow has become the programmer’s best friend, and that best friend still celebrates birthdays at Chuck E. Cheese – it is barely five years old. ’14 grads could access answers much quicker than those from ‘o4, but many would argue whether that access over time makes for better engineers.
The class of ’04 grew up with search engines too, but how much relevant content was there to search? And how difficult would it be to actually find that content given the search engines of the time? The need for trial and error is dying, and it’s reasonable to assume that death hastened between these two graduating classes.
How did they differentiate their ability from others when competing for jobs?
You’ve got a pretty solid GitHub, eh? ’14 graduates could browse and contribute to thousands of open source repos and create their own all through college. GitHub obviously wasn’t the first destination for repos, but hiring managers didn’t usually ask to “see your SourceForge” in ’04. The ease and expectation of showing past code to hiring entities is a relatively new concept.
It’s become normal for many grads to have blogs, robust sites, or even a mobile app or basic product when entering the workforce. The current boot camp trend produces graduates that usually claim an app. Apple’s App Store had 500 third-party apps around launch in 2008, and now between Apple and Google there are nearly two million. How many of those were developed for the purpose of job hunting?
Websites and blogs were more difficult to publish and expensive to maintain before the recent trend of free hosting and tools. It was uncommon for entry-level candidates to list sites or blogs on a résumé ten years ago.
How do they look for jobs? Did they even have to look?
If we are going to compare the ability for two graduating classes to get jobs, we should consider that methods to hiring and job search have also changed dramatically. Job boards like Monster and Dice existed in ’04 to post a résumé, but were primarily used by the most active job seekers and not for passive/ongoing job searches.
LinkedIn can help to both find people and then store contacts, with the added bonus of making users discoverable to potential employers – but LinkedIn only became available in ’03. Networking just a decade ago was more time consuming, while internships have become the norm for engineering students in recent years. Today’s graduate often has made at least a few potentially valuable industry contacts to use during a first job search.
Even if you were to get an interview in ’04, you went in blind. The amount of information regarding the interview process at a variety of companies is abundant, from best-selling interview question books to sites like Glassdoor. Job search has undergone quite a facelift, with unlimited supports in place to help job seekers identify interesting employers, demonstrate skills, and succeed in interviews.
Conclusion
Without trying to get into any debates as to whether colleges are producing better or worse engineers than they were ten years ago, it would be very difficult for ’04 grads to compete with ’14 grads in today’s market based on evolving expectations and changes in what CS students do during college. What might the résumés of CS grads in the class of ’24 look like?
¹ The shorthand ‘sub‘ is short for ‘subreddit‘, which is the name Reddit uses for various channels or forums.
² For the sake of transparency, my age is closer to the college class of ’94.
³ Source: see perhaps 25% of the posts at that same Reddit forum)
How and Why to Backdoor Into Jobs
When I read anecdotes from frustrated job seekers in the tech industry, they usually start out the same way.
“I applied to dozens of jobs
but I am not getting any response.”
Sometimes the low response is warranted due to lack of qualifications or less obvious factors, but often the problem is simply that the job seeker never got access to the person/people who matter most in the hiring of technical professionals. Hiring bottlenecks start with the traditional application process (submit résumé blindly) and can be further complicated by HR reps that are hiring for disparate skills and business units. At a smaller company with no recruiters, the task of screening résumés may go to junior employees and administrative personnel with no background or training in hiring.
When you like a company and want to get an interview, the ideal entrance is very rarely the front door. The front door is the advertised entrance that HR wants you to take, crowded with active job seekers with varying qualifications that will be culled or herded through the process by the people manning the door.
After many years in the business I’ve learned that if you ask privately (meaning not within earshot of HR), most technical managers don’t want candidates to come through the front door either. They would rather you came through a back door, and if necessary to hiring protocol they will later introduce you to the front door guardians to ensure passage. HR mans the front door, but the geeks own the back doors. This is how it works at many employers.
What are the more common back doors?
Hello World! What Every CS Student Should Know About the First Job
Anyone involved with hiring entry-level technology professionals (or reads posts on Reddit’s cscareerquestions forum) is aware that students are being prepared by schools for how to do work in the industry, but are often ill-prepared on how to find work in the industry. There is a major difference between the two, and many grads are being edged out on jobs by equally or even less-qualified peers who were just a bit more proactive about their career. If you think finding a job is only about internships and GPAs, please keep reading.
Some students feel that if they aren’t working 10 hours a day building the next Twitter from their dorm room, or if they didn’t intern at Google or Amazon, that they will struggle to find work. This is hardly the case, and I assure you that if you do a few things during your college years (that require a minimal time investment and no money), you will be several steps ahead when it is time to apply for your first job.
Continue reading
How to Network Less For Geeks
The fundamental importance of professional networking for today’s career-minded tech pro has been pounded into our heads for many years now. “It’s not what you know, it’s who you know” gets spouted by everyone who gets denied a job or interview, and there is certainly some truth in the saying. The mere thought of hobnobbing with other technologists at an event may instill terror in many (myself included at times), and most in the industry yearn to be evaluated purely on technical skills and not the ability to shake hands and make solid eye contact. If you are repulsed by the notion that elbow-rubbing skill may be integral to career success, or are uncomfortable in traditional networking situations, please continue reading – it’s less necessary today than most think.
When visualizing networking, most probably picture a room full of people segmented into smaller groups of varying size having discussions. (Googled “professional networking”, was not disappointed) It could be an industry conference, meetup, or even a more social event such at a bar or restaurant. The images will be appealing to almost no one except perhaps salespeople, and even many of them may shudder.
Continue reading
LinkedIn Spam (?) and Recruiters: A Guide for Geeks
Recruiters take quite a bit of heat from those in the tech community based on what many refer to as LinkedIn spam, and the definition of spam within LinkedIn’s context seems to be fairly wide. Recruiter shaming in public forums and blog posts about making ridiculous demands or nasty responses when being presented a potential opportunity are usually popular among a certain set.
Some potential recruits are a bit more creative, like making the Contact Me on their blog a puzzle that most recruiters will be unable or unwilling to solve. I for one truly admire his creativity and think this is a great way to keep recruiters from knocking based on your desire to have a web presence. +1 for allowing both a Python and Haskell option, which just makes me want to hire him more!
As I’ve said before, when the shaming and mockery of recruiters is deserved I’m not against it – I’ll grab my popcorn and watch. Although I probably use LinkedIn much less than others in my industry I am cautious to try and keep my use appropriate. Bashing recruiters is becoming a bit cliché, and I think the backlash related to LinkedIn in many cases seems unwarranted for a few reasons.
Many technologists use their LinkedIn profile as a way to attract employers – If you go to a publicized networking event and I approach you with a quick, “I’m Dave! Nice to meet you.”, punching Dave in the face is probably not an appropriate response. The environment you place yourself in (a networking event) should create the expectation that someone may try to engage you. Independent contractors, unemployed tech pros, and recent graduates often use LinkedIn specifically as their preferred method (over say Monster or Dice postings) of exposing their experience to recruiters and potential employers. If you are not using LinkedIn for this purpose, it might be useful for you to include that information on your profile.
It can be pretty confusing for a recruiter to get a nasty response from some LinkedIn users and a warm response from others, particularly when both profiles could be virtually identical. LinkedIn has products specifically targeted to recruiters and hiring entities. Being contacted about jobs on LinkedIn shouldn’t be considered a surprise or an infringement on your rights. LinkedIn is pretty clearly trying to allow people to find and contact you for this purpose.
LinkedIn limits how many characters you can include in an invite – If you’ve been complaining that the recruiter who pitched you a job through a LinkedIn invite gave you vague information, I’d encourage you to try pitching someone a job at your company through two tweets (and no URLs). Not to mention, you of course want to know why this recruiter feels you might be a good fit for the job. And you want to know about the job itself. Funding status? Tell me about the founders at least?? Chances are you will have to leave out something the potential hire would find important if you are limited to about 300 characters.
If a recruiter finds you on LinkedIn, the only way to contact you may be an invitation to connect – Most recruiters don’t expect that you will want to connect to them (as if connecting has some sort of implied relationship, which in most cases it clearly doesn’t) after a single relatively anonymous interaction on the internet. The majority of LinkedIn profiles for technologists don’t include an alternative contact method for those they are not connected to already. If the recruiter is unable to find other contact information the invitation to connect may be the only way to reach you, even if the recruiter feels that connecting is somewhat premature based on the lack of a prior relationship.
What to do when a recruiter sends you a LinkedIn invitation to connect, and how to prevent it?
Some thoughts
Remember that you are fortunate – You have a job that people are falling over themselves to hire you to do. The inconvenience of clicking Accept or Ignore is about as first world as a first world problem gets.
Don’t respond – Simply deleting the request takes hardly any time at all. If you get a lot of these requests and deleting them takes a bit more time, please see the point above.
Respond, but don’t connect – If it is something you might want to discuss but you aren’t ready for the whole level of commitment that a LinkedIn connection surely brings, just send a response and take the conversation to email. No harm done.
Create a canned response – Write a few sentences that you can cut/paste into a quick reply, explaining if/why you were offended and what (if any) type of opportunities you might want to hear about in the future. Recruiters who value their reputation will try and take your recommendations to heart (for the minority that have one) and be more courteous in the future.
Clarify on your LinkedIn profile that you don’t want to talk to any recruiters – Why is this necessary? Because you are on LinkedIn. If recruiters disobey this request, shame away.
CONCLUSION: You have every right to complain if you are approached for a job that is not at all appropriate to what you do, and you can certainly shame recruiters that ignore any notices you posted on your profile to try and prevent such contact. But let’s not call every LinkedIn contact about a job LinkedIn spam – for most, that is exactly what LinkedIn is there for.
Like my writing(s)? I wrote a book.
Job Tips For Geeks 