Summary:

  • Compare and contrast the actions of a successful and an unsuccessful candidate
  • Develop a feel for making a lasting impression when applying for a new position

Two candidates, one goal: a software engineer job offer in a tech startup. Both candidates have had an equally successful track record. One of them had no chance of getting the job. The other one got an offer above his market value.

On the surface, there was not too much difference between the two applicants. They even spent close to equal effort on preparing the application package. Yet, the contrast between them will soon become evident.

Matt crashed and burned during the interview. He couldn’t believe his bad luck once he was escorted to the exit. He thought, everything went really well until he got a question that seemed so easy at first. On his way home, he probably wondered why he had kept getting questions he had had a hard time answering, and hoped to be lucky one day.

Dave not only got the job offer with ease. He also got a higher starting salary than the top of the range budgeted for his position, and a career path to become a lead developer. In some sense, Dave was very happy with the offer, as he passed an interview once again. On his way home, however, he wondered which of his three offers is the right one for him.

Why does Dave keep getting the best possible offers, while Matt gets eliminated all the time?

Observing the situation from different angles, at the end of this article, you will also conclude that success leaves clues. Sometimes it is brutally evident why one candidate has a hundred times more chance of getting a job than another one, even if the successful candidate asks for a significantly higher salary.

The Process

For the sake of simplicity, we will focus on the following aspects of the application process:

  1. Application package
  2. HR interview
  3. Homework assignment
  4. Tech interview
  5. Negotiation style

We will analyze each aspect one by one, and compare the performance of the two candidates.

All companies have different application procedures, and different interviewers look for different mistakes. Please don’t treat this case study as the ultimate truth. I do encourage you though to draw some generic conclusions based on common sense.

Application Package

Both Matt and Dave did a good enough job to get noticed. They demonstrated relevant experience in their resumes.

Matt had more experience, but less relevant experience. The only thing worrying me about Matt’s application was his pride in counting the number of months of experience in his field of expertise.

Beyond a certain level of familiarity, years of experience does not correlate with performance. There have been multiple studies about this phenomenon. For instance, in the book Peopleware: Productive Projects and Teams, written by Tom DeMarco and Timothy Lister, Coding War games have been analyzed. People with ten years of experience did not outperform people with two years experience in their field. Correlation between performance and familiarity only started forming below six months of experience.

In my post Design your Career – Become So Good They Can’t Ignore You, I referenced the rule of ten thousand hours of deliberate practice, following the books Outliers (Malcom Gladwell), and So Good They Can’t Ignore You (Cal Newport).

Years of experience do not show the amount of time spent on deliberate practice, leaving your comfort zone, and deep work. Some enthusiasts practice four hours a day, 300 days a year. In two years, they gain 2400 hours of deliberate practice under their belt. Including four years of intensive studies at a university, the best students may have already collected ten thousand hours of deliberate practice.

A more relaxed developer may spend a hundred hours of deliberate practice per year in average.

Therefore, assuming that both Matt and Dave had at least six months of relevant experience in their specialization, I was fine with the result. None of them were junior developers anyway.

I kept Matt’s month of experience counter in mind though, as it was clearly an out of line metric.

I recall reading another developer with five years of experience, claiming that he has had an experience of writing more than 100.000 lines of code throughout his career. This statement is equivalent to a body builder saying that he has eaten three million kilocalories of food throughout his career.

If you mention the number of years of experience in too many places, chances are, people interpret it as explicit influence. Can’t you see that I am good? Shall I mention it once more? Write it down please. I am good!

The resume of Dave was significantly more compact. He wrote everything that seemed relevant to us, and left out the skills that didn’t matter. After all, enumerating Microsoft Excel, a Drivers Licence, knowledge of Haskell, a programming language mainly for universities, did not increase Matt’s chances. The same holds for a detailed description of a project that has little to no relevance to the position. Less is often more.

The cover letter of Matt was all about bragging. It ended with “Because of my six years of experience, qualifications, and accomplishments, I believe I will be a valuable asset to your company”. This was the one and only place where he mentioned our company in his cover letter.

Dave was a lot more easy-going, down to earth and friendly. He was also quite informal. He expressed how happy he was when he read our job ad, as he always wanted to work in an environment, where he could utilize his specialization to its limits. The cover letter sounded like a message from someone who genuinely cares about finding out whether we can work together.

I researched their LinkedIn recommendations and their GitHub profile too. Both of them were cutting edge. Matt seemed to have more dummy projects on GitHub. Dave, however, collected several hundred stars on an open source repository, and it later turned out that a company is using this repository commercially.

Matt had a blog with five short articles. It is always great to have a blog in general even if it is not cutting edge. I was lacking quality though. It looked as though Matt created a blog just to showcase that he had a blog. I personally still judged his blog as something positive.

Dave had a portfolio site, showcasing his open source contribution, including some demos. He also wrote about his mission in life. Very interesting read.

All in all, both Matt and Dave were interesting enough from a technological perspective. Dave clearly took the lead, but none of them have delivered anything so far.

HR interview

Matt continued applying explicit influence. He was emphasizing his own accomplishments, and his role in the projects. He had little to no questions about the company, or about the products the company is offering.

The conversation seemed to be a formality. Matt didn’t seem that interested in anything outside work. He also mentioned that his number one interest is to develop his own abilities.

Near the end of the interview, Matt started asking about overtime policies, the rules of booking leave, and benefits associated with the role. He said this information was important to him, as he was stressed about getting too much work in the past, and he is looking for a balanced life.

Matt didn’t really bother revealing his personality. He kept his style professional. After all, this interview was more or less a formality for him. He did inquire about the next steps of the application process. At the end, both the HR manager and Matt left the interview room relieved that it’s over.

At this point, some HR managers already show the door to even the best professionals, justified by lack of interest in the company. Matt did not make a lasting impression on the HR manager. His position was barely strong enough to get away with his attitude.

Dave came in ten minutes late. He apologized for not being on time, and assured the HR manager that he does not have a tendency of coming late.

Coming late happens to all of us once or twice in extreme situations. Once I remember I was almost half an hour late from an interview due to a traffic accident. Things like this happen. The worst thing that can happen to you is losing focus. Finding excuses and explaining yourself in detail is quite useless. Apologize, ask your interviewer if it is all right to continue the interview, and do your best afterwards. If an external condition blew your chances, tough luck, you have to take responsibility even for things you cannot directly influence.

Dave could continue focusing on the interview, and started asking question after question about the company. The HR manager was genuinely surprised by the avalanche of questions, and she felt the interview was turned upside down, and Dave started interviewing her.

After a while, Dave announced that he believed in balance, so even though he had other questions, it was now the HR manager’s turn to take the lead. Despite giving up the lead, the interview seemed rather a gentle conversation.

There is a major difference between faking interest and showing genuine interest. Dave was indeed curious about the company, his future position, and his colleagues, including the HR manager he was talking to. Instead of being pushy, and trying to make an impression, Dave was trying his best to gather as much information as possible to decide if the job was the right position for him. In some sense, he was the prize to be won, and companies were the ones bidding on his services.

After the interview, the company already had a great impression on Dave. Even the tech leaders were rooting for him to pass all the hurdles of the interview.

When it came to Matt, he did the necessary minimum to pass all tests. His qualifications and experience showed he was the right fit, yet, he clearly did not go the extra mile.

Homework assignment

Both candidates did an excellent job in developing all the requested features. Matt was very quick, he knew what he was doing. His total time spent on the task was one and a half hours after downloading the assignment. It took Dave three and a half hours to complete the same task.

Matt understood the specification correctly, and implemented all features adequately. The features were more or less robust, there were just a few small bugs here and there, and one major bug that he overlooked.

Observing the code, Matt clearly had some difficulties with some of the more complex features. It looked as though he wrote some of his methods based on trial and error instead of having a battle plan in advance. The result was bloated code, and long methods.

The following quote is from the book Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin.

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.”

The danger comes with high cyclomatic complexity, i.e. a high number of possible execution paths within a method. A lot of branching in fifty lines of code is very hard to understand, even with comments. The only reason why it makes sense to write a long function is if you write a lookup-table, or you define long data structures.

When it comes to comments, they were rather used as notes for the developer, not notes for others. There was no generic commenting style in the application, and there was a clear absence of comments where they were needed.

Documentation was also fully missing. Even though it is not a requirement, documentation can sometimes save time. For instance, instead of implementing an obvious chunk of code handling an edge case, it is possible to just document the expected input format, and list the full solution as an improvement suggestion that you are ready to complete upon request. The developer saves time, and the interviewer will know the absence of a feature was not due to negligence or lack of awareness.

All in all, Matt barely passed another hurdle once again. After all, he completed all features quickly, there was no reason to reject him. However, by now, both soft skill warnings, and warnings on problem solving skills have surfaced. These warnings will be examined during the interview.

Dave failed to implement the last feature even though he was asked to complete all features. He wrote in the documentation that he omitted it on purpose, but he is willing to implement it in the upcoming version in case the rest of the code was not convincing.

The documentation of Dave was flawless. Installation instructions, assumptions and software design considerations made it very clear that there was a smooth thought process behind the implementation.

Dave claimed that he practiced acceptance test driven development during implementation. Indeed, all the tests showed intelligent design. I quickly recalled, Matt did not even write any tests. Both Matt and Dave mentioned test driven development in their skill-set. Yet, Dave made it clear in his mission that he is always targeting 100% test coverage. Once I saw the task, I concluded, these were not empty words. He provided test coverage even when he was not asked to do so.

All the implemented features were flawless. I spent ten minutes trying to break the solution with irregular inputs. I tend to do this monkey-test as a habit, and this skill has come very handy throughout my career. Astonishingly, I could only detect one small inconsistency. I could not even clearly call it a bug. I noted this inconsistency for future use, before examining the code more deeply.

The code itself was very well organized and consistently commented. It was obvious for me to understand the code even without comments.

“One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.” (Robert C. Martin – Clean Code)

After all the investigation, asking for the missing feature did not make much sense. Dave has demonstrated his approach towards craftsmanship already.

Tech interview

Things looked very gloomy for Matt at this point. Matt would not have the best chances even if he was the only candidate. In case of Dave, we were not sure if we had the best chances to get him on board.

The objective of Matt’s interview seemed to be to determine if he is a good enough backup option in case Dave turns us down.

The objective of Dave’s interview was rather to convince him that his skills would be utilized to their peak, and he can gain more than enough career capital with us, meaning that he can grow faster with us than without us.

Throughout my career, I have been both in Matt’s shoes and in Dave’s shoes multiple times. Believe me, once you get to cutting edge, interviewing will become a whole new experience for you. If you are not there yet, don’t worry! You are reading the right material, as my mission is to take you there.

Let’s get back to Matt’s interview. Matt’s impression was clearly that he had nailed all hurdles so far. He seemingly arrived with confidence. Narcissistic confidence to be exact.

I asked Matt if he had any questions. He had a few about or technological stack, then he asked about our development methodology. So far so good. Then he asked a question about overtime, followed by a question on performance review periods. His last question was about perks such as getting budget for a conference.

These questions revealed his selfish nature. First, he was looking for comfort, then he was looking for rewards. Don’t get me wrong, being selfish is absolutely all right, as long as you can offer enough career capital in return. Some degree of selfishness is inevitable, both for your private life, and for your professional life. Just recall your flight attendant before taking off: “Once the oxygen masks fall, help yourself before helping others”.

Does Matt have enough career capital to offer? Let’s find it out! The first question was on one of the smaller bugs he had in his homework. Instead of focusing on the solution, Matt focused on apologizing. He expressed how much he dislikes these bugs, and that he tends to catch such errors normally. I told him it was all right, as all of us make mistakes, and asked him to correct it in the code.

I showed him another small bug, then the most significant bug in his code. Apologies became more and more uncomfortable. Matt quickly realized that his chances were getting worse. As I was aware of how Matt was narrating these events to himself, I told him not to disappoint himself, he was still in the game for the position. Sometimes, even candidates require some coaching on the spot.

Unfortunately for Matt, the major bug was a hard nut, and it took him twenty minutes to fix it. It was very alarming to me that he did not log information that helped him, he rather treated a thirty line long method as a black box. He tested multiple modifications at once. He was in fact very lucky to have fixed the mistake without introducing two other bugs as a side-effect. Having observed his thought process, I gave him one last chance to prove himself.

This chance is a very interesting interview question, requiring nothing else, but problem solving skills. If you are interested in this task, I am conducting free simulated interviews, where I give you feedback on your thought process and level of maturity on the spot. This opportunity alone will significantly increase your chances on understanding how to apply deliberate practice in your profession, and how to get to cutting edge.

Getting back to Matt, even though he had all resources available to him, he could have googled anything he wanted, and he could have asked me questions, his problem solving skills were simply not there. His started overcomplicating his solution, and he fell into his own trap. He did not have enough career capital to offer in exchange for the position.

Matt received feedback on the spot. He would not have gotten the position even if Dave had not been hired. From the perspective of Matt, it may be hard to understand this decision. However, from the outside, it was fully obvious.

The question was now if Dave will end up taking the position. We spent the first half an hour on introducing each other, and then Dave took control of the interview by kicking off a conversation about leadership style in the company, used technologies and methodologies, and he even showed interest in the history of the team.

After half an hour of chatting, I was convinced his lexical knowledge was amazing, as it was developed out of interest.

We then moved on to talk about the homework assignment. I presented the one bug to Dave. He said, “nice catch”, smiling. He jumped into his test suite, wrote a failing test, and corrected the code within a minute. Once his test passed, he showed the application in action. This process assured me that not only the bug was fixed, but no other tests signaled any other failures after the change.

The problem solving task was similarly easy for him. Dave explained his approach, and translated his thought process into working code within five minutes.

The rest of the interview was a formality. We solved some problems together that I had encountered during work. Dave only got stuck in one problem, but even then, he demonstrated a brilliant thought process, and contributed to the solution. Matt did not even reach this phase of the interview.

Negotiation style

Matt did not have a chance to negotiate an offer. The only thing we know is that he was fishing for perks during the interview, and he was trying his best to limit his own risks such as overtime. He often demonstrated his worth based on explicit influence, expressing what he thinks about his own experience and knowledge. However, when it came to implicit influence, when it was time to shine, career capital was missing.

Dave was an assertive negotiator. He did not use techniques such as not revealing his salary until we expose our range. Instead, he exactly knew his value, and had a very good idea about our ranges too. He would have even been ready to name all the sources of his research in case his numbers hadn’t matched ours.

All Dave said was “I am aware I am targeting a high salary, and it might be slightly outside your range. With my position and experience in this area, 20% of all developers get this salary or higher. If you choose to hire me, I will make sure I will do my best to justify the slightly higher costs.”

As an added benefit, we talked about his ambitions during the interview. Dave expressed his interest in leading a small team. Although he did not get a guaranteed role, he got two promises: a performance evaluation within a year, and a project he can take charge of. He also got full access to our leadership training.

Dave got the offer. While you are wondering if he took it or not, I would like to reframe your thought process to think about your own situation. Would you like to be like Matt or Dave? Think about one thing that you can do right now to improve your chances. I encourage you to start developing momentum today.

You will most likely attend some interviews sooner or later in your career. You may even negotiate a higher salary with your existing employer. I will help you with the Professional Software Developer’s Roadmap to an Effective Salary Negotiations. Sign up in the form below, and get the guide!

Get hired faster with the Career Speed Guide!

Chances are, you are leaving money on the table.

Download the Professional Software Developer's Roadmap to Effective Salary Negotiations.