Last week, a GitHub repo called google-interview-university popped up on the radar when it hit Reddit and Hacker News. Go ahead and check it out.
The tl;dr is that an early-forties self-taught developer named John with an Econ degree and about fifteen years of varied startup experience has compiled a lengthy and thorough study guide of sorts that he is using to try to get a job at Google. It contains hundreds of links that run the gamut — tips from Google recruiters, books to read, articles on data structures, questions to ask in the interview, and even a link to a PDF file that says “future Googler” with the colorful Google logo intended for printing as some sort of inspiration (you know…because you should print a sign) — all courtesy of a man who uses the domain googleyasheck.com.
According to his LinkedIn, John has been studying full-time since April of this year to reach his goal of becoming a Google engineer.
Insert sound of brakes screeching.
A guy that has been programming since the TRS-80 days and doing stuff with the web since 2000 and runs his own startup is taking off seven months to try to get a job at Google?
I’m not sure exactly what is wrong with this picture, but something feels wrong.
It could be that someone is investing an awful lot of time into a goal that, when they reach it, might be entirely unfulfilling. This isn’t meant as a knock on Google – but clearly, like every other company in existence, Google isn’t going to be a great fit for everybody.
Maybe it’s that an experienced person already in the industry who is probably qualified for a substantial number of programming jobs and even less hands-on technical roles (Product Manager jumps out at me) at hundreds of other companies still may need (or felt the need) to spend over one thousand hours studying just to get past a few hours of interviews with Google.
And what if it doesn’t work out? I’m absolutely rooting for John no matter what (I can’t imagine his enthusiasm and newfound fame won’t help), and I guess if he has a bad day on the phone screen and fails he could still take his knowledge to some other elite companies that could hire him.
Reaction from the web has ranged from laments on the effect of Google’s “CS trivia” interviewing style on the industry to cringeworthy Google fanboyism to admiration for a guy who is working hard to achieve a goal. All have some level of validity.
I see Google worship on a fairly regular basis on Reddit, and I’ve previously written about this fixation many new college grads have on the “Big 4” (or Big 5) companies. It’s rare to hear of senior level candidates having the same enthusiasm, and rarer to see someone taking months off of work to try and qualify for a new job.
As much as I admire someone for setting a goal and working towards it, I’m torn.
I was on the phone yesterday with a senior level hiring manager from a potential new client, and she said something I hadn’t heard in a long while.
“We love older programmers.“
When I speak with CTOs and hiring authorities about their dream hires, some are more cautious than others when stating their preferences. I’m not a lawyer and don’t know specifics on the rest of the world, but here in the U.S. we have laws that try to prevent discrimination in hiring. Some company representatives will describe ideal candidates to recruiters in conversations that could be approaching a somewhat gray line from a legal standpoint, and in these cases a recruiter should clarify that he/she will present all qualified candidates regardless of whether they are a member of some demographic.
We read so much on ageism working against the most senior in the industry that sometimes we forget that there are firms that prefer some gray hair. The problem, of course, lies with the numbers. As I said, I hadn’t heard a strong desire for hiring the most senior level resources in a long time, and we generally don’t see companies using language in ads that would tend to attract older applicants.
Job specs penned by HR or internal recruiters may describe the company as being young and having energy without any disambiguation as to whether the reference is to the employees themselves or the newness of the organization. “We’re a young company” can have more than one meaning – maybe it means “we’re all 22 years old,” or perhaps it means “we’re in an incubator and angel funded.” We may read about established and stable companies, but how often do you see a reference to a “mature team”?
When we look at company websites that show photos of their entire development teams or just a few select profiles, it can give a sense as to the type of culture the firm is trying to portray. These are usually smaller companies and startups with photo choices varying from the serious and dignified to goofy costumed photo booth style shots that are rather shamelessly trying to appeal to a younger audience.
Maybe it’s because I’m in my mid-40’s, or maybe it’s because of the ageism I hear about (and defend my clients against with words) in my resume writing business, or maybe it’s because I spent 15 years running a Java Users’ Group that had its share of gray hairs, but I’ve always been sympathetic to the plight of the older developer. It’s refreshing to hear someone state that they are welcoming to the most senior talent, and I hope to hear that more in the future.
I was recently asked a question on Reddit about a specific contract-to-hire (C2H) scenario that I hadn’t given much thought to recently. With the prevalence of C2H (sometimes called ‘try before you buy’ in the recruiting world) in the market today, I thought the topic was worthy of full exploration.
What Is Contract-to-hire?
For those unfamiliar, contract-to-hire is where a company brings on a resource as a contractor with some level of understanding that there is either an intent or at least a possibility that the resource will be converted to a full-time (aka “permanent”) employee after some contract duration. During the contract period, the resource is often employed by some third-party agency who negotiates the rates.
The Numbers and Terminology
To add a bit of transparency to this, the agency will negotiate a rate with the hiring company (Bill Rate) which is what the agency will charge for every hour of the resource’s service. Then the agency negotiates a rate with the resource (Pay Rate) which they will pay the resource for every hour worked. The amount the agency makes on the transaction during the contract period is the difference between the Bill Rate and Pay Rate (Margin, or Spread).
If $COMPANY wants to bring on $DEVELOPER on a six month contract-to-hire basis, $COMPANY might agree to pay $AGENCY $100 for each hour of service. $AGENCY and $DEVELOPER have agreed to a pay rate of $80/hr, so the $AGENCY gets $20/hr for each hour $DEVELOPER works.
$COMPANY and $AGENCY may have also negotiated some type of buy-out clause, where at the end of the six months if $COMPANY wants to hire $DEVELOPER there will be a placement fee equal to n% of $DEVELOPER’s salary. Sometimes there is no fee involved in the hire, as the agency is considered paid because of their margin over the six-month contract. Other times the placement fee will vary based on the tenure of the contractor, where the buyout might be n% between days 1-60, n-5% between days 60-90, and n-10% days between days 90-180, and no fee at all after 180 days.
In our example above, if we assume a 40-hour workweek the agency would make about $20,000 during the six month contract period of employment. If there is a buyout clause as well, and the developer is indeed hired, the agency would make an additional flat sum.
Why Are Details Important?
Some readers might not care about the nuances of these agreements, and that’s certainly to the agency’s advantage. The reason these details are incredibly important is because the nature of the contracts will alter the financial incentives of the agency, and when those financial incentives are understood it may serve to better explain the behaviors of the agency.
As one example, suppose the agency is getting paid as outlined in the example above, but the agency receives no buyout upon hire. What would be the incentives for the agency? Obviously, the agency would rather have the developer remain as a contractor for as long as possible without ever converting. The agency is getting $20K for every six month period worked, but that turns into nothing when the hire is made.
Let’s look at a second example where the agency has a buyout clause with a prorated element, where the buyout amount is reduced over time as outlined above. What are the incentives there for the agency? There is some math involved (feel free to program a solution in the comments!), but the agency could look at the numbers to see when the optimum conversion time would be, and the agency would have some incentive to make that conversion happen within a certain range of dates. If we really get into the numbers, we could probably point to an exact hour where the developer’s conversion is in the best financial interest of the agency.
Who Have We Left Out?
We’ve explored the incentives of the agency without even considering the incentives of the developer. In C2H situations, there can be a wide range of incentives for the developer, many based on their own personal situation. Since the hiring company will usually provide the developer with several additional benefits upon full hire (insurances, retirement, paid time off), there is also some tricky math involved with figuring out the value of a perm hire compensation package when compared to the hourly rate.
Often contractors are paid a rate above what they would generally make as a perm hire, so we may see situations where the contractor tries to delay converting in order to maximize earnings. This could be in direct conflict with the agency’s financial incentives if a buyout is involved. As you can imagine, things can get rather interesting when the contractor has an incentive to remain a contractor and the agency does not. When analyzing bad recruiter behavior we need to consider misaligned incentives as a root cause.
An agency is trying to maximize their take, and we’ve established that the agency’s earnings are Bill Rate – Pay Rate. The agency has two incentives to increase margins – they first go to the hiring company and try to negotiate the highest Bill Rate possible, and then they go to the developer to negotiate a Pay Rate as low as possible. This model is vastly different to the recruiter/developer relationship dynamic in permanent hire recruiting scenarios (or even during a buyout in a C2H situation), where the recruiter has an incentive to maximize the developer’s compensation (because fee = n% of salary).
Sometimes a contractor will ask for a raise during the contract period. The agency will almost always object to this unless they are making a solid margin already. Unfortunately, the only party that is typically aware of all three numbers (bill rate, pay rate, margin) is the agency itself. The company rarely knows pay rate, and the developer is usually unaware of bill rate. That lack of transparency is in the best interest of the agency, which is why they will try to control access to these numbers.
We need to first keep in mind that in hourly contract negotiations, small numbers can add up. $1 an hour might convert to about $2K per year, and that figure translates to both the developer’s compensation as well as the agency’s revenues.
In most cases, the C2H developer won’t have a salary number defined for their conversion. They have accepted a temporary contract rate, but will need to negotiate their salary when the time comes. This can be problematic, as the developer doesn’t usually have much power in the negotiation. They may already have some level of attachment to the job and their co-workers, and the thought of another job search might be daunting. When you combine these with the fact that the developer probably does not have another job offer to leverage, it can make these negotiations more complex.
To protect your best interests, gather as much information as possible from the agency and the employer. Ask about the agency’s arrangement with the employer when it comes to conversion and buyout clauses, and try to learn about what you might expect to see in a perm hire offer.
A series of tweets by Patrick McKenzie (aka ‘patio11’), CEO of a startup trying to fix developer hiring inefficiencies called Starfighter and well-known for his writing on tech topics, got me thinking about hiring and branding discussions that I’ve had with clients in the past.
In my initial recruiting conversation with a new engineer contact, I always ask about the engineer’s job search criteria. I frame the question a few different ways in order to try and make sure I’m getting an honest answer, and (in order to best serve the needs of both candidates and clients) I try to note at least two or three criteria. Without fail, “I want to work with good people/teams” is an answer that I get at least 90% of the time.
Who Are the Good People?
For the purposes of these recruiting conversations, “good people” is generally shorthand for “skilled software professionals“. The “good” doesn’t equate to morals and ethics, although those are certainly part of the equation at some point.
When I’ve asked for a deeper definition of “good people”, I’ve learned that good people are smart and ideally want to do things the right way. They genuinely care about the quality of their work and their own ability to perform.
While consulting to my startup clients on the topics of employer branding and hiring challenges, I generally refer to some good people as magnets. A magnet is simply someone that other engineers want to work with or for, and usually possesses that mix of technical and soft skills that you wish every team member had. These are the engineers managers want to clone.
The hiring problem for many firms is that it’s difficult for the general public to discover if the company employs good people, or how many they might have.
Engineering Brands and Good People
If we definitively know or are relatively sure that a company has a talented software team, we could say that they have a strong engineering brand. Patrick’s tweet alludes to the fact that Google doesn’t have any issues with their engineering brand.
How do we know if any particular company employs these good people?
They Build Great Products
Good people build great products, right? But that has some major limitations for most of the world.
It’s relatively easy for companies like Apple, Amazon, Google, Facebook, and Microsoft to attract applicants because everyone uses their products. There is a second and third tier with somewhat less traction but enough clout within the industry to attract a healthy number of aspiring employees. Netflix and LinkedIn are good examples of the second tier.
But what about the startup building healthcare data visualization tools, the GIS apps developer, or even the regional consulting firm down the street? These firms may very well fall into the employers of good people category, but their products aren’t widely known.
They Show and Tell Us
Companies like Google and Facebook have engineering blogs and publish developer-targeted products that probably help with recruiting, but their reputations are already established. It’s the companies that aren’t in these top tiers of known entities that need to focus more time on these efforts. Unfortunately, most feel they aren’t able to make branding a priority.
And because of that decision, they don’t get the pipeline of applicants necessary and end up paying more for talent. If this is true, it is often worth paying a salary above market value to hire a magnet to join your company due to the cost savings that hire will generate on future recruits.
CTOs and hiring managers should be conscious of whether they have a positive engineering employer brand beyond just having a reputation in the industry. A general positive employer brand does not always equal a positive engineering employer brand.
As someone who has been in agency recruiting for almost 20 years, I can say rather confidently that engineering branding (and not just overall employer branding) is the most overlooked and underappreciated aspect of hiring in the market today, so much so that my own business will focus more on consulting to clients about engineering branding and less on the traditional transactional recruiting model in the future.
A few recent Reddit and Hacker News posts alluded to the idea of agents in the world of software. If professional athletes and artists can have agents representing them in hiring and negotiation situations, why not software talent as well?
Recruiters are almost always mentioned in these discussions, and after almost 20 years in agency recruiting I feel I understand the short and long-term financial motivations of recruiters pretty well. The primary difference between agents for athletes/artists and tech recruiters is that agents have incentive to help you get the best paying job, whereas recruiters only have incentive to help you get jobs with their clients.
Whether internal recruiters (think Facebook recruiters that only recruit for Facebook) or agency recruiters (that represent multiple companies), the motivation is only to get you the job IF the job happens to be with a company that is paying them.
If Lebron James’ agent only represented the Lakers, Knicks, and Celtics, it would severely limit his professional options. The agent wouldn’t care what the Cavaliers and Warriors might offer or whether those opportunities would be better for Lebron’s career. Lebron would likely want to work with multiple agents so he could be considered by the other 20+ teams in the league. Lebron might have 10 agents in this example, and they would all be working against each other and perhaps lying and cheating to get Lebron to sign with their client teams. This helps highlight a fundamental issue with the incentives of agency recruiters.
I first wrote about this topic almost four years ago in How to Disrupt Technical Recruiting – Hire an Agent, which explored the many issues and inefficiencies in contingency recruiting and how an agent model might work. I even wrote a follow-up piece shortly thereafter that got more specific on services that an agent might offer.
I admit that the current state of the recruiting industry, and in particular the overwhelming negative sentiment faced by third-party recruiters, has provided substantial temptation to transition my one man semi-retained recruiting practice into this agency model. My launch of Resume Raiders and offering of consulting and coaching to job seekers are a small step in that direction, and those services resemble a part of what I’d provide as an agent. If you want to seriously discuss representation, I’m easy to find.
Who Would Need an Agent?
The vast majority of software pros probably don’t feel that they need an agent, but that doesn’t mean there isn’t a market for the service. Here are a few thoughts on who might benefit most from an agent.
- The busy – Job searching takes time, which is why many just wait for jobs to come to them instead of actively researching opportunities. An agent could also manage and vet incoming inquiries (READ: clean out your LinkedIn inbox) to see if they are realistic options or a waste of time. Instead of replying to every recruiter, imagine having your agent reply that he/she will be fielding questions.
- The under-networked – Those without an established network are often limited to the traditional job market (listed positions) and don’t have access to the many possibilities that aren’t in the public domain. An agent must be connected to this hidden job market and to the major players.
- The transitioners – These are people who just need a true advocate during a challenging job search, which usually involves either getting out of a bad situation or transitioning into something significantly different (new tech, new industry, etc.). When a job seeker goes it alone, they are their only advocate. When using an agency recruiter, the job seeker now has another advocate, but that recruiter will only advocate for jobs represented by his/her agency.
- The meek – Those lacking confidence are more likely to accept jobs which are not ideal and approve of compensation packages below market. An agent will protect the client and help them say “no” to the wrong opportunity, provide guidance on regional market rates, and assist with negotiations if an offer comes in low.
Would You Actually Pay An Agent? And How Much?
The question of career agents usually comes down to money. Agency recruiters provide a free service (essentially paid by hiring companies) that some job seekers value and appreciate, but the service is clearly flawed due to the misalignment of incentives outlined earlier. The recruiter may do a great job and represent your best interests as well as possible, but at the end of the day, the recruiter works for the hiring company.
To hire an agent who will truly be representing without bias, the job seeker has to foot the bill. And how much should it cost?
The value of this service likely varies depending on who is being represented and what services the agent provides. Lebron James doesn’t need an advocate to generate interest in his abilities but rather just needs someone to make sure that market rate is received, help making the right choice, and ensure the terms of the contract are favorable.
Developers might feel that the value of this service will depend somewhat on how much an agent would be able to negotiate above the developer’s expectations. It’s been suggested that the agent’s compensation might be n% of the difference between actual compensation and expected compensation. So if the client would be satisfied with 100K and the agent negotiated an offer at 120K, one element of the agent’s pay would be a percentage of that 20K difference, keeping in mind that this is a one-time payment for an annual salary (that 20K difference multiplies every year). One flaw in this model is that the agent has an incentive to recommend the highest offer, even if that highest offer is not the best career move for the client.
Hourly rates are another possibility. One issue with hourly rates is that it encourages the agent to draw out the process. Any arrangement that doesn’t include some commission on the salary provides little incentive for the agent to negotiate aggressively.
There are companies who claim they are providing this type of service for technologists now, but those are mostly recruiting companies that are rebranded as agencies. A true agent will be able to help you with any employer, so firms that only service a select group of clients are not true agencies.
I’d be curious to hear thoughts on this topic. Again, I don’t expect this service would be appealing to everyone (what service is?), but it certainly would help to change the typical recruiter/candidate relationship that is so unpopular in the industry.
Whether through my recruiting work or my resume writing and coaching, I frequently review resumes that lead off with some kind of statement alluding to the candidate being a dedicated lifelong learner. Intellectual curiosity and a desire to keep skills current is something that many hiring companies will value, so it’s generally a good idea to convey those traits if you possess them.
Then as I make my way further down the resume, I try to see if there is anything to back up the claim. In most cases, there is little evidence to support that the candidate has made any independent efforts to pursue learning. Why the disconnect?
When engaging many of these candidates in conversation and digging deeper, I often learn about several examples that indeed validate the dedication to learning. It wasn’t that these people were lying. They just simply didn’t think some of these things were worth mentioning or often didn’t know exactly how or where to list these activities within the structure of their existing resume. I’ve had resume clients that omitted five or more worthwhile items from their resume that would clearly make a difference in an interview decision.
Below are some common examples of details that hiring companies will regard as evidence of intellectual curiosity which are often overlooked by candidates, and how to list them on a resume.
Meetups and Conferences
Being a leader, a speaker, or even just an attendee at technology events is something a potential employer should notice. Conferences can be listed specifically (city, date) or a more general listing can also work. Listing a few presentations is also appropriate if you’ve presented, and details can include title, date, and the name of the group.
Where to List: You could create a section “Community Activity” or “Presentations” depending on your level of involvement. If it isn’t enough to warrant a full section, a catchall “Other” heading can include some more random mentions.
Projects like websites for religious or service organizations are often considered rather trivial by highly experienced candidates but are definitely worth listing if they demonstrate the use of technologies that differ from the day job. Helping out or mentoring school students in tech (robotics clubs, career days) also qualifies here.
Where to List: A “Volunteer Experience” section is useful for someone with a couple things to list, or an “Other” section would also work.
Home automation projects, personal websites, or simple apps that have only one user (you, your spouse, your kid) are all worth noting if it shows something you had to learn.
Where to List: New grads almost always have a “Projects” section on their resume these days, so that has become a rather common header. Links to the code are a bonus.
Listing what you read can come off as a bit unusual sometimes, so this is probably something that only those who have little else will go with.
Where to List: This might be a small subsection under “Education” 0r perhaps a “Recent Readings” list in an “Other” section.
MOOCs, Courses, and Training
With the abundance of free or inexpensive offerings today, millions of professionals are signing up for subjects that either interest them or that they know may interest potential new employers. Some have better reputations than others, so do some research if planning to invest significant time or money in these efforts.
Where to List: Under “Education”, but below degrees. Unlike the listings in the“Experience” section, any non-degreed learning will not be listed in reverse chronological order, but rather by order of importance.
This week I received a multi-paragraph email from a job applicant who was applying for a developer position I had advertised with one of my clients. There was no resume attached or even referenced, which is highly unusual (sometimes there is nothing attached but a reference to an attachment). Maybe he forgot.
The email was almost exactly what I might have coached an experienced candidate to write in applying for this position. He demonstrated quickly that he had read the requirement and done at least a minimal amount of research on the company. His professional interests seemed to align nicely with the job responsibilities, he mentioned experience with the languages and frameworks we sought, and even linked to a couple project sites and GitHub repos so we could look at his code. The words he used were encouraging – “significant experience with…“, “I thrive in a…“, “worked extensively with…” – while indicating that he met the requirements of an ideal candidate. As you can imagine, I was quite interested.
I replied to express my interest and asked if he had a resume, which I use as a framework for an initial screening conversation and eventually is sent to the client if we agree to move forward.
The response noted that he’d forgotten to attach the resume, and he took the opportunity to reinforce his candidacy with a reference to a number of recent “larger projects” and further encouragement for me to view his code. When I finally opened the resume, I learned this candidate had no professional experience at all, and the projects referenced were all part of a recently completed 12-week boot camp.
It’s important to note here that the position I had listed was for an experienced programmer, and my hiring client would not consider anyone entry-level regardless of academic credentials. My client would not deem this candidate qualified for this particular role, but let’s pretend for the sake of this article that I did have an entry-level position available.
A Credibility Problem or Honest Misunderstanding?
When I learned that this candidate had never worked in a professional environment and had only been programming for a few months, his description of his experience now became a bit confusing. Larger projects? Significant and extensive experience? Thriving in and accustomed to certain environments?
Most professionals that have been in the industry would not consider a few months to be significant or extensive experience, and large projects in the industry aren’t typically completed in a few weeks. How would someone know what type of environment they thrive in if they’ve never been in a professional environment?
This disconnect could be the result of a couple possibilities.
If we’re giving the full benefit of the doubt, a boot camp graduate might consider these projects large just based on having no real project history to use as a baseline, and words like significantand extensive can be relative. A few weeks of experience could be classified as extensive when compared to someone that has never programmed.
At worst, the candidate is trying to represent a level of ability that he is rather unlikely to possess. Even the most intensive programs, whether they be boot camps or degreed, aren’t promising their graduates the ability to claim significant experience with large projects upon completion… are they?
Now this candidate would potentially be perceived as having a credibility issue, and, unfortunately, that label would stick even while under consideration for an entry-level job that he is likely qualified to do. What’s even worse is that an entry-level candidate has very little leverage in the hiring process without the credibility issue. So now we have what might be considered a somewhat homogenous entry-level candidate that starts off on the wrong foot.
Could he recover? Of course, it’s possible, but it shouldn’t be necessary. A more transparent approach which details the strengths and weaknesses is always a better option.