Michael Eriksson
A Swede in Germany
Home » Misc. | About me Impressum Contact Sitemap

Job application paradoxes


Over the years, in particular when freelancing, I have gone through application processes with a large number of potential employers/customers. Doing this I have noticed a considerable contrast between, on the one hand, the ideals of text-book applications and typical patterns in employer behaviour, and, on the other, the type of thinking that makes for a good software developer. This article discusses some of these issues.

The Tall Dancer syndrome

Many of the below items are good examples of the Tall Dancer syndrome. As often is the case, the minority (the techies) tend to learn how the other side works, and most become understanding and adapted; while many members of the majority, unfortunately, tend to remain intolerant, misinterpret different standards of behaviour as rudeness, fail to understand that different people can have very different priorities, etc.

Notably, the discussions of developer mentality refer to the natural state, and the adapted behaviour may be different: An experienced developer will, e.g., be unlikely to feel insulted by a gratuitous email (as discussed below), but will likely roll his eyes and laugh it off as yet another sign of how odd people are. Similarly, he will be likely to adapt to the behaviours of non-developers—even if they do seem absurd.

“Social skills” are a particularly problematic issue: The main reason why so many developers are considered lacking in this area is that they merely work to a different standard, have different preferences, etc. It is only a slight exaggeration to say that “learning social skills” amounts to “learning to behave in a manner conformant with the majority” or “pretending to be an extrovert”—while other factors, e.g. emotional maturity, which many developers possess to a higher degree than the average extrovert, are often not considered. See e.g. the discussion of emotional intelligence in the Tall Dancer article or my take on Dr. House and social skills.


Uses of “social skills” below should be seen as (slightly sarcastically) referring to the common use of the phrase.

List of issues

  1. A common recommendation is that the cover letter (sometimes the entire application) should be tailor-made for each employer. A good software developer, however, will in his work strive to solve a particular problem once, make that solution of high quality and reusable in any situation where that particular problem occurs, etc. This would amount to writing one single, high-quality cover letter, and just make minor changes and adaptions for company- and position-specific details.


    I tend to go with a compromise where I have some parts that are fix and some parts that are written from scratch in each case. The variable part also depends somewhat on the ad and company website: If the ad/site is generic, my application tends to be more generic; if it is more original, so is my application. In addition, I occasionally start over from scratch even with the fix parts.

  2. Another is to always send a “thank you” email or similar acknowledgment after an interview (apparently not just as a courtesy, but because it would demonstrate “follow-up skills”). This too is contrary to the focus on efficiency and effectiveness a good developer should have—why waste the time of two parties in that manner? In fact, if a developer receives a follow-up that has no practical purpose (e.g. clarification of something discussed), he may well see it as an annoyance—not only because of the time wasted, but also over the opinion the sender implicitly reveals of him, i.e. that he is gullible enough to fall for such an easy trick of garnering sympathy.

    Similarly, in particular when dealing with HR departments, there tends to be a lot of fluff and flattery being both sent and received; however, good developers tend to have a mind-set where this is both a waste of time and a sign of lack of respect for the other party.

  3. A large minority of companies require applications or part of applications to be delivered in various MS-Office formats. A good developer, however, will shun these third-rate tools and prefer to work in other ways. Personally, I almost always answer with a link to We Can Put an End to Word Attachmentse with the statement that I do not have MS-Office available, being a Linux user. (Note that while OpenOffice is better than MS-Office, it is still not what I would consider good; and it is far from fool-proof when it comes to handling proprietary Microsoft formats.) I use MS-Office when I am paid for it only, and a company that requests MS-Office documents loses many credibility points with me—one which unconditionally requires them, is a place where I would be very unlikely to find myself at home. A software company should know better than to use MS-Word, just like a construction company should know better than to use hammers of gold, a delivery company should know better than to use a bicycle for a delivery of two hundred cases, and an accounting firm should know better than to use abaci.

    Another common constraint is to require PDF files; this, however, is far less of a problem, because it still leaves the creation in the hands of the applicant, who merely needs to convert his files to PDF—which can be done from almost all other formats with little effort.

  4. Some companies, in particular larger ones, additionally force the applicants to re-write their CVs, project lists, whatnot, in specific formats, e.g. through a webinterface to an internal database or in a pre-formatted MS-Office document (usually one that it is so heavy in macros that non-MS products simply cannot cope). Note that, unlike above, PDF is not an improvement here; on the contrary, support for many non-central features, notably form-input and scripting, is very poor among non-Adobe programs.

    Similar to the above, a good developer will consider this an infuriating waste of time: He will want to write his information down once and give it to all employers in the same form (or forms which can be generated from the original; e.g. LaTeX -> PS, PDF, HTML; or XML -> other XML, HTML, PDF). Further, a good developer will want to focus on head-work, not leg-work—and these re-writes are nothing but leg-work. (This applies even when copy-and-paste is possible, because there can be considerable re-formatting and adaption necessary. Not only is formatting, headings, and similar, typically lost when copying from one program to another; but MS Word tends to apply automatic formatting and modifications to pasted text, in a brainless manner, which have to be corrected. Further, the imposed formats often require that individual paragraphs, often even several words or a single number, be copied individually; rather than in one single operation. In some cases, it is not even possibly to use the same texts, but new texts must be written.)


    The main reason for these re-writes is obviously that the employers want to save time and efforts for themselves at the cost of the applicant, which, while reflecting poorly on their attitude towards employees, is somewhat understandable.

    However, I also suspect that some use them as an unethical and misguided test: If the applicant is willing to jump through sufficiently many hoops, he is likely to be a more compliant and hard-working employee. (This based on what I have seen in terms of “hoop leaping” in applications and offers between small and large companies, say a small company bidding on a two-year, ten-man contract from a large company. Often the smaller party has to invest several man-months, unpaid, to just have a one-in-ten shot at getting the contract.)

    The hitch: A good software developer should not be a compliant drone, but questioning, independent, and thinking for himself—and using the “hoop leaping” criterion is likely to select exactly the wrong people. Similarly, a good software developer has a policy of “work smart, not hard” (even if also willing to work hard for shorter periods of time, when it is truly called for), which actually leads to more being accomplished, and at a higher quality, than with a “work hard” policy—it is not input in hours, gathered by working over-time in the evenings, that matters; but the output in software, accomplished by good thinking and rational work.

  5. The actual interviews are often of limited, sometimes even negative, value (this is highly dependent on the interviewer, however). Most interviews are just about appearances, clothing, how one manages to present oneself, and other factors of little value to the actual work of a software developer—and good software developers tend to be uninterested in superficialities, sometimes to the point of having a disdain for people who are too well-dressed, behave too “smoothly”, or are otherwise superficially pleasant: My own standard clothing of decent shirt, black trousers, and black leather shoes (without tie and jacket) borders on the snobby among my fellows, where t-shirt, jeans, and sneakers is the standard.

    Further, interviews often go into a re-hashing of what a conscientious interviewer would already have gathered from the application, while questions and tests that probe the intelligence and knowledge of the applicant are rare. (Here, again, a good developer has the contrary mentality and can be annoyed at having to re-state what is already written—or at the interviewer for not having done his homework.)


    How would I hold an interview?

    I would ask specific questions focusing on finding information not present in the application (and, to some degree, to check for misrepresentations), I would try to get a rough estimate of the intellectual capabilities of the interviewee, and probe his knowledge in relevant areas. (The latter, bearing in mind that such probes can be misguiding when the knowledge has not been recently used.)

    Further, I would try to judge his level of understanding. In particular, I would strive to filter out candidates who engage in pre-mature optimization, do not understand the value of readable code, have naive ideas about this and that. (While giving some leeway to the young and inexperienced.) More information can be found e.g. in my discussion of what to read.

  6. In the same vein, disturbingly many adverts for developers, at least in Germany, explicitly put a focus on social skills (cf. the earlier discussion of this topic), “sicheres Auftreten” (hard to translate, but “self-confidence”, “suaveness”, and “authority” catches aspects of it), and other traits not traditionally associated with software developers. While these characteristics are often beneficial, they are not central to the role of a software developer, good software developers tend to not have them, and those who do have them tend to be poor developers—some traits simply correlate positively, others negatively, just like tall people tend to be heavier than short people, red-heads tend to have more freckles than others, and so on.

    If competent developers who additionally have good social skills can be found, they may very well be the best choices; however, they will be far rarer than the incompetent developers and non-developers with good social skills.

    Selecting for these traits will result in worse choices than when a focus is put on traits like intelligence; ability to think critically; or the mentality that causes someone to read books on programming, learn the ins-and-outs of the tools used, or prefer sudoku over the bar scene: It is possible to deliver first-rate software on time with a team of brainy überneirds—it is not possible to do so with a team of hyper-extroverts without the right knowledge, understanding, and intelligence. Further, while there are many other roles where the relative benefits of various characteristics are very different (consider e.g. valuable traits in a salesman), I suspect that increasing the average “neird proportion” would have positive effects even in most non-developer roles—while the current trend in the other direction poses a positive danger.


    I have repeatedly heard arguments like “In the past, it was enough to know the technical side, but in today’s work-place social skills are just to important to be left out.”—a statement which naively assumes that there is a sufficient supply of good developers with social skills. This simply is not the case; and emphasis on social skills will lead to employees with (on average) worse technical skills. In effect, the skills that are required to do the job are treated as a nice-to-have, while a nice-to-have is treated as a requirement.

    When compromises must be made, they must be made with the lesser evil and the greater benefit in mind.

    (I stress, again, that the definition of “social skills” is also typically a naive one—often even limited to “pleasant to spend leisure time with”.)

    A related problem is the abomination “Internetaffinität” (and some similar formulations). Not only is this a highly dubious use of “Affinität”, which should prompt any school teacher to reach for his red marker, but the compound (with the obvious translation “Internet affinity”) does not refer to something of value: What is typically meant is (depending on who wrote the ad and the exact position) either “can use Outlook and IE without assistance” or “is a hip layman; has Facebook/MySpace/Twitter accounts, and is the first to jump onto the bandwagon of the next Internet hype”.

  7. On occasion, a photograph is required, and it is usually recommended—but what does a photograph have to do with anything?

    For a receptionist or a salesperson, it would be an understandable requirement. For a software developer? No!

    Software developers should be hired based on the inside of their heads, not the outside. Going by the outside introduces unnecessary random factors—and can even favour poor candidates: As discussed above, many good software developers give their looks comparatively little attention; and poor hair-cuts or long hair, glasses, and unshaved faces are common; even unkempt beards occur.

  8. Many adverts ask for a degree in “(Wirtschafts)-Informatik” (where “Informatik” corresponds to computer science, and “Wirtschafts-Informatik” to business informaticsw).

    This may seem sensible at a first glance, but has at least two issues:

    Firstly, it is over-inclusive—“Wirtschaftsinformatik” is a soft option, and, in my experience, the graduates are often useless (exceptions occur, however): They are on average less intelligent than real computer scientists. They lack a true knowledge of both computer science and business—while often being unaware of this flaw, themselves, and demonstrating that “a little knowledge is a dangerous thing”. Some of their courses are just a few steps short of underwater basket weavingw (a good illustration is given by my discussion of formal qualifications).

    Secondly, it is over-exclusive—people coming from math, physics, or other harder subjects, very often make better software developers than computer scientists. This applies to an even higher degree where software architects are concerned. It is true that they start with a disadvantage in raw knowledge, but they are typically more intelligent, better at abstract thinking and problem solving, more likely to actually do the reading that develops them further, and so on.

    The choice between a mathematician and a “Wirtschaftsinformatiker” (other criteria like GPA assumed equal) is a no-brainer: The mathematician.

  9. Overuse of buzzwords of various kinds: Apart from the fact that the concepts behind buzzwords often are over-estimated, trivial, misunderstood, one-day flies, or similar, there is the rather major problem that many people who, e.g., work with a particular paradigm are unaware of the corresponding buzzword—or think that it is not something worth mentioning.

    In the 90s one of the big things was “client–server”—which is not in anyway overestimated, trivial, whatnot, but exceedingly useful. Indeed, I worked with client–server concepts and setups all the time. The phrase “client–server”, however, was only mentioned once in a blue moon—and then typically by some marketing/sales guy or a manager. We developers had about as much reason to talk about client–server this-or-that as we did discussing the air that we were immersed in and dependent on.

    The same applies to many other phrases found in adverts (or that human resources naively use to filter their applications), including the current hype around SOA. In fact, even years before the hype started, SOA was something that was used in the companies I worked in (if possibly in a more rudimentary and undeveloped form)—as a natural development of client–server and separation of concerns.

Ideas of application “experts”

More generally, self-proclaimed application experts have many odd ideas (often contradicting each other), including promoting language that is so obviously “adverty” that I, were I doing the filtering, would likely throw an application using it into the waste basket without further consideration. Others give trivial and highly unhelpful tips, e.g. to replace “graduated” with “graduated summa cum laude from Harvard”: If someone had a summa cum laude degree from Harvard he would have used the latter formulation in the first place; if he barely graduated, at all, from Hicktown Community College, the advice is useless.


I have two Masters with first-rate grades myself, but rarely mention them in the cover letter: Almost all colleagues I have worked with over the years have had at least a Master; most positions I have applied to have required a qualified degree; and details, bragging about grades, and similar, can definitely be saved for the CV in such circumstances—unless the applicant is freshly graduated. It should also be born in mind that formal qualifications are of limited value.

The one physical book I have read on the topic (“Sure-Hire Cover Letters” by Robbie Miller Kaplan) consisted mostly of a series of before-and-after combinations—where I, personally, found most “before” versions better than their “after” counter-parts... This excepting, obviously, those using naive re-writes of the “Harvard summa cum laude” kind.