Category: Newsletter articles
Why You Didn’t Get the Job
Over the course of my career I have scheduled thousands of software engineering interviews with hundreds of hiring managers at a wide array of companies and organizations. I have learned that although no two managers look for the exact same set of technical skills or behaviors, there are recognizable patterns in the feedback I receive when a candidate is not presented with a job offer.
Obviously, if you are unable to demonstrate the basic fundamental skills for a position (for our purposes, software engineering expertise), anything else that happens during an interview is irrelevant. For that technical skills assessment, you are generally on your own, as recruiters should not provide candidates with specific technical questions that they will be asked in an interview.
It should be helpful for job seekers to know where others have stumbled in interviews where technical skill was not the sole or even primary reason provided for the candidate’s rejection. The examples of feedback below are things I have heard repeatedly over the years, and tend to be the leading non-technical causes of failed interviews in the software industry (IMO).
Candidate has wide technical breadth but little depth – The ‘jack of all trades’ response is not uncommon, particularly for folks that have perhaps bounced from job to job a little too much. Having experience working in diverse technical environments is almost always a positive, but only if you are there long enough to take some deeper skills and experience away with you. Companies will seek depth in at least some subset of your overall skill set.
Candidate displayed a superiority complex or sense of entitlement – This seems most common when a candidate will subtly (or perhaps not so subtly) express that they may be unwilling to do any tasks aside from new development, such as code maintenance, or when a candidate confesses an interest in exclusively working with a certain subset of technologies. Candidates that are perceived as team players may mention preferences, but will also be careful to acknowledge their willingness to perform any relevant tasks that need to be done.
Candidate showed a lack of passion – The lack of passion comment has various applications. Sometimes the candidate is perceived as apathetic about an opportunity or uninterested in the hiring company, or often it is described as what seems to be an overall apathy for the engineering profession (that software is not what they want to be doing). Regardless of the source of apathy, this perception is hard to overcome. If a candidate has no passion for the business, the technology, or the people, chances are the interview is a waste of time.
Candidate talked more about the accomplishments of co-workers – This piece of feedback seems to be going viral lately. Candidates apparently ramble on about other groups that built pieces of their software product, QA, the devops team’s role, and everyone else in the company, yet they fail to dig deep into what their own contribution was. This signifies to interviewers that perhaps this candidate is either the least productive member of the team or is simply unable to describe their own duties. Give credit where it is due to your peers, but be sure to focus on your own accomplishments first.
Candidate seems completely unaware of anything that happens beyond his/her desk – Repeatedly using answers such as “I don’t know who built that” or “I’m not sure how that worked” can be an indicator that the candidate is insulated in his/her role, or doesn’t have the curiosity to learn what others are doing in their company. As most engineering groups tend towards heavy collaboration these days, this lack of information will be a red flag for potential new employers.
Candidate more focused on the tools/technology than on the profession – Although rare, this often troubles managers a great deal, and it’s often a symptom of the ‘fanboy’ complex. I first experienced this phenomenon when EJB first arrived on the scene in the Java world, and many candidates only wanted to work for companies that were using EJB. When a technologist is more focused on becoming great at a specific tool than becoming a great overall engineer, companies may show some reluctance. This is a trend that I expect could grow as the number of language/platform choices expands, and as fanatical response and the overall level of polarization of the tech community around certain technologies increases.
Candidate’s claimed/résumé experience ≠ candidate’s actual experience – Embellishing the résumé is nothing new. A blatant lie on a résumé is obviously a serious no-no, but even some minor exaggerations or vague inaccuracies can come back and bite you. The most common example is when a candidate includes technologies or buzzwords on a résumé that they know nothing about. Including items in a skills matrix that are not representative of your current skill set is seen as dishonest by hiring managers.
Candidate’s experience is not ‘transferable’ – If your company is only using homegrown frameworks and proprietary software, or if you have worked in the same company for many years without any fundamental changes in the development environment, this could be you. The interviewer in this case feels that you may be productive in your current environment, but when given a different set of tools, methodologies, and team members, the candidate may encounter too steep a learning curve. This is often a response on candidates that have worked within development groups at very large companies for many years.
Give some thought to these before your next interview.
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+.
Lessons From a JUG Talk With Eric ‘ESR’ Raymond
(full video of ESR’s presentation from YouTube below this post)
I have been President of the Philadelphia Area Java Users’ Group for 12 years, and as one might expect a typical meeting is geared around a presenter with a slide deck that gives a deep dive into some Java topic. We could hear a case study, an explanation of a tool, tips for programming effectiveness, etc. The JUG has followed this model since I founded the group in 2000, and we manage to get between 75-150 attendees at most meetings.
Last month we held a meeting that was entirely different. I had reached out to Eric Raymond (aka ‘ESR’), who is best known as a leader in the open source software movement and author of The Cathedral and the Bazaar, about potentially speaking to the group. Although ESR is not commonly associated with Java, I thought it would be an opportunity for the group to hear a well-known and respected engineer speak about a topic. ESR suggested that he would do a free-form type presentation, without notes and slides, and simply take questions from the audience to use as improv material. With about 150 engineers in attendance, ESR fielded a fairly wide array of questions on everything from functional languages to open source licensing to coding standards.
So why am I posting this article on JobTipsForGeeks? As a recruiter I am often asked for career advice by my network of engineers, and my answers are always based much more on market trends (supply and demand) and ‘buzz’ around various technologies than on the viability of the technologies themselves. For example, I am well qualified to discuss the adoption of specific languages by software companies in my region, but I am much less qualified to discuss the long-term viability of those adoption choices from a technical viewpoint.
As ESR was asked some of the same questions I am often asked, I thought his answers and insights were an opportunity for the audience to hear a ‘technically-grounded’ counterpoint (or supporting evidence) to the market-based advice I provide to individuals. His specific commentary on functional programming languages and the value of learning them regardless of adoption rate was something I thought was insightful advice for engineers of all levels, and his musings on coding standards and how to obtain management ‘buy-in’ on open source are great tips for navigating at companies that may not be as tech-friendly as others. These are not all specifically ‘job tips’, but I believe there is certainly some value in reading these opinions as you decide on which directions you may take your software career.
The quotes below are ESR’s responses to questions, organized by topic.
ON PYTHON
“Yes, I really like Python. I like it for a very specific reason. I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability. That is, the ease with which you can read your code six months later. The longer I program, the more convinced I am that that is THE most important metric of a language, bar none… Most of the programming I do these days is in either Python or C.”
ON JAVA
“I still haven’t actually learned Java well enough to do more than a couple hundred lines of programming in it. I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy. So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’.
ON C++
“C++ has the exact opposite problem to the virtue I had called out in Python. Long-term maintainability of C++ code, TERRIBLE.”
ON PERL (answer continues from his answer on C++ above)
“OK, the best thing I can say about that is, it’s not as bad as Perl, but I’m afraid that constitutes damning with faint praise. I still like Perl fine and occasionally use it, as long as the program isn’t more than 25 lines long.”
ON GOOGLE GO
“I am sort of gingerly dipping my toes into the waters of Go, Google’s new language… I’ll tell you one concurrency thing I am really pleased by. I have been wondering since about 1971 why nobody took the ball and ran with Hoare’s communicating sequential processes model. So elegant, so pretty, so nice to reason about and 40 years later the Go people picked it up and ran with it. That’s one reason I’m looking at Go. CSP is the basis of their concurrency model in that language which is enough to motivate me to want to look at it some more.”
THOUGHTS ON THE JVM BECOMING MORE GENERAL PURPOSE
“I’m mostly ok with that. I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be.”
ON RUBY
“I’ve dipped into Ruby a little bit, there was a point where I had to modify some Ruby code for a project I was working on, so I think I understand the language a little, maybe not master level. My impression of Ruby is that it has pretty much the same virtues and the same problems as Python, and I might be tempted to switch except that it’s not different enough. Functionally speaking of course, I mean aesthetically there is all kinds of odd little differences. But it’s not different enough from Python to make me move, that’s my impression.”
ON SCALA
“It’s on my list of languages to learn. I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it.”
ON OPEN SOURCE LICENSING/GPL
“…this is one of my more incendiary opinions, I don’t think we need the GPL anymore…My attitude in general is just use permissive licenses, stop with the viral stuff…”
ON OPEN SOURCE
“If you’re thinking in terms of bringing open source inside the corporation, you’ve already failed. That is already thinking in the wrong direction because you’re trying to figure out how to control and make safe a process that thrives on lack of control and no safety, other than good code review. Instead of thinking about how to bring open source inside the corporation, the right kind of question to ask is ‘how do I start up an open source project that benefits my corporation, build a community, and THEN sell it to my bosses?’. Because one of the iron laws of dealing with bureaucracy is ‘it is easier to get forgiveness than permission’…How do I start an open source project that will interest my bosses, get it viable, and then sell it to them once they have a benefit that they can see?…Show them a benefit. Don’t say ‘we can do this wonderful thing if you authorize me to spend n hours with no obvious physical return’. That is something a manager is always going to say ‘no’ to. What you have to do is show them a benefit. It works much better, for example, to find an existing piece of open source software that is fairly close to solving the business problem and going to your boss and saying ‘you know, this thing already works and already has a user community and I can show you where it’s deployed, give me 50 hours and I can turn it into something that will solve our problem too’. At that point you have a much better pitch, because that’s the kind of trade-off your manager is used to thinking about.”
ON OPEN SOURCING PRODUCTS DEVELOPED IN-HOUSE
“The universal argument that works for that is to say ‘hey boss, how would you like to reduce your maintenance costs?’. Lay off the work on other people so it’s not coming out of your budget. That’s the reason for open sourcing stuff that was developed in-house. The argument for that is cost-spreading and risk-spreading. And you want to put it exactly that way, ‘hey look, I’m going to reduce your bottom-line expenses’.”
PROS AND CONS OF CODING STANDARDS
“My first overarching observation is that the smartest thing you can do is choose a language in which coding standards are not necessary because there’s a uniform style that the language semi-enforces. Yes I have Python in mind. Go also has this property, it’s very difficult to have indent style variations in Go…The smartest thing you can do if all other things are equal is pick a language where you will never have coding standards wars. The reason that that is a high-utility thing to do is, of course, the purpose of coding standards is to maximize readability of the code and long-term maintainability. And yes, I do think that is extremely important… in particular if you are writing in C, the thing to do is pick a coding standard but don’t try and be too anal about it. There comes a point at which the effort to enforce every conformance to every minutiae of a coding standard is causing you more pain and overhead than it is actually worth in reduced maintenance costs.”
THOUGHTS ON LISP/FUNCTIONAL PROGRAMMING
“There’s a can of worms. The first thing you need to know about me in this connection is I’m an old Lisphead…I actually cut my teeth on APL…The result of the first two languages that I learned is I have this mental measure of a programming language’s adhesiveness. A programming language is adhesive to the degree that it sticks to your brain and cannot be displaced from your brain except by a language that is more adhesive. I learned APL first, and then I got exposed to Lisp…My first question was ‘which one is more powerful in a practical sense?’, and yes, yes I know they are all Turing equivalent…So I decided to test the question by writing two toy implementations. One of an APL interpreter in Lisp, and one of a Lisp interpreter in APL…That is why I switched to Lisp, and discovered that Lisp is more adhesive than APL, and it displaced APL from my brain. Nothing has displaced Lisp from my brain. I have not encountered any language that is more adhesive than Lisp. Which is not to say I use Lisp a whole lot, but that it still dominates the way I think about programming.”
ON HASKELL
“I dipped my toes into Haskell, and someday I’ll have to do a significant project in Haskell. But that time is not yet though. I haven’t found anything for which it is better than the tools I’m already using. The problem with languages like Haskell…and I have digested dozens and dozens of computer languages in my time and I used to be a mathematician with a specialty in formal and foundational logic. With all these credentials, Haskell makes my brain hurt. So if Haskell and other pure functional programming languages make your brain hurt, that’s ok. And the thing that worries me about them, is that if they make MY brain hurt, how the hell are they going to make any traction with people who didn’t used to be foundational logicians with a specialization in logic.”
ON FUNCTIONAL LANGUAGES
“My worry is that these are beautiful tools that will never actually achieve mass acceptance because they are simply too hard for most programmers to use. The question is, what is the attraction then? For the class of problems that is easily addressed using a functional language, using functional languages produces solutions that are breathtakingly, devastatingly elegant, beautiful and terse. When the tool matches the problem, there are very few things in the universe more lovely than a properly designed functional program. The issue though, is ‘A’ – that the tools are difficult to comprehend, and ‘B’ – I said ‘when the problem matches the tool’, there are lots of problems that don’t match functional programming language tools because functional programming language tools really want to live in a universe where everything is stateless and all transactions are reversible. Uh oh. You run into problems with those assumptions the moment you deal with messy things like input/output operations…intrinsically not reversible. A lot of the complexity in functional programming languages arises from this unavoidable interface, this energy barrier between the programming language’s internal world of pure logic, statelessness and reversibility and infinite backtracking, and the messy exterior world where we actually have to deal with stateful objects…They are fascinating tools, they are good for some classes of problems, I love them aesthetically. I don’t know if they will ever be more than a small minority preference.”
ON LEARNING FUNCTIONAL LANGUAGES
“Nevertheless, even though these tools may never get huge traction, learn one anyway. When you get deep enough into any functional language, for me it happened with Lisp…there will come a point at which you will achieve Satori, you will achieve enlightenment about how functional programming actually works and your entire universe will lurch sideways and never be quite the same again. And even if you never use a functional programming language for a line of code after that, it will change the way you think, it will change the way you form abstractions, it will clean things up.”
ON JAVA AND PYTHON SEEMING MORE FUNCTIONAL
“Ironically in the case of Python, Guido actually doesn’t like Lisp and his personal preference would be to take the functional constructs out of the language (Python), but every time he does that a bunch of his friends and senior developers, including me, look at him and say ‘you will take away my lambdas when you pry them from my cold dead fingers’.”
PYTHON VS JAVA
“The advantage of Python over Java is that it’s less heavyweight, there isn’t a huge syntactic thicket of declarations and codicils and stuff that from a point of view of a Python programmer is extraneous junk that gets in the way of comprehension. There are languages that are much worse that way, see my rant about C++. Java is a bit too syntax-heavy and cluttered for optimum long-term maintainability. That is my opinion anyway.”
OPEN SOURCE
“We now live in a situation where lots of people can use and enjoy open source tools and an increasing number of people can make a living writing and maintaining them, and that’s a good thing. Do I want to see all software become non-proprietary? It wouldn’t particularly bother me if that happened but it’s not a major objective for me. It doesn’t harm me that other people write proprietary software as long as they don’t try to infringe on my freedom to write software the way I want to. That’s the freedom I’m concerned with protecting. I want people who voluntarily choose to be part of the open source community to be able to continue to be a part of it, and as long that objective is achieved, what other people do is not really of much concern to me.”
Your comments are welcomed below, thanks for reading.
How Employers Measure Passion in Software Engineering Candidates (and how to express your passion in resumes and interviews)
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.
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, and Google +.
The Future: Polyglot Programmers
I wrote an article three years ago, “Become a Better Java Programmer – Learn Something Else“, that was subsequently picked up by JavaWorld and DZone and received moderate positive and a bit of negative feedback. The negative was primarily aimed at my assessment that “perhaps 80%” of the best local Java talent were familiar with at least one of a set of other languages I listed. Some readers felt the 80% was pulled from thin air (or pulled perhaps from somewhere else), and I concede the number was simply an estimate. And of course the “best local Java talent” line was also subjective, but time has shown I am a good judge of that.
The gist of the article was that the best Java pros that I knew at the time were either fortunate, curious or ambitious enough to learn other languages and platforms. Perhaps they wanted to improve their Java skills, to simply climb a mountain because it was there, to have a Plan B in case Java went downhill (article published June ’09, Oracle/Sun deal announced April ’09), or maybe they knew something I admittedly didn’t know regarding where things were headed.
When I wrote the article, I was offering career advice targeted to Java developers who wanted to continue to be Java developers – learn another language and you should become more effective using Java. I don’t think I had any real instincts that things were going to change dramatically over the next several years. I think the dramatic change is now happening, and it’s time to pay attention if you haven’t been.
The concept of polyglot programmers and polyglot programming isn’t new by any means, and I realize that I’m certainly not the first person or the most qualified person (I may be the tallest) to think or write about the subject. Neal Ford mentioned it over five years ago in a blog post that was quite prophetic.
Think of it this way: Years ago if you were living in Germany, chances are you only spoke German. As travel became easier and business spread to different countries, the world got smaller, and it was advantageous or even necessary to learn new languages because the chances of encountering a non-German speaker were greater. Now many Europeans speak at least a couple languages fluently out of necessity. If you are a bartender in Rome, chances are you know how to say ‘beer’ and ‘thank you’ a few ways. The software development world and the options within it have grown vastly, but the need to be productive or conversant in more than one programming language has not historically been a requirement to get ahead. I feel that has changed, and will continue to change in the years to come.
Since writing my last newsletter I had a couple interesting and vastly different conversations with two technologists that made quite an impression. One was with a very experienced (>10 years) Java programmer who admittedly had no real programming experience beyond the more common Java tools and API’s (some MVC, JSP) and invested little time trying to keep up with industry trends. She had many years with the same company and saw very little change in the tech environment. The second conversation was with a grad student finalizing a Master’s in Comp Sci who had academic, internship, and professional experience (< 2 years) with Python, Java, C++, and Ruby. He was involved in various tech communities and technology was a hobby in addition to being a chosen profession.
Right now, both of these candidates are quite employable, and as you would expect the experienced Java programmer will earn more at present. If I had to buy stock based on future earnings and career advancement in these two candidates today, I’d put all my money and mortgage my house on the grad student. This Java pro is, at this point, not even aware that the world has passed her by.
Historically, most software shops were hung up with hiring requirements that listed minimum amounts of acceptable experience with a technology. I can recall having to explain to a client a few years ago that the only person that might have had the amount of Spring experience they were seeking was Rod Johnson (true story). When I speak to my clients now, it is clear that most are more interested in aptitude over experience with specific languages or tools, as well as an understanding of certain core engineering concepts and principles (perhaps multi-threading or functional programming) in addition to a set of character traits that tend to result in productive engineers.
The metaphor I often use is to liken engineers to athletes. A great athlete can throw a football or a baseball skillfully and is able to use both a hockey stick and golf club to make solid contact with a puck or ball, once the athlete makes some simple adjustments to the chosen object. Likewise, a truly great engineer should be able to succeed using any of several languages, once they understand the syntax and basics.
With the wide variety of robust languages and platforms currently available and ready for prime time, it is hard to imagine that any one or two will become as dominant a force as Java and .Net have been over the past 10+ years. I believe the days of hearing ‘We are a Java shop’ or ‘We are a Python shop’ are behind us. The most innovative shops are mixing technologies based on using the language/platform that is the best fit for the task while also factoring in the experience level of the team members. To remain valuable and relevant, it is becoming necessary to write software in more than one language. Having the ability to produce in more than one language may be a luxury today, but it is becoming very clear that this will be a necessary skill for tomorrow’s engineer.
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, and Google +.
Job Tips For Geeks 