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.
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.
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.
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.
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
willshould 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.
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.
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?
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.
It’s been a week since I posted “Advice From A JUG Leader – Learn a Different Language” and it seems to have ruffled at least a few feathers in the Java community. As the article has been re-posted and bounced around on Twitter, I have had some opportunity to interact with some members of the Java community who have strong feelings about the content. None have called for my death, and the debate has been almost entirely polite thus far.
I think and sincerely hope that the Java community understands that the impetus for writing this article was an observation that many in the Java community are simply not aware of the trends in the industry, and by the time those trends become standards it is too late. These are the people that, if the train does come, never heard it approaching. My purpose is not to predict or encourage the demise of Java, as that should not and will not happen. The Java community is deeply loyal to Java, perhaps even to a fault, and I hope these articles serve as a wake-up call that the most important loyalty should be to your career as a software professional and to neither an employer or language.
I have noticed from these mini-debates is that defenders of Java, at least in my interactions so far, seem to primarily be highly experienced developers that perhaps have the most invested in Java. As I mentioned in my original article, I don’t expect known Java experts to feel any changes. At least a few of the comments seem to come off as rants against youth (“go play your Xbox“?) and startup culture and not a defense of the language’s health itself. I haven’t seen the younger generation of Java pros, but I know they are out there. I don’t seem to see Java enthusiasts attacking faults in the alternative languages or praising Java for a superior feature set.
Some comments seem to admit that Java has some shortcomings just like other languages, but it’s what we have for now. That is good enough for some people – particularly those that have been in Java for a long time – but not good enough for many developers who want to work with the best available. The arguments so far have been, in no particular order:
Argument #1 – Don’t Use Alternative Languages Because The Languages are Unproven, and/or Only Startups Use Alternative Languages
“And, don’t forget, 70% of startups will fail within the first ten years. So, I’m not inclined to base my decisions on the faulty and unproven ability of start-ups to make sound business decisions for themselves.” – Comment from TSS reader, click for full context
Some of the languages are more proven than others obviously, but we can’t ignore the fairly regular news regarding established firms transitioning to alternative languages and platforms or taking a polyglot approach. I would hardly call companies like Twitter, YouTube, foursquare, LinkedIn and Google immature startups at this point. If you are going to argue that there are plenty of other shops that use Java, we all know that. The point is some startups (those most apt to use these alternative languages) have made bad decisions (as have large firms), but to call the languages themselves ‘unproven’ at this point would not be accurate. No guilt by association here.
Businesses don’t make decisions, people do. I don’t think we should fall into the trap of lumping together the decisions made inside of some startups as any proof of language relevance at this point. When a host of startups fail due to their language choice alone, that conversation can be had.
If you were around back in the late nineties there were a lot of technology startups with funny sounding dot-com names. Many of these companies were using a three or four year-old programming language called Java. They could not have predicted that Java would grow to be as popular as it is today.
Note: Python is older and Ruby is about the same age as Java, Scala has been around for 9 years, Clojure for 5 years.
Argument #2 – If You’re Bored With Java, That Is No Reason To Branch Out
“Becoming “bored or frustrated with Java” is a pretty poor excuse for branching out. As a professional, I’m not paid to feel entertained and broadened in my horizons. I’m paid to get things done as efficiently and as well as I possibly can… Go home and play your Xbox to relieve boredom. Don’t make your employer pay for yet another language learning curve so that you feel less bored and frustrated.” – Comment from TSS reader, click for full context
Simply being bored with Java could be enough for someone to look for other alternatives. I think the bigger issue is that technologists who pay attention to developments in other languages are envious of the features that other languages provide. Today, I feel that a smaller percentage of the Java community explore alternative languages based either on less curiosity or less opportunity. As the Java community at large is exposed to these other languages more and more, I would expect you will see many more defectors. The early adopters of Java were the most curious C++ or C developers who were looking for something different and stumbled on Java, and the most curious of Java pros stumbled on these other languages over the past few years.
Argument #3 – The Assumption That Most or All Of These Alternative Languages Will Be Dead In 5-10 Years
“If I’m off learning optional languages, I’m falling short of what I get paid to do. What’s more, I may have decided to do some development in one of the latest and greatest languages that, in a few years, will fall by the wayside, and now I’ve left my employer with a bunch of projects that will have to be re-written into a language that is currently active and supported.” – Comment from TSS reader, click for full context
Many of the early adopters of Java, as I mentioned in my article, have already been exploring some of these alternative languages for some time now. Often they were not initially paid to do so. Could some of these languages be dead in 5-10 years? Sure. Most of the languages I’m thinking of when I talk about alternative languages are already 5 years old, and some much older. Even the young Ruby/Rails combo has been around for over 5 years.
Did people make the same assumption about Java back in the late nineties?
Argument #4 – Look At The Evidence That These Alternative Languages Are Not Being Adopted/Used/Sought After
Some defenders of Java have been pointing me to various statistics as proof that these alternative languages are not being used, not being sought after by employers, or not being adopted. I would cede that none of the current crop are even close to Java in terms of popularity today. I was sent to this link from Networkworld.com that says Java developers are the “most difficult tech pros to land, followed by mobile developers“. I wonder where the demand for mobile developers was three years ago? Would mobile development be a valuable skill to learn at this point?
As a recruiter, I’m also having a bit of a harder time finding Java developers now. One of the main reasons for that is pretty simple – a lot of the people that I know that used to do Java work aren’t interested in doing Java work any more. Over the years I’ve met a fair amount of experienced Java developers that were dying to get a job doing mobile work, Ruby work, Scala work, etc., but I’m not finding too many Ruby or Scala programmers with five years out of school looking for their first Java job. Maybe it’s just me, but I don’t see that…ever.
Another link was given to the Tiobe Index, which is pretty widely used to highlight trends of language popularity. It is based on search engine hits. All indexes like this have some obvious flaws. If you read Tiobe’s Definition, the phrase “Java programming is dead” will actually improve Java’s position in the rankings. So absorb these ratings with that in mind. They measure chatter, which could be positive or negative.
Well, the takeaway from this graphic, for me anyway, would be that Java dropped significantly and Objective-C seems to be gaining popularity dramatically. But this could be some anomaly in a given month.
“Java has slid only recently and barely while the much touted JVM languages aren’t even on the radar” – Comment from Dzone.com reader, click for full context
The green line that is Java seems to be trending downward on a fairly regular basis since ’02. I’m not sure I’d refer to a 10 year decline as ‘recent’ in the technology industry. Again, I don’t think the Tiobe index is the ultimate indicator, but I wouldn’t point someone to this statistic to support an argument that Java is healthy.
Objective-C wasn’t listed in 1997, was ranked #46 in 2007, and now stands at #3 on the index. If you had picked up Objective-C a few years ago, say in ’07 when it was not entirely popular, you would probably be doing well today as the demand for iOS work is quite high and the supply of developers is quite low. In ’97, Java was #5 – one spot behind VB and two spots behind COBOL.
The arguments against learning a new language or using a new language in production were probably the same back in the late nineties when Java was still new. People surely came to the defense of C and C++ saying that we didn’t need a new language then. It’s progress and subsequent resistance to change, and in the technology industry change can sneak up on you pretty quickly if you aren’t paying attention.
I feel that many in the Java community may not be paying close attention.
If you were a C++ programmer messing around with applets back in ’96, you’ve already been through this transition once. What I’m hearing now from experienced folks is that these alternative languages are for start-ups, “Trix are for kids!“. I know quite a few gray haired former Java developers that are getting paid to write code in other languages now, and I think they would tell you that the alternative language market isn’t just for kids. Were you using Java in a start-up back in the day – were you one of the kids?
My purpose in writing these posts is to make a certain element of the Java community aware of what is out there, and that in my opinion now is an opportune time based on external market forces to explore other languages. This is not an attack on Java as a language or on the people that choose to write in Java. I’ve dedicated much of the past 12 years to the Java community and I don’t intend to change that now. I expect that I will be involved with Java professionals for several years, helping them to find jobs and scheduling great events for my JUG. I chose to change the focus of my business beyond Java, and my suggestion to Java professionals would be to at least consider and research doing the same.
Cue ‘Pomp and Circumstance’ – hit play below to enhance the reading experience (or don’t, it’s just a song)
Dear Graduating Senior and Future Technologist,
First, congratulations on earning your degree! A degree is generally considered as a ‘nice to have’ and not a firm requirement for most programmer slots these days, and hopefully you learned quite a bit about software development in your classes. Having that parchment could be an advantage over other candidates entering the competition for technology sector jobs.
Based on conversations I’ve had with other recent graduates, it seems you have probably received some bad advice and misinformation recently from professors, career placement advisers, your peers, and even your parents regarding your new search for employment. I certainly mean no disrespect to those trying to help guide you, but it is important that you also get some input from people ‘on the front lines‘ in the field. Some academics tend to be insulated from what is really happening in the software industry, and your parents may think that a good pension plan is what you should really be after.
First I will outline how your job search (as an entry level technologist) is unique and much of the generic material that you have read re: job searches will not be applicable. Then we will analyze how to best choose your job, and what to do when you start.
GETTING YOUR FIRST JOB OFFERS
There are quite a few things to keep in mind when trying to get your first job offer(s). I assume by now you’ve read a considerable amount of information on interview techniques and resume tips. Most interview prep info is applicable across the board for all experience levels. Regarding resumes, the first thing to keep in mind is that in most cases the value of your education > job experience, so details on your school projects and classwork should be highlighted and placed prominently on your resume. I don’t recommend an ‘objective’ section for experienced candidates, but for recent grads it is a good tool for conveying your drive and desire.
Companies are going to view many resumes and conduct several interviews with entry-level candidates. Hiring managers are well aware that a significant majority of new engineers will not be immediately productive upon hire. The decision to hire an entry level candidate is essentially an investment for the firm, where said investment has little current value (low productivity) but should hopefully reap dividends in the long-term. A company’s interview process becomes due diligence to weigh the risk and reward for any individual.
Why should someone hire you?
What makes you a better investment than your classmate?
The most important attributes for entry-level engineering hires are:
- Willingness to do whatever is asked, and some things that are not explicitly asked – The tasks given to an entry level engineer will generally be the least interesting, so you will need to pay some dues. Remember Ralph Macchio waxing cars and painting fences in The Karate Kid? (Oh, class of 2012, almost forgot – did Will Smith’s kid wax cars in the remake?) For the first few months of the job, you will be Ralph Macchio – go buy a headband. Sure, Ralph got a bit lippy with Miyagi from time to time, but he finished the jobs and learned his craft. Convey in your resume and during interviews that you are a team player and willing to do what is necessary to further the goals of the company. Bonus points if you can show initiative (I recently had a candidate that was given the task of writing a small application at home as part of the interview process, and she decided to write a test suite and readme file that were not part of the assignment – brilliant!).
- Desire and ability to learn – The desire to learn will be an intangible that may be best demonstrated by any extracurricular engineering-related activities that you do. School tech clubs, user groups, hobbies, and conferences all apply to your curiosity. Ability to learn might be shown via an anecdote about a school project where you had to pick up a new tool or language with little guidance to complete the task.
- Youthful exuberance and enthusiasm – Injecting young talent into an organization can give a spark to any disillusioned engineers who may be losing passion. Someone with great positive energy (even combined with limited skills) has great value as a catalyst. In sports, these are players that may be referred to as ‘good locker room guys’. Don’t do cartwheels in your interview, but showing managers a contagious energy that people can feed off is a real benefit that you could provide immediately while learning the trade.
- Malleability – One good thing about not having any job experience is that you should be somewhat free of any bad habits. When given a choice between entry level and someone with just a bit more experience that has some potential baggage, companies will most often take the blank slate. The team will help mold you into being productive specifically within their environment and development methodology. It’s difficult to demonstrate malleability in interviews, but be willing to let it happen.
CHOOSING YOUR FIRST JOB AND WHAT TO DO WHEN YOU START
It seems that many of you were recently told how vitally important your first job is and to be extremely selective in making a choice, and I agree that your first job in the industry can be significant. However, it is probably not quite as important as you think, and based on many conversations it is not nearly as significant as you are being told. You are entering a field that is known for a high turnover rate with available statistics tending to fluctuate in the 10-25% range (often higher for first jobs), so odds are you won’t still be at this first job in a few years anyway. So let’s consider how to get the most out of the experience.
When I speak to entry-level and junior engineers and ask them about their job search criteria, I generally get similar answers to the ones I get from more experienced pros. “Interesting technologies and problem domains, challenging responsibilities, good people/culture, competitive compensation and benefits, stability…” Does knowing that the software engineering field has historically had a high turnover rate change any of your criteria?
“But my professor said I shouldn’t take a job using certain languages, my adviser said I should be paid at least $63,200 per year, and my parents told me I need to be looking for job stability.”
No, no, and no! The language is just a tool to use while learning the trade (noting that some tools/skills are more marketable than others), the money will come to you if you take the right steps in your career, and I hate to be the bearer of bad news, but there is no such thing as stability anymore. The first job search should not be about trying to get rich quick, nor should it necessarily be about finding an employer that you will be with forever. Did you plan on marrying the first guy/girl you dated? If it happens, great, but let’s not go into this first search with unrealistic expectations. What is really important about your first job?
The single most important thing you should be looking for at the start of your career is to work in an environment where people are both able and willing to teach you how to become a better engineer.
Other factors will obviously come into play, but be sure to weigh those with the above in mind. Just because a software shop pays the highest salary, uses the newest technology, has plenty of customers, offers you the most job responsibility and passes the Joel Test doesn’t make it the best place for a freshly minted engineer (but it does sound pretty tempting).
Being ‘taught‘ doesn’t mean that you should seek out companies that provide formal training sessions in air-conditioned lecture halls, as that was what college should have been. It also doesn’t mean that you will be coddled and have your hand held every step of the way. Swimming lessons are taught in the pool for a reason, and the deep end can be more useful than the shallow end for certain training purposes.
Able to teach would be characterized as a team with strong developers (preferred size is debatable but somewhat irrelevant) and communicators that have good habits and a track-record of writing quality code. Ideally the team is busy and productive enough where new engineers can learn to function in a fast-paced environment with deadlines, but not so chaotic that the company doesn’t have the luxury of letting you make the occasional mistake. Aside – You are going to make mistakes, so be prepared to accept some blame for a problem you created, learn from the mistake, and don’t compound the problem by passing the buck.
Willing to teach can be a little complicated with both personalities and time constraints being potential inhibitors. You
want need to find a mentor, and strong technologists will need to have their egos stroked a bit (protip – you will find a few egos in the tech world). The search for a mentor is not a race and shouldn’t be taken lightly. Some may argue that finding the ‘right’ mentor could be as important as finding the ‘right employer.
Take a few weeks to try and figure out who the best engineers are in your team/department, and who you could learn the most from (note that the best engineer often does not equal the best mentor). Which developers are tasked to explain things to other team members and which ones conduct internal training activities? Once you have some ideas as to who the best engineers are, maybe try asking them a few test questions to see how responsive they are to helping out the newbie. Finally, choose the best fit based on all these factors and tell her/him that you are interested in being mentored. If this person likes you she/he will most often be flattered, and hopefully you now have your first guide through your early career. If this person refuses or seems hesitant, go ask your second choice. Repeat as necessary.
Once you’ve found your mentor, pay careful attention and try to figure out what makes this person such a good engineer. Note their work habits, interactions with both technical and business teams, reading materials/bookmarks, how they handle working under duress, etc. How does he/she respond to unrealistic deadlines, his/her own bugs, dissension within the ranks? Continue to ask questions and be conscious of any social cues your mentor might be sending out (i.e. learn to differentiate the ‘Not now, kid’ leer from the ‘You could just Google that question’ stare).
Now that you have a mentor, show your mentor your appreciation by both being grateful and working hard. Don’t be the last one in or the first one out, as people notice those things for new hires. Your performance will now reflect somewhat on your mentor, so even if your actual contribution is somewhat low your effort should never be in question.
Remember that as an entry-level developer you are an investment for the company, and the harder and smarter you work the more apt you are to begin paying dividends. Don’t make them regret their decision to invest in you. Chances are you won’t be at this first job for more than a few years, so absorb as much information as you can from your the opportunity and your mentor.
Over the past few months I have had some exchanges with small company executives and hiring managers which have opened my eyes to what I consider a relatively new wrinkle in the software development hiring world. I have been recruiting software engineers for 14 years, and I don’t recall another time where I’ve observed this at the same level. Here are two examples.
The first incident was related to a candidate (‘A’) resume that I submitted to a local start-up. A was well-qualified for the position based on the technical specifications the client gave me, and I anticipated that at worst a phone screen for A would be automatic. I even went as far as to share A’s interview availability. A day after hitting ‘send’, I received feedback that the hiring manager was not interested in an interview. A large part of the manager’s reasoning was related to the fact that A had taken a two year sabbatical to pursue a degree in a non-technical discipline and subsequently took a job in that field for a brief stint, before returning to the software world a few years ago. I clarified information about A to be sure that the manager had full understanding of the situation, and the verdict was upheld – no interview.
My second anecdote involves another candidate (‘B’) that I presented for a position with a different client company. B was someone I would classify as a junior level candidate overall and probably ‘borderline qualified’ for the role. B had roughly the minimum amount of required experience with a few gaps, and I was not 100% confident that B would be invited in. B was brought in for an interview, performed about average on the technical portions, and shined interpersonally.
As this company does not make a habit of hiring average engineers, I was at least a bit surprised when an offer was made. I was told that a contributing factor for making the offer was that B’s ‘extracurricular activities’ were, according to my client, indicative of someone that was going to be a great engineer (though B’s current skills were average). B’s potential wasn’t being assessed as if B were an entry level engineer with a solid academic background, but rather the potential was assessed based on B’s interest in software.
There are obviously many other stories like these, and the link between them seems obvious. Software firms that are hiring engineers (smaller shops in particular) appear to be qualifying and quantifying a candidate’s passion with the same level of scrutiny that they use in trying to measure technical skills and culture fit. Historically, companies have reviewed resumes and conducted interviews to answer the question, ‘Can this candidate perform the task at hand?‘. For my purposes as a recruiter of engineers, the question can be oversimplified as ‘Can he/she code?’. It seems the trend is to follow that question with ‘Does he/she CARE about the job, the company, and the craft?’.
If you lack passion for the industry, be advised that in future job interviews you may be judged on this quality. Whether you love coding or not, reading further will give you some insight. Engineer A is a cautionary tale, while B is someone the passionate will want to emulate. Let’s start with A.
Candidate A never had a chance, and I’ll shoulder partial responsibility for that. A was rejected based solely on a resume and my accompanying notes, so theoretically A could be extremely passionate about software engineering without appearing to be so on paper. Applicants do take some potential risks by choosing to include irrelevant experience, education, or even hobbies on a resume, and I will often warn my candidates of items that could cause alarm. In this case, A’s inclusion of both job details and advanced degrees in another discipline were judged as a red flag that A might decide to again leave the software industry. A similar conclusion could have been reached if A had listed hobbies that evidenced a deep-rooted drive toward something other than engineering (say, studying for a certification in a trade).
Another related mistake on resumes is an Objective section that does not reflect the job for which you are applying. I have witnessed candidates being rejected for interviews based on an objective, and the most common example is when a candidate seeking a dev job lists ‘technical lead’ or ‘manager’ in the objective. Typical feedback might sound like this: ‘Our job is a basic development position, and if she only wants to be in a leadership slot she would not be happy with the role’. Listing the type of job that you are passionate about is essential if you are going to include an objective. I prefer that candidates avoid an objective section to avoid this specific danger, as most job seekers are open to more than one possible hiring scenario.
Since the search starts out with the resume, be sure to list all of the details about you that demonstrate your enthusiasm. This should include relevant education, professional experience, and hobbies or activities that pertain to engineering. When listing your professional experience, emphasize the elements of your job that were the most relevant to what you want to do. If you want to strictly do development, downplay the details of your sys admin or QA tasks (a mention could be helpful, just don’t dwell). When listing your academic credentials, recent grads should be sure to provide specifics on classes relevant to your job goals, and it may be in your best interest to remove degrees or advanced courses unrelated to engineering.
In my experience, the most commonly overlooked resume details that would indicate passion are:
- participation in open source projects
- membership in user groups or meetups
- conference attendance
- public-speaking appearances
- engineering-related hobbies (e.g. Arduino, personal/organizational websites you built or maintain, tech blogging)
- technical volunteer/non-profit experience
If any of the above are not on your resume, be sure to include them before your next job search.
Assuming that you get the opportunity to interview, try to gracefully and tactfully include some details from the bulleted list above. Your reading habits and technologies you self-study are best mentioned in interviews, as they may seem less appropriate as resume material.
Conclusion: Most candidates should feel free to at least mention interests that are not engineering related if the opportunity presents itself, as companies tend to like hiring employees that are not strictly one-dimensional. Just be sure not to overemphasize interests or activities that could be misinterpreted as future career goals. Passion alone won’t get you a job, but it can certainly make a difference in a manager’s decision on who to hire (candidate B) and who not to even interview (candidate A). Make sure you use your resume and interview time to show your passion.