Tag Archives: jobs

How to (Partially) Control Your Technical Interview

Posted on by
Reply
JTFG book cover

Book now available!

Generally speaking, when you walk into an interview you are at the mercy of the interviewers.  Although you may be given some general information regarding the interview format and probably have an idea about the questions or exercises you may encounter, there are endless possibilities on the topics you may be asked about over a two or three hour session.

As was stated before, any item on your résumé is fair game, so one way to potentially avoid queries on unfamiliar topics is to keep those words off your résumé.  Regardless of what is or isn’t on your résumé, it is quite likely that you will be asked questions pertaining to subjects that are not within your areas of expertise.  Trying to fully eliminate the exposure of certain vulnerabilities is an exercise in futility, but there is one rather effective method to at least attempt to mitigate the risks.

There is an increasing trend in the technical hiring world for employers to request firm evidence of a candidate’s abilities that go beyond what a traditional résumé includes.  For programmers, this typically can be achieved through a code sample.  Front-end designers and developers may be expected to show off some UI or website that they built, and architects may be asked to share documents. Mobile developers may hear this more than any other group, and are routinely asked “Do you have any apps available?” as part of the vetting process.

One way to partially control the content and direction of your interview is to provide interviewers a work sample that will presumably become a point of discussion.  This will turn what could be a technical interrogation into a version of show and tell.  Even if the exchange about your sample only takes fifteen minutes, that is fifteen minutes of the interview where you hopefully will shine, and it is fifteen minutes less time for the interviewers to delve into other topics that are probably less familiar.

To employ this tactic, be sure to make it known at some point early in the process that you have samples of your work for review by request.  A GitHub link at the top of your résumé, a URL to download your mobile app, or a link to sites that you developed are much more graceful than large file attachments.  You can choose to extend an invitation to view these projects as early as your résumé submission, and when scheduling the interview you can express your willingness to discuss the projects in more detail and offer to bring a laptop with samples.

Independently volunteering to show representations of what you have produced will give an employer the impression that you are both willing and able to demonstrate the quality of your work.  That act makes the applicant appear more open and trustworthy than someone who hesitates when asked for some samples.  Recruiters and hiring managers alike will welcome résumé submissions that are accompanied by additional supporting evidence of a candidate’s abilities.

When you enter the interview, you can mention that you brought samples to show if the team is interested in seeing your work.  This will typically be received quite positively and could lead to a deep dive into familiar territory.

This post is an excerpt from the recently released ebook Job Tips For GEEKS: The Job Search, available to purchase from iTunes iBookstore, Amazon, Barnes and Noble, Smashwords, and (soon?) Kobobooks.  A sample from the iBook in PDF format can be found here.

About these ads

Indicators of Talent (and Heuristics) for Software Engineers

Posted on by
6

A recent Hacker News post by a man named Andrew was voted to the front page and received over 50 comments (as of my post).  The post was called Ask HN:  Would you hire me?, and Andrew specified that he was talking about a junior level position.

He provided the following details about himself:

  • 28 years old with a Finance Degree from a non-Ivy league school
  • Spent the last two years living overseas teaching English and learning to code
  • Fairly well versed in html, css, javascript, and PHP

He also included links to his:

  • GitHub – handful of repos, 7 months as a member, pretty active over the last quarter
  • Stack Overflow profile – 521 reputation, top 37% this quarter, 16 badges
  • Blog – Attractive UI, 7 overall posts (a few with some code), with the highlight being details of a Chrome extension he built and demonstrates in a video

Andrew received a fair amount of positive feedback, and not one single poster gave a ‘you are not hirable‘ response.  No CS degree, no professional experience, yet a highly technical audience were either mostly positive and at worst neutral on hiring (considering is more accurate) this potential applicant.  Only a couple responders mentioned looking at the one project he listed, and none referenced the quality of his code samples on his blog or GitHub, so we might assume that no one even bothered to look at his code.  Interesting.

Part of the explanation for the positive response is undoubtedly the makeup of the Hacker News crowd, which does not include a large contingent of HR reps from large companies who control a great deal of the hiring decisions.  Place this resume and story on Monster or Dice, and I expect that Andrew would receive responses from less than a quarter of his viewers.  Possibly less than a tenth.

I admit, if I were to see this candidate’s resume (assuming it reflected the details he put on HN), I would absolutely want to speak to him.  The clients I represent, which are mostly startup and early stage software companies, are more representative of the HN crowd (at least in terms of evaluating engineers) than most larger companies.  And even if I did not have a great opportunity for him today, I would think that a few years down the road he will be someone that I’d want to represent.

What is it about this candidate with no experience and no highly relevant education that gets our attention?  Of the details we have about Andrew, how many could have impacted my decision to speak to him?

When evaluating talent and the decision whether or not to interview a candidate for a software job, I must rely on several attributes that have historically been attached to quality talent that were successful in receiving job offers from my clients.

Let’s break it down.

28 years old with a Finance Degree from a non-Ivy league school - Most readers, including myself, probably didn’t give this any thought.  His degree in finance should indicate some math background, and if he had listed his specific school that would have had an impact.  Although most might be reluctant to mention it, the age demographic is probably a positive based on the industry, as he obviously has some life experience and maturity but will not fall prey to any old dog/new tricks bias.

Spent the last two years living overseas teaching English and learning to code – Teaching any subject to any students is valuable experience for almost any profession, and should indicate some level of communication skills.  The international aspect adds a bit more interesting background than if he were teaching domestically.  Some who chose to speak to Andrew may have been strongly influenced by the oversas aspect, as this could also show some willingness to face risk and change.

Fairly well versed in html, css, javascript, and PHP.  Just getting started with Ruby - His claim of being ‘well versed’ is only a self-assessment, but that could be at least somewhat validated (or invalidated) by anyone taking a look at his blog’s source or GitHub account.  This at least indicates that he is learning technologies that will give him some marketability based on demand for these skills.  We may question Andrew’s choices if he were learning a less popular skill.

GitHub, Stack Overflow, and Blog - For those that make decisions about technical talent, the fact that Andrew has both a GitHub and Stack Overflow account is probably more of an indicator of possible talent than what is actually in the accounts.  Most candidates in my experience don’t have a GitHub/Bitbucket or SO account, but those who do have accounts are historically more successful with my clients than those who don’t.  The attractive blog and few technical posts are yet another indicator, showing some passion as well as the ability to articulate his ideas in writing.

What other details may have led to the decision of HN readers or people like me who would at least want to speak to Andrew?

He reads Hacker News – Even if he isn’t a senior developer, he at least appears to have spent some time in one community where they frequent.

He comes across as modest and doesn’t appear to feel entitled - You don’t see anywhere in Andrew’s post a reference to how awesome he is or how he is ‘kicking CSS’s ass on a daily basis’.  His responses to feedback are very positive, grateful, and polite.  The choice of ‘well versed’ over some other terms that may be linked to overconfidence was wise.  Andrew also will not be accused of sounding entitled to a great dev job, and on the contrary he comes across as someone who knows he has to earn it.  Perhaps that is a function of his lack of a CS degree, but either way he appears to be taking the right approach.

He’s already creating product – Although he is only early on in his tech studies, Andrew has a product on the market that you can find in the Chrome Web Store that you can download.  There are developers with 20 years of experience that haven’t built any of their own tools or products yet, but this guy is two years in and has that mindset.  Some may question how great (or even good) a product someone at this level of experience could build, but the desire to produce and distribute a tool is something that perhaps can’t be taught.

Note:  Other indicators I use regularly include:

  • Past employers – Some companies frankly have a higher standard of hiring
  • Technical hobbies – Arduino, build robots, or create things at home
  • Speaking or writing – Presentations and publications are usually strong indicators
  • Tool choice – What blogging platform or operating system you run at home
  • User group and meetup – Shows interest and passion

Conclusion:  Hiring managers and recruiters are making quick decisions to interview and consider candidates, and as demonstrated by this HN post it seems that there are several recognized indicators of possible talent.  For job seekers, you may want to display links to your accounts prominently, and highlight details such as independent product development.

Of course, these indicators are not perfect.  I, too, have a GitHub and Stack Overflow account and a blog that covers technology (and I even run one of the best Java Users’ Groups in the world) – but I don’t write code.  Readers of HN should not hire me.

Discuss here or on Hacker News.

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

Why You Make Less Money

Posted on by
29

Have you ever had a conversation with a fellow technologist that you felt wasn’t quite at your skill level, and at some point you discovered that she/he makes $20,000 more than you do?  $50,000?  As someone who has had a great deal of access to the salary and compensation details for thousands of software engineers over many years, I can report that there can be significant variation in salary between technologists with almost indistinguishable skills and qualifications.  This may not be news to some, but some of the reasons might not be obvious to professionals in the field, particularly if someone has only been exposed to a small subset of industries or companies.  Many of the explanations are somewhat unique to this industry or at the very least more prevalent in the software world.  Regardless of whether or not money is a primary motivator in your career, it is still useful to understand why others may be earning more (and what you can do to earn more).

What are some possible explanations as to why someone equally or less-qualified makes more money?

  • Public image and intangibles - An average technologist may be compensated above more productive co-workers if there is some advantage that the company sees in that person’s employment.  Community influencers such as open source project leads, conference organizers, meetup/user group leaders, speakers, and authors may all fall into this category.  In business this is the concept of goodwill, where an asset has a higher value due to an intangible.  Google’s high profile hires of  James Gosling and Ray Kurzweil and Dropbox’s hiring of Guido van Rossum came with a certain level of goodwill bundled.  On a local level, a company may believe that hiring the local Python group leader could make hiring Python pros easier and less expensive, which may justify a higher salary independent of the developer’s quality or production.  Regulars on the conference speaker circuit can ask for a premium simply based on the PR provided every time their bio is published on an event website.
  • Negotiations and raises - Software professionals are often stereotyped as unskilled or uncomfortable in situations where they are negotiating or asking for raises and perks.  This first requires the courage to ask for more (as a raise or starting as a new hire), and then the knowledge and skill to ask effectively.  As a recruiter I typically handle salary discussions for my candidates, and I know that for most engineers that particular service is considered most valuable.  A difference of even a few thousand dollars as a starting salary can dramatically alter your lifelong earnings.  Remember that this number is regularly used as the basis for bonuses, raises, and most importantly it has some bearing on salary at your next job.  Think of starting salary as the principal level for compound interest.
  • Market knowledge - Remember that conversation alluded to in the first line of this article?  If you had three or four similar interactions within a year, hopefully you noticed a pattern and it seems your friends know something that you don’t.  Many engineers aren’t even aware that they are paid below market rate because they just trust that they are fairly compensated and have no reason to investigate further.  I have had conversations with experienced and well-qualified developers who are floored when they learn that they have been paid 20-30% below market rate for many years.  Know what you are worth.
  • Self-promotion - Even if the high skill level is there, many technologists are either unable to properly express their own expertise and accomplishments or feel awkward tooting their own horn.  The ability to market yourself often starts with a powerful résumé and a confident interview presence when trying to maximize salary at a new job.  When staying with your employer, self-promotion requires the savvy to make your accomplishments known without looking like a braggart.
  • Consulting differential (both independent and staff) - Developers that are independent consultants charge clients a premium to account for expected frictional unemployment and to address the fact that a temporary employer typically will not make any real investment in the career of a temporary employee.  It is rare to see independent consultants sent to conferences or trainings by their clients, and independents do not always get the most desired projects.  Independents are also on the hook for their own benefits, retirement savings, etc.  Salaried employees of consulting firms are also often paid above other similarly qualified professionals, as it is easy to measure a consultant’s contribution to the firm’s net revenues based on bill rates, billable hours, and their compensation package.  There may also be regular travel or variable commute that tends to inflate salaries.  Salaried consultants who know their bill rate, utilization, and total compensation package have a distinct advantage when trying to justify their value (and salary) to an organization.
  • Profit vs Cost Centers - Similar to consulting, companies that use technology as their main source of revenue tend to pay higher than firms where it is considered a cost center.  Building software products that will be sold usually results in higher salaries than building systems for internal use.  There are some major exceptions, but those tend to be specialized to industries where technology utilization is a key differentiator in the performance of the firm’s primary business interests (trading systems come to mind).
  • Rare skill - The premium paid for even one single rare skill among many common skills can be substantial.  When a new language, framework, product, or platform is hyped as the ‘next big thing’ and adoption begins, even junior level talent with that skill can earn above more generally qualified individuals.  This is simple supply and demand for a scarce resource.  In years past the premium was greater for rare skills, as companies today seem more confident in their ability to train an existing resource than to hire someone new and much more expensive.
  • Time expectations – Some employers pay a premium because of the high expectations they place on hires.  Unless you have some vested interest in the success of the company (stock, profit sharing), a 70 hour work week is probably unacceptable unless you are being compensated accordingly for that level of commitment.  Positions that require employees to be on-call are also commonly paid above market.  Work/life balance has a price, and some are willing to sell.
  • Long tenures at big companies – Many large organizations have systems of pre-determined fixed raises and regular bonus or vacation increases for certain milestones.  The hire’s value to the company increases over time as they become highly specialized in a certain environment, and the concept of golden handcuffs is born.  The downside of this for the employee is that it often leads to compensation well above true market rates, which makes it nearly impossible to find new employment at a lateral compensation rate.  When these types are victims of a layoff, the result is brutal.
  • Location – No explanation needed, I hope.

Conversely, here are a couple explanations as to why someone might make less.

  • Startups – Startups often exchange equity for cash compensation.  These employees are often earning less for the opportunity to receive a big payout.  Candidates negotiating with startups must place their own figures on the value of the equity, which is a difficult task.  Startup compensation today is much more competitive with large companies than it once was, at least in my experience.
  • Benefits, work/life balance - Since most professionals refer to compensation in terms of cash paid, employees that receive significant value in their benefits and perks may be mistakenly considered underpaid.  Generous paid time-off, tuition reimbursement, and childcare can be major expenses that are covered by some employers and often not included in discussions. 
  • Experience value – The opportunity to work for certain companies, to learn a valuable skill, or to be on a highly-regarded team is a reason that many engineers may sacrifice some salary, and shops that provide that ability may leverage that during negotiations.  Many developers are entirely comfortable with accepting compensation below market as a trade-off for the positive effect on their career and marketability.

Conclusion:

If the topic of compensation comes up with other technologists, consider that there may be several explanations and hidden factors for the disparity between numbers.  When exploring new opportunities, keep in mind that the amount of your offer is not solely based on your skill level relative to others or the value the company feels you will provide.  In situations where several of these explanations apply simultaneously, the numbers become even more skewed.

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

Enterprisey Developers, Acronyms, and Discrimination

Posted on by
6

Java eyechart

Over the past few years my clientele shifted from a mix of mostly mid-market companies and a few startups to almost entirely startups, and that shift has resulted in a wider palette of languages requested by clients.  Where my business was about 95% Java for the first 10+ years of my career, today it is closer to 25%.  As I’ve written before, my business veered naturally from a pure Java focus when a considerable amount of the Java talent I have represented in years past started to migrate and show interest in diverse languages and ecosystems.

Unlike the boom periods for startups in the past, it appears that today’s startup is much less likely to choose Java as the primary development platform.  Many developers who did Java work for startups in the mid 2000′s sought higher ground in the late part of the decade when small shops took a hit, and found themselves working for large companies and more corporate environments.

Flash forward to the past few years and the resurgence of startups.  Many of those engineers who took shelter in the larger firms are now interested in establishing themselves once again as a major contributor on a small team in a startup, and when I have represented some of these highly qualified developers to startups now, I’ve been met with the feedback ‘The candidate’s résumé appears too enterprisey‘.  As an aside, I don’t get that response nearly as often for Java engineers that stayed with small companies.

The enterprisey label, in my experience, seems to be used in two situations that can often (but not always) go hand-in-hand.  First, enterprisey is often used to describe candidates that come from large development shops regardless of the languages used (although Java and .Net platforms are the norm), where the bias is that the development culture and the broader company culture make that candidate less likely to succeed in the startup.  This is the result of preconceptions surrounding development methodology, possible unnecessary complexity in applications, a slower release schedule, or the impression that developers in these larger environments are sheltered from tasks related to data, devops, sysadmin, and QA that are frequently handled by developers at startups.  The label may be applied liberally to virtually any candidate coming from a company larger than the hiring firm.

The second common enterprisey tag is used on any developer using Java or .Net regardless of the employer size, due to the predominant viewpoint that other language communities have developed regarding Java/.Net being wrought with and plagued by dozens of frameworks and bloated stacks.  As someone who sees thousands of résumés a year, it is clear that résumés of Java and .Net developers are often significantly longer than those of developers in other languages, but there could be several factors at play there beyond just the number of potential bloat items (insert Java = verbose joke here).  At a distance, the résumés of Java developers can resemble an eye chart, with acronyms outnumbering actual words.  One hiring manager of a Scala shop provided this gem:

“The laundry list of legacy enterprise technologies (JMS, JMX, etc.) doesn’t do anything for me.”

The word ‘legacy’ seems particularly cruel there.

Sadly, many of those making hiring decisions in these startups are quick to dismiss a highly-skilled talent simply because of their experience working for a larger company or their primary language being in the Java or .Net worlds.  Whereas an interest in, say, functional languages is now often used by startups as an indicator of ability, the prolonged use of Java or .Net at a large firm can be a detriment when applying for work in any other language or polyglot environments.

So how can engineers labeled ‘enterprisey’ escape that bias and be accepted by  smaller shops with different languages?

Résumé and bio de-enterprisification – That’s not a word (yet), but the concept would be to go back and make sure your résumé/bio/LinkedIn profile/etc. doesn’t read like a corporate Buzzword Bingo card.  Eliminate or modify anything that may appear steeped in bureaucratic process and procedure, and be wary of any items that can be perceived as indicative of a glacial development pace.  References to project length and time between releases should typically be avoided.  Emphasize new development over maintenance tasks, and accomplishments over process.  Listing too many tools, frameworks, and specifications will often work against you and may be considered an indicator of your dependence upon them.  Shortening the résumé is almost always the way to go here, and three + page résumés generally smell of enterpriseyness.

Develop other language credibility – Any code that you can point to that does not run the risk of being labeled enterprisey is better than nothing.  As stated before, some startups perceive functional programming interest as a marker for ability, so even an implementation of a typical interview exercise in a functional language (or one different from your primary) has value.  Provide links to this code on your résumé and reference any personal projects that are applicable.

Stop calling yourself ‘LANGUAGE Developer’ – I do it too (all the time), but you should not.  Use whatever you feel is appropriate – Software Engineer, Programmer, Developer, Geek – but stop inserting a language when describing yourself on paper or verbally.  And perhaps more importantly, stop thinking of yourself as a LANGUAGE Developer.  Sometimes you may need to dumb it down so the clueless recruiter will find you, but try to minimize those instances the best you can (and do you really want that recruiter to find you anyway?).

Express your outside interests – Just because you get paid by some insurance company to write Java/.Net apps all day doesn’t mean that is who you are.  If you are exploring other languages through books, conferences, and self-study, make that known in whatever way may be discovered during your job search (résumé, blog, social media, etc.).  Hobbies like robotics, Raspberry Pi, and Arduino are probably unrelated to your job but not necessarily unrelated to your career.  Any technical interests beyond the primary function of your job demonstrate at least some level of versatility and the ability to adapt outside of your enterprisey 9 to 5.

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

A Guide To Lifelong Employability For Tech Pros

Posted on by
1

There seem to be a rash of “Am I Unemployable?” posts and comments lately on sites that I frequent, and after reading details the answer in my head is usually “Not quite, but sounds like you are getting there“.  In other words, someone will hire you for something, but many who assess themselves as unemployable are going to feel both underpaid and undervalued when they finally find work.

How does a technology professional go from being consistently and happily employed for a number of years, only to find himself/herself suddenly unemployable?  Better yet, what are the key differences between someone who spends months on a job search and someone who can unexpectedly lose a job Friday and start a new one the following Monday?

How do certain people get job offers without having to even interview?

It isn’t simply about skill, although that is obviously a factor.  Even pros that are highly productive and well-regarded in some circles can encounter challenges in today’s hiring environment.  It’s about creating relationships and developing your reputation/visibility.

In my experience, pros that are always in demand and rarely (if ever) unemployed seem to share certain sets of habits, and while some of the material below is Career 101 there are some that you probably never considered.  As a longtime user group leader and recruiter of software engineers for the past 15 years, I see this first hand on a daily basis.  Let’s start with the habits that are the least obvious and progress to some that are more widely practiced.

Interview - How often do you interview when you are not actively looking for a job?  For most the answer is never, and I’d encourage you to take at least a couple interviews a year.  Going on the occasional interview can serve two purposes.  First, they are a way to make new contacts and keep your name in the minds of potential employers, with the added benefit that these same interviewers may be working at new companies in a year or two.  One interview could lead to an ‘in’ with four or five companies down the road.  Second, it is the only way to keep interview skills sharp.  Interview practice is best done live without a net, and failing the audition for a job you truly wanted is often attributed to rusty interview chops.  Even a simple informational interview request (made by you) is an effective and creative way to make first contact with a potential employer.

Know when to leave your job – Without question, the group having the toughest time finding work are unemployed with say ten+ years at the same company, and a close second would be employed workers with that same ten year tenure.  For anyone about to scream ‘ageism‘ please hold that thought, as older technologists that have made smart moves do not typically have this issue.  I would add that older engineers who possess the habits outlined here are the group being hired without interviews.  There are always exceptions, but tech pros can stagnate quicker than those in other industries due to the speed of change in technology.

The definition of job hopping has morphed over the past fifteen years, and it is now understood that semi-regular movement is expected and accepted.  Where other industries may interpret multiple employers as a symptom of disloyalty, in the software world a pattern of positive (moving to something better) job changes is often more indicative of a highly desirable candidate.  Conversely, someone who has remained at a company for many years may be viewed by employers as loyal to a fault and potentially unambitious.  If this person has solid skills, why has no company picked him/her up yet?  Changing jobs before stagnating is critical to overall employability, and how quickly you stagnate will vary based primarily on your employer’s choices, your own ability to recognize that stagnation is happening, and your desire to not let it happen.

Make ‘future marketability’ a primary criterion when choosing jobs or projects – Carefully consider how a new position will impact your ability to find work later in your career and use that as one of your key incentives when evaluating opportunities.  Details about your roles and responsibilities as well as the company’s technology choices and reputation in the industry are all potential factors.  Does the company tend to use proprietary languages and frameworks that will not be useful later in your career?  How will this look on my résumé?  Many candidates today are choosing jobs or projects based on an opportunity to learn a new skill, and for this they are usually willing to sacrifice some other criteria.

Reach out to others in the community (not coworkers) – How many times have you sent an unsolicited email to someone in your field that you don’t know?  “Congrats on your new release, product looks great!” or “Saw that you open sourced, look forward to checking it out” as an email or a tweet is an effective way to create a positive impression with a person or organization.  Twitter is great as a public acknowledgment tool, and the character limit can actually be advantageous (no babbling).  If you stumble on an article about a local company doing something interesting, there is much to be gained by a 140 character pat on the back. This is essentially networking without the investment of time.

Lunch with others (again, not coworkers) – You have to eat lunch anyway, so how about inviting someone you don’t know that well to lunch?  Perhaps include a few people that share some common technology interest and turn it into a small roundtable discussion.  Meeting with other tech pros outside an interview or meetup environment enables everyone to let their guard down, which leads to honest discussions about the experience of working at a company that you may consider in the future.  It’s also an opportunity to learn about what technologies and tools are being used by other local shops.

Public speaking – This is an effective way to get attention as an authority in a subject matter, even on a local level.  Preparing a presentation can be time consuming, but generally a wise investment.  Even speaking to a somewhat small group once a year can help build your reputation.

Attend a conference or group meeting – This isn’t to be confused with going to every single meeting for every group in your area.  Even getting to an event quarterly keeps you on the radar of others.  Make an appearance just to show your face and say hi to a few people.

Reading and writing about technology – One could debate whether reading or writing has more value, but some combination of the two is likely the best formula.  If you don’t know what to read, follow some peers and a few respected pros from your field on Twitter, LinkedIn or Google+, and make a point to read at least a few hours a week.  As for writing, even just making comments and discussing articles has some value, with perhaps more value (for job hunting purposes) in places like Stack Overflow or Hacker News where your comments are scored and can be quantified.  Creating your own body of written work should improve your understanding of a topic, demonstrate your ability to articulate that topic, and heighten your standing within the community.

Build a personal code repo – Many in the industry balk at this due to the time required, but having some code portfolio seems to be on the rise as an expectation hiring firms have for many senior level candidates.  If the code you wrote at work is not available for demonstration during interviews, working on a personal project is more critical.

Conclusion
At first glance, this list may appear overwhelming, and I’m certain some readers will point to time constraints and the fact that they are working 60 hour weeks already.  Some of these recommendations take considerable time, but at least a few require very little commitment.  Employ a few of these tactics and hopefully you will never suffer through a prolonged job search again.

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

The Stigma of Tech Certifications (and their real value)

Posted on by
7

Every so often I will receive a résumé from a software engineer that includes a list of technical certifications.  These days most candidates tend to have none listed, but over the years I’ve seen some include anywhere from one or two certs up to ten or more certs, and it seems the number of companies willing to certify tech professionals has continued to grow.  Vendors like IBM and Oracle each offer over 100 certifications, while Brainbench lists almost 30 tests on Java topics alone.  At prices ranging from the $50 neighborhood up to $200 and more, the technology certification industry seems quite lucrative for the testing companies.  But what is it all about for engineers?  What (if any) value do certifications have for your marketability, and could having a certification potentially result in the opposite of the intended effect and actually hurt your chances of being hired?

When do certifications help?

There are some situations when certifications are absolutely helpful, as is the case for job seekers in certain industries that generally require a specific cert.  A certification that was achieved through some relatively intense training (and not just a single online test) will also usually have value, much like a four year degree tends to be valued above most training programs.  If a technology is very new and having skill with it is incredibly rare, a certification is one way to demonstrate at least some level of qualification that others probably will not have.

When and why can certifications actually hurt?

Professionals that have very little industry experience but possess multiple certifications usually will get a double take from hiring managers and recruiters.  These junior candidates are perceived as trying to substitute certifications for an intimate knowledge that is gained through using the technology regularly, and more senior level talent will note that the ability to pass a test does not always indicate the ability to code.  Many of these job seekers would be much better off spending their time developing a portfolio of code to show prospective employers.

Experienced candidates with multiple certifications may have some stigma attached to them due to their decision to both pursue them and then to subsequently list them.  Some recruiters or managers may feel that these professionals are trying to compensate for having little depth in a technology or a lack of real-world accomplishments, and that the candidate wrongly assumes that a cert shows otherwise.  Some that evaluate talent might get the impression that the candidate obtains certs in order to feel validated by (or even superior to) their peers, and that the cert is more driven by ego than a desire to learn.  Lastly, there will be some who feel that over-certified technologists are ‘suckers’ that should have spent their (or the company’s) money and time more wisely.

The greatest value of certifications

Having spoken to hundreds of programmers certified in any number of technologies, I found that the majority claimed to find more value in the process of studying and test preparation than with the accomplishment of passing the test and getting certified.  Pursuing a certification is one way to learn a new skill or to get back to the basics of a skill you already have.  Certification tests are a great form of motivation to those that take them, due to the fact that there is:

  • a time deadline – If you decide you want to learn a technology in your spare time, you probably don’t associate any particular date in mind for learning milestones.  Certs are often scheduled for a specific date, which motivates the test taker to study right away.
  • a time cost – Preparing for a test like this comes at the expense of other things in your life, so most that pursue certs understand the time investment required.
  • a monetary cost – Shelling out $50 to $200 of your own money is an additional motivator.  It’s not that much for most in the industry, but it is a lot to pay to fail a test.
  • a risk of failure – If you are studying with others for a test, pride will also be motivating.

As the pursuit of certification seems to be the greatest value, keep this simple fact in mind.

Just because you get a certification doesn’t mean you have to list it on your résumé.

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

Tips To Overcome Ageism In Hiring As a Software Professional

Posted on by
1

As a recruiter who is about to celebrate (as if recruiters celebrate such a thing) mark fifteen years in the technology industry, I am starting to see that many of the contacts I made back in the late 90′s are now having some concerns about ageism during a job search.  Any failed interview for older software professionals may cause a raised gray eyebrow and a thought that age and not their skill was a factor in the decision.  Companies that freely apply catchall terms such as “overqualified“ or “not a cultural fit” in a rejection only serve to cloud the engineer’s mind and cause him/her to wonder if these are just the politically correct or legal code words to signify “You’re too old for us”.

Much has been written about older professionals being dogged by myths surrounding work effort, production, energy, and whether employees with families are more likely to work less.  Start-ups are often portrayed as testosterone-and/or-alcohol-fueled code marathons only welcome to young males, which hurts the many start-ups that are not. But even hiring managers who have read studies and evidence that debunks these myths may still be guilty of judging candidates based on perception, so another blog post about why all companies (start-up or mature) should consider hiring older workers may not be helpful.  The goal of this post is to help these more experienced candidates maximize their chances of being considered for jobs, and to make sure they are evaluated based on their skills alone during interviews.

Just as you would find at a nightclub, ageism starts with the person at the door.  During a job search, the doorman is the person screening resumes.  Therefore, the resume is the first item of consideration when trying to combat the problem.  Let’s look at some common resume mistakes that expose candidates to ageism.

Resume Tips

Mistake #1 – Your resume does not need to include every position you have had in your life, and it doesn’t even need to list every position you have held in your field.  This is by far the most common way that candidates expose themselves to possible ageism.  If you have been in the industry for over twenty years, the work you did at the beginning of your career is hopefully quite different than what you are doing now.  Trim down your resume to a manageable size by eliminating jobs that are the most dated and least relevant.  Although there is nothing wrong with removing outdated experience, add the phrase ‘Additional experience provided upon request‘ if you feel it necessary.

Mistake #2 - The ‘Education’ section of a resume does not need to include graduation dates.  The graduation date is arguably the easiest and most accurate way to put an age number on a candidate, using the formula

Age = (current year - graduation year) + 22

By including the date of graduation you are simply making it easier for them to discriminate.  When hiring managers or recruiters see dates that seem like the distant past, they will do the math in their head subconsciously and label you with a number.  “This guy graduated in ’81?  That makes him, what…54?”  Don’t put the date on the resume if you feel that your age could be used against you.  This isn’t dishonesty (putting an incorrect year would be dishonest).  There are several details about you that are not listed on your resume, and graduation date should not be required.

Without a graduation date, the formula for quickly approximating age generally becomes

Age = (current year - year of hire at earliest job listed) + 22

If you consider the point listed in Mistake #1 and you decide not to list early and irrelevant job(s) right out of school, and you also do not list your graduation date, you can potentially take years off of your perceived age.

Mistake #3 – Your resume does not need to include every technology that you have ever used.  A resume of a very senior engineer could potentially contain an impressive and lengthy list of technologies in the skills section if he/she were to offer a comprehensive inventory of the various hardware, tools, languages, operating systems, databases, protocols, etc. that have been used during the span of their career.

Keep in mind that certain technologies or buzzwords are likely to trigger a visceral reaction based either on the age of the technology itself or how that technology is generally viewed by the industry.  Languages that are out of favor in today’s programming culture are probably the most common issue.  To have experience over a long period of time and with several tools is undoubtedly valuable, but unless a technology has significant relevance to the jobs being sought the risk of including these details may outweigh the benefits.

Interviews

If you followed the advice above regarding your resume, the next step will be interviews.  In interviews, you want to make sure not to play into any of the myths or the fears that are commonly associated with the hiring of older workers.  Below is a list containing many of the most stereotypical generalizations or assumptions common to ageism and how to best avoid them.

Older hires will not be able to put in hours.  The availability issue is more closely associated with start-ups that may require more office time, and this perception is amplified when a start-up is staffed primarily with young, childless, and single employees.  Being honest about your desire for work/life balance is best for all parties involved, but don’t let the interviewers assume that because of your age or family situation that you are only able to work 40 hours if you are indeed open to more.  Clarify the amount of time you are willing to commit to working in or out of the office to prevent false assumptions.

Older hires will retire soon.  Answering the “Where do you see yourself in five years?” with “Retired in Florida” is probably not the best answer, but honesty about your expectations is always best.  Don’t let the employer assume that you are planning to retire soon if that is not the case.  If you can not afford to retire in the near future, it may be helpful to let a hiring manager know that fact in order to allay this potential fear.  The amount of time technology professionals of any age spend at any one company is lower than it used to be, so having an older employee on board for three to five years could have value to the company that is not much different than the average tenure of a young hire.

Older hires have low energy or are less productive.  Older candidates should be more aware of their perceived energy level and body language during interviews.  It’s good advice to job seekers of all ages to try to schedule interviews during the hours of the day that you feel you perform best and are most alert.  Be sure you are well rested, fed, and look alive.

Older hires have dated or irrelevant experience.  Eliminating some of the older experience on the resume helps showcase current skills while avoiding the appearance of stagnation.  When giving anecdotal answers, try to focus your material first on what is most relevant and most recent.  Referring to projects that ended thirty years ago is not advised unless the lesson learned was incredibly valuable.

Older engineers only want to manage.  If you have been in leadership roles but are looking for something more hands-on, you must make that very clear during interviews and in initial correspondence when applying for a job.  The assumption will always be that employees expect more responsibility as their career progresses, but many software engineers simply want to stay in the code and are not interested in managing.  Don’t let your interviewer assume that you want to manage if you do not.  A willingness to mentor employees while also being hands-on will add to your potential value.

Older engineers are less teachable and may have strongly reinforced bad habits.  This line of thinking is amplified if the candidate has been in the same professional environment for many years, and the suspicion is that engineers become overly accustomed to a single way of working and won’t easily adapt to new ways.  If you have had the same employer for a long time, try to emphasize any major changes that took place during your tenure and how you were forced to learn new things or leave your comfort zone.  If you were an agent for change, be sure to bring that fact up during conversation.

Older hires will not be a culture fit.  Culture fit is something older engineers probably didn’t hear much about in the beginning of their career, and ‘not a fit’ can be used as a blanket term for rejecting candidates without having to give a specific reason (which potentially exposes a company to discrimination lawsuits).  Try to learn about company culture before the interview so you can at least be aware of their values and the image they want to convey, even if that image is not really who they are.

Career advice

Stay relevant.  Keep up to speed on what technologies are popular with the cool kids, even if you do not use them on the job.  If you have time to spend a few hours and tinker, that experience may pay off in your next job search.  Knowing what others in the industry are doing is as simple as reading articles every few weeks.

Never stagnate.  Older engineers that overstay their welcome at a company will have an incredibly difficult time finding work if a job search becomes necessary.  When senior engineers are the victim of layoffs after being employed for 15 or more years, a long and difficult job search is often the result.  Being stuck in the same role with the same technologies at the same company for a long stretch could become comfortable, but it will not be an asset when changing employers.  Your first loyalty should be to yourself and your career, and not to your company.  In my experience, older professionals that have not stayed at any job for a long stretch (>10 years) have the most prospects.

Keep a positive attitude.  Many engineers are quick to actually dismiss themselves as candidates due to age, and they don’t even bother applying to companies they feel will reject them based on ageism.  Other candidates have self-defeating attitudes about their plight or their perceived inability to improve their situation.  Do not fear rejection, and learn from mistakes made during job searches.

Share your knowledge.  Engineers that have a reputation as teachers, advisers, and mentors will always have an easier time finding work.  Whether you write technical blog posts, present to user groups, or do informal talks during lunch, you will develop a reputation as someone who uses your experience to make your teammates better.  Think of your experience as a positive asset for a new employer, and be known as someone who is always willing to guide younger technologists.

Be open to non-traditional employment options.  Job trends and careers have changed drastically over the past 30 years, and the traditional ‘graduate college → get job → retire with pension‘ progression isn’t realistic today.  If you haven’t already, give consideration to contract/consulting work, contract-to-hire or alternative employment options.  Older professionals may find that ageism is less common in temporary hire situations.

What If We ______ Like We Hire Programmers – What Questions Are Appropriate?

Posted on by
2

Programmers often experience a high degree of frustration during the interview process, and one primary source of annoyance is how the programmer perceives the line of questioning or exercises.  In a buyer’s market where supply exceeds demand, hiring managers will often be a bit more selective in evaluating candidates, and talent evaluators may request or require more specific skill-sets than they would if the talent pool were deeper.  These tactics are short-sighted but deemed necessary in a crunch.

I recently stumbled on two articles with an identical theme.  “If Carpenters Were Hired Like Programmers” was written in 2004, and “What If Cars Were Rented Like We Hire Programmers” was posted very recently.  The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters).  The comments sections on Reddit and Hacker News are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme.  No analogy is perfect.

There are surely companies that are ‘doing it wrong’ and asking questions that will reveal little about a candidate’s potential as an employee, but I’m getting the sense that many candidates are starting to claim that even appropriate lines of questioning and requests are now somehow inappropriate.  More importantly, it appears that candidates may not understand or appreciate the true value of certain questions or tasks.

To continue the carpenter analogy, let’s look at the types of questions or tasks that would be both useful and appropriate in evaluating either a carpenter or a programmer (or anyone that builds things) for potential employment.

  • Overall experience and training – No one will should argue these.
  • Experience specifically relevant to the project at hand – This is where we may first see some candidates crying foul, particularly if the relevancy of the experience is judged predominantly by the level of experience with very specific tools.  Learning a new programming language is probably not equivalent to learning how to use a different brand of saw, but engineers can sometimes be overconfident about the amount of time required to become productive with a new technology.  The relevancy of experience factors into a hiring decision most when project delivery is valued over long-term employee development.
  • Answer some questions about your craft – When hiring managers ask questions, candidates should keep in mind that there can be a few reasons why a question is asked.  Obviously, one objective may be to truly find out if you know the answer.  However, sometimes the interviewer asks a difficult question simply to see how you may react to pressure.  Another possibility is that the interviewer wants to reveal if you are the type of person who may confidently give a wrong answer to try and fool the interviewer, if you are more likely to admit what you do not know, and to evaluate your resourcefulness by how you would research a problem with an unknown answer.  A genuinely, laugh-out-loud stupid question may be asked to see how well you may deal with frustration with a co-worker or an unruly customer.  Lastly, the interviewer may simply want to see your method of approaching a tough question and breaking it down.  Candidates that are quick to complain about being asked seemingly minute or irrelevant details often overlook the true purpose behind these exercises.
  • Design something – I’m always amazed when candidates call me in a state of shock after being asked to do a whiteboard exercise in an interview, as if these types of requests were either unfair, insulting, or a ‘gotcha’ technique.  Anyone who builds things should be somewhat comfortable (or at least willing) to either visually depict a past design or attempt to design a quick solution to a problem on the spot.
  • Show us how you work alone – Assigning a short task for someone to complete either in an interview setting or at home before/after an interview is absolutely an appropriate request, which candidates can choose to accept or deny.  It is both only an opportunity to demonstrate skills and to further express your interest in the position by being willing to invest time.  Providing a bit more than the minimum requested solution is a valuable method to differentiate yourself from other candidates.
  • Let’s see how you work with a team – As candidates are often hired to build things collaboratively, a short pairing exercise or a group problem-solving activity could be the best way to efficiently evaluate how well one plays with others.
  • Show us some samples – Professionals who build things have the unique interviewing advantage of actually showing something physical that they have built.  A carpenter bringing a piece of furniture to an interview should be no different than an engineer offering a past code sample.  Companies are increasingly using past code as an evaluation tool.
  • References – At some point in the process of evaluating talent, asking for references is a given.  Being unwilling or unable to provide references can make someone unemployable, even if all other tasks are met.

If you go back and reread the articles about the carpenter and rental car interviews, you may have a new perspective on the reasons some questions may be asked.  Think back on some interviews that you have had, and consider whether it’s possible that the interviewer had ulterior motives.  It’s not always about simply knowing an answer.

If you found this article useful, you might find my ebook Job Tips For GEEKS: The Job Search very helpful.  You can also follow Job Tips For Geeks on Google+, Facebook, and Twitter.

Interview Prep For Geeks

Posted on by
2

Failing an interview due to a lack of qualifications is forgivable, but it is tragic when highly qualified candidates do not get an offer due to being unprepared. With the amount of information freely available today, the time and effort required to prepare for an interview is extremely low and a relatively small investment to make in your career.

Typically a candidate will have at least two or three days advance notice to do some research and prepare for any interview. Here is a checklist of things for technologists to investigate to be sure you are ready for what will come your way.

  • Company intel – Learn as much as you can about the company, and try to have at least one minute of material memorized to answer the “What do you know about us?” question. Be prepared to present on the company history, the products or services the company provides, details on the business model, and the industry itself (competitors, health of the market, etc.). For technologists, the ability to give an eloquent response to the “Describe what the company does” question is a huge asset that should not be overlooked and could be a significant factor in your success. Gathering substantial information on a young company’s funding status or finances might be difficult, but there will generally be at least some info in press releases from venture partners.
  • Tech environment – Get specific details about the technical environment by doing some basic web research, reviewing any available job descriptions or LinkedIn employee profiles, and talking to your recruiter or any appropriate company contacts you may have. What frameworks, languages, databases, operating systems, and hardware are they using? Even if the details aren’t all entirely relevant to your interview, it will show that you are taking this process seriously. Look up any buzzwords or acronyms you don’t recognize so you can at least discover if you may have experience with a related item (“I haven’t worked with ______, but I’m familiar with ________ which appears to be a similar tool/language”).
  • Tech moves – Knowing the company’s current tech details is valuable, but knowing about some of the company’s technical history will show great initiative while also providing potential insight into how the company views technology and makes tech decisions. Has the company made significant changes to their stack, and if so, why? Are they heavily invested in open source? Do they seem closely linked to a specific vendor? Does the company have an engineering blog or a company GitHub account for you to explore that might contain this information?
  • Interviewer intel – Insight into the technical background and past employers of the individual(s) you will meet is a great advantage, as you may have some similar history. Personal GitHub or Twitter accounts? Technical blog posts? A LinkedIn or web search of the interviewer(s) might turn up some helpful details to use during the interview, as long as you use the info wisely. Showing that you did some research displays initiative, as long as you respect personal space.
  • Confirm the basics – Where are you going and who should you ask for when you get there? Who are you meeting with and what is his/her/their role in the company? What is the preferred dress code? (NOTE: Some companies actually ask that candidates dress more casual, so be sure to ask)
  • Prepare questions and anecdotes – Most interviews will provide you with at least a brief opportunity to ask questions. Although you ideally want to have these memorized, it is generally a good idea to have some questions listed so you don’t forget them under possible duress. There are also some fairly standard questions in the “tell me about a time when…” family which are commonly answered with anecdotes. Give some thought to past challenges, failures, and successes, and especially what lessons you learned from each project.
  • Documents – Some companies may ask you to fill out an application and other relevant documents before the interview. Find out if this is the case and if so get those completed before interview day. Make sure to print out at least three copies of your resume and one copy of your list of questions. Think about who you will list as references if asked on the application, and have their info (name, email) available.

Keep in mind that making a solid impression in an interview is something that can make a huge impact down the road, whether or not you get the job. Interviewers remember candidates who impressed, and they absolutely will remember those who crashed and burned as well. Do your homework and take interviews seriously, not just for the sake of getting this job but for opportunities later in your career.

TALK! It’s An Interview, Not An Interrogation

Posted on by
1

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 Facebook, Twitter, or Google+.