Disrupt Tech Recruiting II – So You Want Ari Gold?

After publishing How to Disrupt Technical Recruiting – Hire an Agent and reading the subsequent feedback from readers at Hacker News and elsewhere, it is clear that at least some subset of engineers believe two things:

  1. The technical recruiting industry is at times remarkably flawed, and the financial incentives inherent to the system will not always lead a recruiter to represent the job seeker’s best interests.
  2. There is some demand for a talent/agent model for tech professionals, and it is a service several would be willing to pay for.

And it is also worth noting that the only agent that engineers have know is Ari Gold (or at least that is the agent they want).  Not even ONE Jerry Maguire reference?  It seems engineers want to hug it out and care less about being shown the money.

During my dissection of the industry, I somehow overlooked perhaps the biggest flaw that is at the absolute core of the issues with the recruiting industry.  I’m a bit embarrassed that I missed it, and it wasn’t mentioned in the threads, so here goes:

Secrecy and privacy of information is THE cornerstone to traditional recruiting.

Why is that?  Well think about it.  If hiring companies knew every local candidate that possessed the skills they were seeking, many would not use an agency recruiter to handle the process and would simply have HR/managers contact them directly.  Likewise, there would be many candidates that distrust recruiters applying directly to jobs if every available job were listed in one single place to search.  There would certainly be some companies and candidates that recognize the value the recruiter brings beyond the initial introduction, but if all information were available to both sides we would find much less demand in the industry.

Why do you think recruiters don’t generally list their clients’ names publicly?  Why are there so many complaints about recruiters being unwilling to share a deep amount of detail about projects or their open jobs?  There are two main reasons.

  1. To prevent other recruiters from learning about who they represent (NOTE:  this is a big one, particularly for recruiters that work exclusively with start-ups that fly under the radar).
  2. To prevent candidates from applying directly to those companies, thus cutting out the chance for the recruiter’s fee.

So in order to preserve their chances of being paid a fee, recruiters need to keep candidates and companies from knowing about each other until a precise moment where they make the introduction to both sides, and then hope that the company doesn’t respond with some evidence of prior contact and that the candidate doesn’t say that he/she applied to that job yesterday.  If either of those two scenarios happen, the recruiter has some incentive for that deal to NOT work out, even though it is his/her client!  Let’s assume that company has one vacancy, and my candidate applied to it a day before I discussed it with him/her.  My incentive instantly goes from wanting my candidate to get the job (so I can get a fee) to a financial incentive that the candidate isn’t successful (so the job will still be available for another candidate I can find).  That is a very dark and unfortunate set of incentives inherent to the system.

It’s very easy to see how the incentives are built in this model.  Recruiters have the incentive to help out their client companies to fill jobs, but only if the hire comes from my agency.  The recruiter has the incentive to help a candidate find a job, but only if he/she takes a job at one of our clients.  This is the unfortunate symptom of contingency work, and thankfully in my current business model (which isn’t contingency) I don’t have these same incentives to the same degree.  Who are contingency recruiters really providing a service to anyway?

Why do you think recruiters see LinkedIn as both a blessing and a curse?  We use it to find new candidates and keep in touch with past candidates and clients, yet we realize that everyone else now has access to the same information and companies can much more easily find candidates.  As a recruiter, you are probably likely to list your contacts as ‘private’ for this reason.

The agent model would not have this privacy incentive built into the system.  I could see an argument made where an agent might not want other agents to know who he/she is representing, but I think that is a much smaller problem than what we have today.  When one of an agent’s talents is seeking work, there would be a campaign of open information to try and get the talent noticed.  Having a business model based on privacy and secrecy is much less attractive than an agent model with openness.

Enough about what’s broken, let’s talk about solutions.

Based on the discussions, here are the services that the talent knows they want:

  1. Negotiation in job changes – Engineers seem to agree that an agent would probably be better at negotiating compensation packages.  Another added benefit to having an agent in act as a proxy in negotiations is the preserved comfort factor after you potentially start the job.  Picture a very trying or heated negotiation between an engineer and a start-up CEO that comes to an eventual agreement, and then the two must work in adjacent cubicles the following Monday.  A buffer would have helped prevent any potential awkwardness.
  2. Job identification and coordination – Many in the community made it pretty clear that they are not interested or skilled in cold calling and introducing their services to potential clients.  Having an agent do the legwork to identify potential employers and then to contact them and schedule meetings on the talent’s behalf will save lots of time to do other things.  For consultants paid hourly, remember that every hour spent on job search is an hour you can’t bill to a client.
  3. Competitive salary/rate information – There seems to be a general distrust for websites that provide market information, and engineers may be somewhat insulated when it comes to what others with similar skills are earning.  An agent would have some solid evidence regarding street value of any talent and would do the research necessary.
  4. Marketing/PR/Selling – It has become clear to me over the years that there is a sizable percentage of talented engineers that are uncomfortable talking up their own skills, and that was mentioned a couple times as another asset of an agent.  Marketing and PR would probably mean different things for different career levels, but it could include work to increase the talent’s blog traffic, booking a presenter’s invite to a users group/meetup, or strategy on how to build the talent’s brand.

There were some services and advantages that were somewhat surprisingly not mentioned:

  1. Handling incoming job solicitations – All of the complaints about recruiter spam and cold calls are gone for the agent’s talent.  Forward calls, emails and LinkedIn spam to your agent, and he/she will investigate.  Put your agent’s name on your website and LinkedIn profile.  If the opportunity is legitimate and meets the criteria the talent sets for sharing, your will get the details.  If not, you never have to waste your time hearing about it.
  2. Interview coaching – Not just your standard fare interview coaching you can find on web sites, but also any inside tips on the specific interview.  This could include past experiences others have had with the company, some research on the background of the people you are meeting, and anything else that will be helpful to the talent.  Remember that the agent is representing you at this point and not the company.  As one reader noted, a good agent would not want to do companies a disservice by providing specific interview questions (as that would harm the agent model, the hiring company, and the agent himself/herself), but it is fair to offer the talent some guidance on what format to expect and who they will be meeting.
  3. Internal company information – As your representative, the agent should be providing talent with details on both their current employer and any that you may be considering for future employment.  The information learned from discussions with others in the business will be helpful to the agent’s entire stable of talent.  Consider it the type of info you may find on Glassdoor, but from verified sources.
  4. Career advice in non-search situations – Are you thinking about moving from code into management, or considering taking a leadership position on a project doomed for failure?  Considering a jump into contracting, or thinking about abandoning your current independent consulting project to join a start-up?  Want to talk about it?  The value of this advice could be quite large yet difficult to quantify.
  5. Negotiation of promotions or raises – Changing jobs is not the only scenario where negotiation may take place.  An agent could help you get the best deal from your current employer, either through direct negotiation or by coaching you on how to maximize your chances of getting a good number.
  6. Resume creation/curating – This one isn’t a huge service but it’s a few hours out of your work year.
  7. Transparency! – The agent model is completely transparent to everyone involved.  The agent represents the talent, and the talent pays for that representation.  There is no question about the agent’s loyalty as there is in contingency recruiting models (is the recruiter representing me or the company?).

Some potential issues were identified in the comments

  1. Would there be any conflict of interest when representing multiple candidates?  Doubtful.  I guess there could be a rare situation where two talents vie for the same position, and in that scenario the agent would simply represent both fairly and let the best person for the job win.  The agent would probably have no financial incentive favoring either candidate.  Transparency would be important (revealing the situation to both talents).
  2. Would there be backlash by hiring entities against candidates who use an agent?  It’s hard to tell, but it’s conceivable that there would be some organizations that might react hesitantly at first.  However, the key here is that an agent would be providing a service to a company for free (or if not completely free, definitely much less expensive than recruiters).  It would be hard to think that firms would not be very pleased with a cold call from an agent stating that there is a qualified candidate interested in your company, and you will get all the normal recruiter services for the process with no recruiter fee at the back-end.
  3. How much would the agent need to know about technology?  This one comes up quite a bit in criticisms of technical recruiters and then in the discussion of an agent.  The agent needs to know enough about tech that he/she won’t misrepresent the talent, and will not waste time marketing talent to positions that are not a technical fit.  An agent should also have some sense of tech trends, what skills are in demand, and the overall market for different types of talent.  The biggest complaint seems to be wasting time with discussions of jobs that are not a fit or being sent on interviews that are not appropriate.  An agent would not have the same incentive to send you everywhere imaginable, as that incentive is not built into the agent model.
  4. Would the service be just for contractors?  No, not the way I see it.  The pricing model for contractors is very easy to consider, as paying a percentage of hourly rate to the agent is already a common practice for staffing firms (what is called ‘margin’).  The value of an agent’s service to engineers with salaried positions seems very obvious in helping to manage the overall career as well as the career moves.

How do we compensate the agent?

This is a bit tricky and I believe that the pricing model might be different for contractors and talent in direct salaried positions.  For contractors, the existing model (a ‘per hour’ cut) is well-known and accepted.  I think the main difference is an agent would have some fixed transparent rate ($x/hr or y%/hr.  Many recruiting firms do not reveal the full bill rate to the contractor, which tends to cause distrust when the contractor finds out the actual rate.  Having a fixed percentage or dollar per hour figure would make the relationship much more comfortable for both sides.

For talent in permanent salaried positions, there needs to be more discussion.  My vision would be some flat annual representation fee for service with an additional charge/bonus for times of active job search (where the level of services and time invested would increase).  The job search fee could have several models built in – perhaps an hourly rate, flat fee per week/month, flat fee per job search, or some percentage of salary.  The problem with the percentage of salary model is that it gives some incentive for the agent to suggest you take the highest paying job even if that is not best for your career.  Another model would be a negotiation bonus above some level set and agreed upon by the agent and talent.  “For anything I get you over 120K, I get a one-time bonus of 50% of the difference.”  That leads to some incentive to take the highest paying job, but it also gives more motivation to negotiate.

The reason I include an annual representation fee into the discussion is it helps to eliminate an agent’s incentive for candidates to change jobs, and it allows the agent to justify investing time with the talent to discuss career-related issues that come up.  In the traditional recruiting model, the recruiter hopes everyone is looking for a job at all times.  An agent would have much less of a financial incentive for you to change employers, so the agent wouldn’t be as likely to suggest you leave a job that is right for you.

CONCLUSION/tl;dr

Traditional contingency recruiting incentives are:

  1. Privacy and secrecy of client company and candidate information.
  2. Only help client company when it results in a fee.  Only help candidates when they take jobs at my clients.
  3. A desire for people to leave jobs as often as possible.

Agent model incentives:

  1. Keep the talent happy so they remain your talent.
  2. ???

Let’s keep the dialogue going on this.  Based on lots of direct feedback, it seems the community could be on to something.  Agree, disagree, suggest?

About these ads

How To Disrupt Technical Recruiting – Hire an Agent

A recent anti-recruiter rant posted to a news group and a subsequent commentary on HackerNews got me thinking about the many ways that tech recruiting and the relationship between recruiters and the tech community is broken.  I saw a few comments referencing that the community always says how broken it is, but no one tries to fix it.  Here are some ideas on how we got here and directions we can go.

Why is the recruiting industry the way it is?

  • The high demand and low supply for tech talent creates a very lucrative market for recruiters.  Many technologists might not be aware of this, but successful recruiters probably all make over 100K (some earn much more) and as a commission-based business your compensation has no maximum.
  • Recruiting is an easy field to enter.  No formal training is required, although you will need some sales training and tech knowledge to truly make an impact.  One can easily start with a computer, a phone line, and a basic website.

So we have an industry that can be very lucrative (for some much more lucrative than the tech industry itself) with almost no barriers to entry.  Of course an industry with these characteristics will draw both talented, ethical professionals as well as carpetbaggers and bottom-feeders just as the gold rush did.

What are the biggest complaints about recruiters (and how can we solve them)?

First, complaints from candidates (tech pros):

  • Too many cold calls.  POSSIBLE SOLUTION:  Without some widespread changes from all three parties (candidates, hiring firms, and recruiters) in the industry, this one is probably impossible to solve.  Simply mentioning that you do not wish to hear from recruiters is no guarantee that they won’t contact you, but if I see on a LinkedIn page that someone specifically doesn’t want to hear from recruiters I won’t contact them as it is clear they do not value the services I provide.
  • Dishonesty about the job description or salary.  POSSIBLE SOLUTION:  What if companies gave recruiters some form of ‘verified job spec‘ to share with candidates?  Salary range, job description, location, whatever else might be helpful.  A candidate could request this from the recruiter before agreeing to an interview.
  • Being marketed/used without their knowledge.  POSSIBLE SOLUTION:  Companies could require a ‘right to represent‘ email giving a recruiter permission to submit his/her resume for any or all positions, which would at least eliminate some of this.  Of course, recruiters will still send blinded resumes (contact info removed) to client prospects.  A better idea may be for candidates to have a document that they ask recruiters to sign – a contract where the recruiter agrees not to send their resume in any form to any company without the express written consent (the ‘right to represent’) of the candidate.  I’m not a lawyer, but I assume there could be some financial penalties/restitution allowed if you were to break that trust, as you may damage the candidate’s career.  As a rule, if I want to market a candidate to a client, I always get their permission first.
  • No feedback or follow-up.  POSSIBLE SOLUTION:  Unfortunately there is little value that a company gets by providing specific feedback about a candidate, and it actually exposes them to substantial risk (ageism, racism, etc.).  Likewise, taking time to give rejected candidates details provides nothing to the recruiter except goodwill with the candidate.  This one is difficult to solve, but probably not as big an issue as the other problems.

And complaints from hiring firms:

  • Too many resumes.  POSSIBLE SOLUTION:  If you provide a very good requirement to a good recruiter, he/she should be able and very willing to limit the resumes.  Telling your recruiter that you want to see the best five available candidates should encourage them to limit submissions.
  • Unqualified candidates.  POSSIBLE SOLUTION: Same as above.
  • Misrepresenting a candidate’s background.  POSSIBLE SOLUTION:  Well for starters, stop working with the recruiter and that agency entirely.  If you want to make a positive change for the recruiting industry, contact the recruiter’s manager and tell your side of the story.  Having liars in an industry is bad for everyone except the liars and those that profit off of them.
  • Marketing cold calls.  POSSIBLE SOLUTION:  If you truly will not use recruiters for your searches, list that on your job specifications both on your website and the jobs you post publicly.  I would rather not waste my time if a company has a policy against using recruiters, and if your policy changes perhaps you will be calling me.  I will not call a company that specifically lists that they do not want to hear from recruiters, as it is clear they do not value the service I provide.
  • Price gougingPOSSIBLE SOLUTION:  This could be when recruiting agencies mark-up their candidates’ hourly rates well beyond what is a reasonable margin, or when recruiters who receive permanent placement fees tied to salary will stretch every penny from the hiring company.  Flat transparent fees work very well for both of these problems (a flat hourly mark-up on contractors and a flat fee for permanent placements), although recruiters would particularly hate a flat fee structure for contractors.  The recruiter’s ‘sale’ to a contractor is, “If I can get you $300/hr, do you care if I make $2/hr or $100/hr?“.  The answer is usually ‘no’, which is all fine until the contractor finds out that you are billing your client $300/hr and only paying the him/her maybe $50/hr.  That is rare, but that is when things get ugly.  Flat and transparent rates exposed to all three parties involved will solve that problem, but don’t expect recruiters to go for it.

To all the technology pros who claim they really want to disrupt the industry, I have one simple question.

Would you be willing to hire, and pay for, an agent?

I’ve heard the argument from some engineers that they would like recruiters to care more about the engineer’s career and not treat them like a commodity.  Recruiters are traditionally paid for by the hiring companies, but only if they can both find the proper talent and get that talent to take the job (contingency recruiting).  This can lead to a recruiter treating candidates like some homogenized commodity that all have similar value.

If engineers want true representation of their best interests, having representation from a sole agent would be one obvious choice.  As your agent, I could provide career advice at various times during the year, making suggestions on technologies that you may want to explore or giving inside information on which companies might have interest in you.  You might come to me to discuss any thoughts on changing jobs, how to apply for promotion, or how to ask for a salary increase (which I could negotiate for you directly with your manager).  When you do decide to explore new opportunities, the agent would help put together your resume, set a job search strategy, and possibly market your background to some hiring companies.  As the agent is making his living by charging a fee to the candidates, the agent could charge a much smaller fee (or potentially even no fee) to the hiring company, which would make hiring you much less expensive than hiring through a traditional recruiter.

If you were contacted by a recruiter from an agency or a hiring company, you would simply refer them to me for the first discussions and I would share the information with you (if appropriate) at a convenient time.  You could even list my name on your LinkedIn, GitHub, and Twitter accounts.  “If you are interested in hiring me, contact Dave at Fecak.com“  How good would that feel?  How good would it feel to tell your friends that you have an agent?

All of this assumes your agent would have some high degree of knowledge about the industry, the players, market rates, and a host of other things.  Many recruiters don’t have this expertise, but some certainly do.  An agent could probably represent and manage the career of perhaps 50-100 candidates very comfortably and make a good living doing it.

Would you be willing to pay a percentage of your salary or a flat annual rate to an agent who provides you with these services?

If the answer is ‘yes’, look me up and I’d be happy to discuss it with you further.  But I’m guessing for many the answer is ‘no’ (or ‘yes, depending on the price’).

My business model

Most recruiters are contingency based, which means they only get a fee if they make a placement.  If they search for months and don’t find a proper candidate, they just wasted months for no payment.  This places 100% of the risk of a search on the recruiter and 100% of the control with the hiring company.  Even if the recruiter finds a great fit, the company can walk away without making a hire.  Contingency recruiting is cut-throat and causes desperation to make a placement, and this is where most of the problems arise for candidates.  This is the ‘numbers game’ that tech pros talk about, where the recruiter’s main incentive is to get resumes and bodies in front of clients and see what sticks.

Some recruiters are retained search, which means that basically all their fees are guaranteed up front regardless of their results.  This is great for the recruiter but places 100% of the risk on the hiring company.  The recruiter is working this search to save his/her reputation, which is obviously very important in getting future searches.  This is not cut-throat, because it is not a competitive industry – recruiters have exclusive deals with a retained client for that particular job.

The model I use combines contingency and retained search.  I charge clients a relatively small flat fee upfront to initiate the search, which is non-refundable.  When a placement is made, I charge my clients another flat fee (not tied to salary).  When you combine the two fees, the percentage of salary is often about half what contingency recruiters would get for the same placement.

So you think I’m an idiot for charging much less than my competition.  Perhaps.  I see it as creating a true partnership with companies that continue to come back with additional searches and repeat business, often referring me to their friends and partners.  When a company gives you a fee upfront, they are putting their money where their mouth is and you can be sure they are serious about hiring.  It takes some degree of trust on behalf of the hiring company, but once you have been in the business for a while the references are there and chances are we have some business connections in common.

So far this model has worked well, with happy clients and lots of repeat business.  I have already met my goal for 2012, and I’m hoping to double it in the coming months.

What else do I do differently?

  • I give it away (sometimes) – information, resume and interview advice, and any other kind of help you can think of are requested of me, and I rarely refuse a reasonable request.  If I can’t help you find a job, I can at least take a look at your resume or evaluate how your applications look. I have known some engineers for over ten years without ever having made .05 in fees, and  have helped them make career decisions for free.  I’ll often introduce candidates to  start-ups or one-man firms with limited budgets who may end up hiring without using my services, with the hopes that they will use me for future searches.
  • I run a users’ group – I’ve run the local Java Users’ Group for almost 13 years.  It is a volunteer job with no compensation, but it helps me stay in touch with the tech community and it also adds some credibility to my name.  It is a lot of effort at times, but the success of the group is something that I’m quite proud of.  I don’t recruit out of the group, but most of the group are aware of my services and come to me for my services when necessary.
  • I specialize – Historically I focused both geographically and on one technology (Philadelphia Java market).  I’ve opened that up a bit as many of those Java pros are now doing mobile, RoR, and alternative JVM lang work, and I’m a bit more regional now.  Staying specialized in one geography and one technology forces a recruiter to be very careful about his/her reputation, as the degrees of Kevin Bacon are always low.
  • Flat fees – A flat fee lets the company know that my goal is to fill the position and how much you pay the candidate is irrelevant.  I inform candidates of this relationship so they are aware that my goal is to get them an offer that they will accept, and my client companies know that if I say I need $5K more in salary to close the deal that I am not trying to line my pockets.

CONCLUSION
Don’t expect my model to be adopted by any other firms, but I wanted to share it with readers as at least one alternative to the traditional contingency model that seems to be the biggest complaint for both candidates and hiring firms.  And I believe the agent model would work quite nicely for all parties involved if anyone would like to inquire.  If you truly want to disrupt the industry, let’s talk.

TALK! It’s An Interview, Not An Interrogation

Several times a year I will get a call or email from a hiring manager telling me that an interview never really ‘went anywhere’ because the candidate seemed either unwilling or unable to dive very deep into technical topics.  It can be impossible for an interviewer to accurately gauge whether the cause was a lack of tech skills or just an inability to communicate those skills, but it really makes no difference as the end result is a rejection.  This observation is probably a bit more prevalent during phone screens, where the parties do not have the advantage of proximity and body language to assist.

Whenever I hear feedback like this from clients, I imagine what the interview may have sounded like:

INTERVIEWER:  Have you worked with Ruby on Rails before?
CANDIDATE:  Yes, I have.
INTERVIEWER:  Could you elaborate on that a little bit?
CANDIDATE:  Yes, I could.
INTERVIEWER:  (VISIBLY ANNOYED)

It brings to mind the old joke (which of course reinforces gender and programmer stereotypes):

A wife asks her computer programmer husband, “Go to the store and get a gallon of milk, and if they have eggs get a dozen.”  A short time later the programmer returns with twelve gallons of milk.  She asks, “Why did you get twelve gallons of milk?” and he responds, “They had eggs.”

In the short two question interview scenario above, the candidate is answering the questions being asked, and the candidate is providing all the information that was being requested.  If you look at the questions in a literal manner (as many engineers tend to do), this candidate may not feel he/she is being dodgy at all.  Just as the programmer in the joke did what his wife asked (by his literal interpretation).

Let’s now look at a brief example of a police interrogation:

INTERROGATOR:  Where were you on the night of the 8th?
SUSPECT:  At home.
INTERROGATOR:  Were you by yourself?
SUSPECT:  No
INTERROGATOR:  Who was with you?
SUSPECT:  My husband.
INTERROGATOR:  WHO WAS WITH YOU??!!
SUSPECT:  My lover!  (CUE SCARY MUSIC)

These answers provide the minimum amount of information the interrogator requested, and a lawyer will probably advise you to keep your answers short and precise during questioning.  The interrogator’s job is to get a suspect to say something that he/she does not want to reveal.

A job interview is not an interrogation, and it is important for candidates to be sure they are not treating it as such.

Keep in mind that interviews, particularly in technology settings, can be awkward situations for participants on both sides of the table.  Most interviewers are at least slightly uncomfortable being placed in a room with a complete stranger for the sole purpose of judging him/her in order to reach some conclusion about whether he/she should be hired, a decision which could greatly impact the life of at least one party (the candidate) or even both parties (if the hire is made).  If an interviewer gives even a small consideration that this stranger may have a family that depends on the income that the job would provide, the potential for an awkward exchange is even more likely.

Most interviewers want to get a dialogue flowing, where the discussion will allow them to evaluate your technical and interpersonal skills.  They want to control and moderate the conversation, but they would like to listen more than they speak.  The candidate’s ability to communicate his/her thoughts will be apparent after a few questions.  At some point most interviewers have to ask themselves, “Would I want to work next to this person every day for several years?”  If the candidate answered their questions in a fashion resembling the Candidate or the Suspect in the samples above, the answer is always “No”.

Some candidates may argue that they have answered the questions as asked, and that if the interviewer wanted more details he/she should have inquired for them specifically (“Tell me about Ruby on Rails experience.”).  This is a valid observation, but it doesn’t solve the problem.  It’s purely a function of conversational English, and it is one reason that chatbots with artificial intelligence may give answers like our Candidate did in the example.

So, I’ll just keep talking and talking to solve the problem?  NOPE.  There is also the possibility that if a candidate answers every question with a long-winded response, he/she may be rejected for not being able to provide succinct answers.  Managers are often unwilling to hire someone who they feel is unable to express themselves efficiently, and in the case of software engineers you may hear, “Being that chatty, I can’t imagine what his/her code (comments) looks like!

How do I appear to be open, honest, and transparent without sounding chatty?  How do you avoid being labeled as unable or unwilling to answer interview questions?

  • Don’t take every question literally – Remember that a good interviewer is trying to engage you in a dialogue and an exchange of ideas.
  • Pause before answering – Some candidates seem programmed to immediately start talking after a question is asked, and then find that they haven’t really answered the question.  Taking a moment to reflect on the question and to organize your thoughts gives the appearance that you are making an effort to supply a strong answer and that you are not impulsive.  A little white space does not have to be an uncomfortable silence.
  • Pause after answering -  If the interviewer does not respond with a follow-up after a few seconds, he/she may be waiting for you to go deeper.  Ask if he/she is satisfied with your answer and offer to continue with more information if necessary.  “Would you like some more details on that?
  • Ask questions to clarify what type of answer is expected – If you are asked a question where there could be both an acceptable short answer (yes/no) or a longer answer (details), give the short response and offer the interviewer more.  “Yes, I have used Ruby on Rails.  Would you like me to discuss my experience further?
  • At the end of the interview, ask the interviewer if they have any other questions that will help them make their decision. Invite them to contact you in the coming days if any additional information is required or if they would like any clarification on the answers you provided.

Go into the interview with the goal of having a conversation which should put the interviewer at ease.  Be willing to follow the interviewer into any direction the discussion may take, and ask questions so you know that you are on the same page.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on FacebookTwitter, or Google+.

How Hackers Choose Tools (thoughts on Paul Graham’s Java’s Cover)

Recently, a 2001 blog post with the title Java’s Cover written by Paul Graham (of Y Combinator fame) spread across Twitter and was linked by all the other usual tech site suspects.  The piece was about what Graham called ‘hacker’s radar‘, which he describes as the ability of hackers to ‘develop a nose for good (and bad) technology‘.  For his description of hacker’s radar, he decided to cite Java as an example of a technology that smelled bad at the time.  Java’s popularity in 2001 made it a pretty big target for critique.  The title Java’s Cover is a reference to judging a book by the cover, and Graham argued that Java’s cover was a stinker.

Graham admits in the article that he had never written Java and his main exposure was when he ‘glanced over reference books‘, though Graham does have substantial tech credibility as a hacker.  He lists 12 reasons why he didn’t like the look of Java, and mentions that he had a hunch that Java would not be a very ‘successful language‘ (but he ‘may turn out to be mistaken‘).

The commentary on the aforementioned usual suspect sites seems, predictably and unfortunately, to be centered on the accuracy (‘is Java truly successful?’) or inaccuracy (Java is everywhere) of the prediction itself.  I feel it is a much more interesting exercise to take the opportunity to go into the author’s opinions as representative of an advanced technologist, and to see what factors would lead a like-minded and influential technologist to potentially have the same negative reaction to a new tool/language based on relatively non-technical factors.  Every day we read articles that are highly critical of languages, frameworks, design patterns, and anything else you can imagine, and it can be difficult to tell how much experience the author may actually have (or even need) to make such assertions.  When an industry voice writes an opinion on a topic based on the factors listed by Graham, what weight is given to the conclusions by the community?  Graham’s article is somewhat unique in that he was willing to list the ‘smell’ reasons for his suspicion.

Looking at each reason Graham gave individually may give us some insight into how technologists yesterday and today may form opinions about a variety of topics, and whether or not we can use these tests to determine future success.

1. It has been so energetically hyped.

While it is certainly true that excessive hype can be a sign of any potential product’s weakness, that certainly isn’t always the case.  Graham mentions notes that ‘A real standard tends to be already established by the time most people hear about it’.  You will find that almost every technology that is highly criticized has been blessed/cursed with a fair amount of hype, either generated by marketing people with profit motive or evangelists that may have much smaller (or even zero) financial interests.  I’m not sure that hype alone should make technologists wary about a new offering, but people who are naturally skeptical will surely be wary of over-the-top hype efforts.

2. It’s aimed low.

This one seems to have some merit.  In this case Graham is saying that Java is intentionally dumbed down, and that ‘Java’s designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.

When people create a product/tool for other people to use, they obviously want their audience to be able to learn it, and Graham seems to argue that by ‘aiming low’ and focusing on ease of use you are probably placing unnecessary limitations on the product you are building.  If you were creating based solely on the need to solve specific problems, ease of use would not be as great a factor.

3. It has ulterior motives.

In this case Graham is speaking of Sun’s plan to ‘undermine‘ Microsoft.  We could certainly apply some tests of ulterior motives to several new developments in tech over the past several years, but I’d imagine it would be a difficult task to find similar motives in the overwhelming majority of new products.  This one is probably, in most cases, not applicable.

4. No one loves it.

Ouch!  Every language, every tool, is loved by someone.  Remember all those people in #1 above that make up the hype machine?  Perhaps by saying ‘I’ve never heard anyone say that they loved Java‘, Graham meant that that no one of any influence or importance loves it.  If a product is eschewed by the most widely respected folks in industry, that is a warning sign.  When some thought leaders begin to endorse tools they become viable for others to adopt (see alternative JVM programming language adoption by big firms today).  Some former Java evangelists professing a love for Scala comes to mind.

5. People are forced to use it.

Being told that you have to use a tool does not make it questionable, but in Graham’s brief description he infers that the anecdotal evidence includes smart people that would have used the tool voluntarily if it were good.  This is probably better said as ‘Outside forces with potentially differing objectives force technologists to use it against the techie’s own better judgement.’  It’s hard to argue with that.

6. It has too many cooks.

This one is quite interesting, especially with the changes that have occurred in the industry since 2001 and the emergence of open source as a dominant player in the market.  Graham went on to write that ‘the best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.

Issues with the JCP over the years have been written about ad nauseam.  But what would Graham make of other open source developments over the years?  I imagine the rebuttal would be that only the highest level members of an open source project are truly the ‘cooks’ he refers to, with the rest of the members merely relegated to chopping and slicing.  Maybe not.  Being suspicious of multiple decision-makers pandering to multiple masters would be natural, and warranted.

7. It’s bureaucratic.

In this case Graham is referring to the language structure itself and not the leadership.  This can be perhaps lumped into #2 It’s aimed low although not in every instance.  If a language is ‘aimed low’, you might expect that the designers would try and limit the types of mistakes users could make (see #9 as well).

8. It’s pseudo-hip.

Interesting perspective.  I’d argue it was hip.  Graham continued, ‘Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.

I couldn’t help but notice the words Graham uses to critique Java in 2001 are very similar to how Democrats paint the modern day Tea Party (an observation on the language, not a political statement).  The real meat of this criticism seems to be that the product is controlled by a large organization, which per Graham would by default make it ‘clunky’, but posing as a much more community-friendly and open option.  I’m guessing this element of Graham’s opinion would have been amplified dramatically after the Oracle acquisition.  Would hackers feel differently if a big company tool wore the corporate badge proudly?

9. It’s designed for large organizations.

Graham specifies that Java was designed to limit large teams of mediocre programmers from causing damage.  This seems very much like reasons #2 It’s aimed low and #7 It’s bureaucratic above.  This is probably more accurately categorized as ‘designed for mediocre programmers‘.  I would assume that any advanced technologist would probably be less interested in a tool that seems to be created for a lesser engineer.  Graham wants only languages for big boys and girls, and most advanced and even intermediate hackers would probably agree.

10. The wrong people like it.

Graham lists the wrong people as ‘suits’ tuned into the hype from #1, big company programmers from #9, and college kids looking to get a job.  He feels that all three of these groups change their minds regularly.  I’d say the college kids of 2012 appear to be interested in newer technologies (Ruby, Python, functional programming, mobile) that are probably not the core of their curriculum (Java), and in 2001 they were also interested in newer technologies (Java) that were also not the focus of their education (C/C++).  Does the interest of college grads in Ruby and Python make those tools the wrong tools, or do today’s college grads have a bit more of a sophisticated hacker palate?  What do the suits and big company programmers love today?  Tools with ample talent supply, maybe?

11. Its daddy is in a pinch.

Java’s OLD daddy was, but Java’s new daddy buys islands!  But this isn’t about Java.  The financial standing of the steward of a language or product is certainly a valid consideration to make when evaluating the future viability regarding use in developing a product.  But who would be deemed the daddy of open source tools?  Individual project owners perhaps?  The vendor ecosystem that supports them?  The landscape has changed enough since 2001 that this criticism might be less of a factor now.

12. The DoD likes it.

Guilt by association, and Graham calls DoD culture the ‘opposite‘ of hacker culture.  In some recent discussions about Java and alternative JVM languages, I’ve seen this discrimination used in reverse, where Java supporters claim that the use of the alternative JVM languages by start-ups is a strike against using the alternative options.  The argument is that start-ups are all run by kids and cowboys, so any choices they make can’t be grounded in solid technical judgment.  Interesting how two groups, who both probably feel they are above-average technologists, can come up with opposite interpretations.

CONCLUSION

If you made it to the very bottom of Graham’s post, there is a link to an article called Trevor Re: Java’s Cover, which refers to comments by Trevor Blackwell (also a YC partner) about the post.  Blackwell classifies programmers as either ‘brilliant hackers‘ or ‘corporate drones‘ with most tools being written for the drones, so hackers need to know the smell tests to decipher quickly which tools are meant for the hacker and which were designed for the drones.  Of course, very few of the people Blackwell calls drones probably feel they are in that camp, which just complicates the issues even more.

I feel that Graham’s article is interesting as a time capsule to compare how hackers thought about new tools in 2001 and how they may come to conclusions about languages today.  As an investor, I’m sure some of the same smell tests Graham listed would apply to how he evaluates start-ups for potential funding.  Whether Graham was right or wrong about Java doesn’t matter at all, but getting a glimpse into his thought process then is quite valuable.

How would the current batch of popular and emerging technologies fair today, using Graham’s microscope?

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on FacebookTwitter, or Google+.