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.
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 conforming to the majority” or “pretending to be an extravert”—while other factors, like emotional maturity, which many developers possess to a higher degree than the average extravert, 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.
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 sufficiently similar situation, etc. This would amount to writing one single, high-quality cover letter, and then to 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 might start over from scratch after a longer engagement.
It might be, however and more generally, that the aforementioned recommendation makes sense for sufficiently specific and rare positions. For instance, if someone wants to apply to an upper-management position at a specific company, a very different approach might be needed than for someone looking for a janitorial position with any company that has an opening. Then again, how many cover letters are written for applications to upper-management and how many for other positions?
Another common recommendation 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 that 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.
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, as a Linux user, do not have MS-Office available. 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.
Linux users do, of course, have access to OpenOffice, LibreOffice, and maybe some other set of tools of similar capabilities.
At my last use, many years ago, they were better than MS-Office, but still a far cry from good, with problems including similar usability issues as with MS-Office, a similar insistence on WYSIWYG, and a similar interleaved grouping of applications that might be better put into separate and independent (if potentially cooperating) projects.
To boot, they were far from fool-proof when it came to handling proprietary Microsoft formats, and a “No MS-Office? Just edit that file with OpenOffice instead!” approach was correspondingly problematic.
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.
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 web interface 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 format (or some format that 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, and correcting this can be laborious. Further, the imposed formats often require that individual paragraphs, often even several words, sometimes even a single number, be copied individually; rather than in one single operation. In some cases, it is not even possible 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 candidates. Similarly, a good software developer has a policy of “work smart, not hard” (even if also willing to work hard 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 quality software, accomplished by good thinking and rational work.
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.
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 humans tend to be heavier than short humans, red-heads tend to have more freckles than others, and so on.
In the case of self-confidence, it must also be remembered that the correlation between competence and self-confidence is low or even negative: The highly competent, in virtually any area, tend to be strongly aware of their own flaws and mistakes, what they could do (even) better, where they have knowledge deficits, etc. The incompetent? Not so much. A particular danger in software development is that the incompetent often have glaring holes in their understanding, e.g. concerning the importance of code quality, and are left happy with inferior work. “The code runs and was delivered on time—I must be good!” That the code was shit and will be a future source of bugs, a maintenance horror, hard to extend, whatnot, that does not occur to the incompetent developer.
Further, humility and awareness of own fallibility are much better character traits than self-confidence—and this very generally and by no means limited to software developers. These are traits that should be wanted in applicants.
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; and 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 übernerds—it is not possible to do so with a team of hyper-extraverts 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 “nerd proportion” would have positive effects even in most non-developer roles—while the current trend in the other direction poses a direct danger.
I have repeatedly heard arguments like “In the past, it was enough to know the technical side, but in today’s workplace social skills are just too 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”.)
Then we have abominations like “Internetaffinität”. 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 accounts with the same social-media platforms as I do; and is the first to jump onto the bandwagon of the next Internet hype”.
On occasion, a photo is required. (And application how-tos see it as mandatory.)
But what does a photo 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, if rarely.
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 softer option than “Informatik”, 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—applicants coming from math, physics, or other harder subjects, very often make better software developers than computer scientists. (This applies to an even higher degree when we look at seniors, software architects, and the like.) 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, e.g. GPA, assumed equal) is a no-brainer: The mathematician.
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 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 1990s, for example, 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 might naively use to filter applications), including the later hype around SOA. In fact, even years before the hype started, SOA was something that was used in and by the companies where I worked (if possibly in a more rudimentary and undeveloped form)—as a natural development of client–server and separation of concerns.
More generally, self-proclaimed application experts have many odd ideas (and often contradict 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. (Generally, advertisers, marketeers, “communication experts”, and similar groups seem to be entirely oblivious to how cheap, unconvincing, even repulsive many of their preferred formulations are.)
Trivial and highly unhelpful advice is another problem. Consider e.g. the tip to replace “graduated” with “graduated summa cum laude from Harvard”: if someone had a summa cum laude degree from Harvard, chances are that he would have mentioned it in the first place; if he barely graduated, at all, from Hicktown Community College, the advice is useless or an invitation to fraud.
(However, note that a much more general version of such advice might be legitimate, e.g. to dig down for something that might be a unique selling point, or to put the most positive spin on a given fact that truth allows.)
The one physical book that 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.
I have two Masters with first-rate grades myself, but rarely mention them in the cover letter: Almost all colleagues that I have worked with over the years have had at least a Master; most positions that 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 claim about most colleagues having had at least a Master was true at the time of writing (2010). By 2023, a negative trend of lowering qualifications in Germany, already felt in part back then, has made the statement untrue.
This has at least two components:
Firstly, at least in STEM fields, the “Diplom” family (e.g. “Diplom-Ingenieur”) of degrees used to dominate. These were equivalent to a Bachelor immediately followed by a Master, implying that someone with a tertiary degree usually had (the equivalent of) a Master. However, Germany has switched to a system with separate Bachelors and Masters, with a much lower proportion of Masters as a consequence.
Secondly, the growth of the software industry has lowered the average qualification for almost all positions. Employers might want employees with advanced degrees, but there are too few of those around to fill the need. To boot, many employers fail to understand that software developers are not fungible—in fact, are among the least fungible professionals around. As a result, they might pick someone less-qualified-but-cheaper, which lowers the average education level further. (Of course, cheap-in-the-short-term often ends up as expensive-in-the-long-term, when quality and productivity do not pan out.)
In the overlap between these two components, some deliberately abstain from post-Bachelor studies, because they expect to get the same job anyway—and two years earlier.
(To this, I stress that a more advanced degree is not a guarantee of anything; however, a higher degree and/or a degree in a more brainy field implies a stronger filtering for ability and, therefore, that the degree is a better heuristic. Of course, on another dimension, higher education is being evermore dumbed-down and directed at the masses in Germany too, which weakens the filter effect.)
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.