Recruitment

10 Reasons Why You Won’t Get That Developer Job

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

You answered all the technical questions perfectly. You have solid experience with some shiny projects and companies in your resume. Your financial expectations are reasonable. Still, someone else will get the job. Why???

alone photo

I participated in tens of recruitment processes as a developer. Then I hosted even more when hiring to my teams. Based on that experience, I am listing the 10 not-so-obvious reasons for hiring managers to reject your application.

If you’re a developer, they may help you understand the reasons behind rejection. If you’re a manager, you may consider some of the below when recruiting for your team (and avoid the others…).

1. You are not likable. We spend a lot of time at work, so interactions with our co-workers may have a significant impact on our general happiness. Managers know that, and many prefer to hire a solid, but not great developer that has a friendly, positive attitude, rather than a top performing jerk.

2. You are too smart. A good manager will not hire an overqualified candidate, to avoid their disengagement with too simple tasks. A bad manager will not hire them from the fear of being ‘overthrown’.

In both cases, you should be thankful for it and look for another place.

3. You are too confident. If you’re acting arrogant during an interview – when people usually try to control their behaviors – what will happen once you’re faced with serious problems during actual work?

4. You are not the best match. Building a team doesn’t just mean ‘let’s hire the top X candidates that apply’. It’s a complicated process that requires some strategy, balancing the skillsets, experience, career aspirations etc.

The company might decide that the most skilled candidate isn’t necessarily the best one for the current gap – they might need someone more junior, or focused on different types of projects, with different ambitions and goals. What you can do is try to fully understand the need, and – if you still think you’re a good match – justify it clearly for the hiring manager.

5. You complained about your previous employer. This is a red light for many interviewers (whether that’s smart or not is a different discussion). They immediately start thinking of you as a complainer, or someone not trustworthy, who will spread gossips and negativity.

6. You didn’t show respect. Everyone needs to feel respected. A manager won’t hire someone who is not acting properly towards them or other employees. Even if you say something inappropriate by pure mistake, it’s likely they will notice and remember it.

7. You lack a good ‘why’. If you are unable to clearly explain the motive for seeking a new job, it will usually be assumed you’re going after money. And unless they are the highest paying company, they will be afraid you’ll do it again soon, or that you won’t be fully engaged in your duties.

8. Your resume doesn’t tell a story. This one is especially difficult to understand for many job seekers. Most managers aren’t stupid (no, really!) and they often realize that candidates may have a carefully-crafted answer to the previous question, so they look at their employment history in more detail.

Do your past job transitions make sense? Do they fit the bigger picture of declared career goals? Do they tell a consistent story of a growing developer? Be sure to analyze your resume from this perspective.

9. You weren’t honest. That’s an obvious one. If they spot you lying, or notice some signs of hiding information, that’s a red light. A good manager will prefer to know the ugly truth. If you made some bad decisions in the past, but are able to speak openly about them and explain what you’ve learnt, that may even be an advantage.

10. You are changing jobs too often. Some managers treat this very seriously, others – not so much. Some companies won’t even invite a job hopper to an interview. Project situation might affect this as well – if they are seeking someone to help with an urgent, critical initiative, they might not be too worried of the risk of losing you soon after.

However, if you are a job hopper, this will be one of the most common reasons to get rejected, regardless of your skills and personality.

 

Would you add anything to the above list? Feel free to leave your thoughts in the comments.

 

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard
Development Process, Technical Leadership

FAQ for Your Project Manager

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

I decided to summarize some of the most frequently asked questions that I’ve been receiving throughout my career as a development team leader or manager. They usually come from project managers and product owners, sometimes also from stakeholders or customers.

I believe many of us often need to respond to the below, so putting these all together might save us some time. Feel free to copy & paste the answers as needed!

questions photo

1. Why is such a small change taking so long?

  • What might seem as a small tweak, can sometimes require re-designing a part of a system, if we didn’t originally predict that this particular aspect might need to change. And no, it’s not possible to predict all possible changes. Even if it was, you wouldn’t be happy with the cost…
  • Aside from making the code change, we have to test it, ensure it doesn’t affect anything else in the system, deploy it and verify in various environments (development, test, staging, production). No, we can’t take shortcuts if you don’t want to risk a major production failure.
  • Even when making tiny changes, magic can happen and we are never able to predict the impacts with full confidence. That’s just the nature of software development.

2. Why is it so expensive?

  • As developers, we have to take many aspects into account: code quality, security, performance, scalability, maintainability, usability and more. All of these require attention from the team. We have to plan for those concerns, verify them, write automated tests, etc.
  • Yes, we are putting business value as our top priority. We’re just not thinking about today’s business only. What will be the business value of the software if it stops working after the database exceeds 100K records? Or when hackers bring the website down? Would you accept a huge cost of future enhancements if we take design shortcuts today?

disaster photo

3. Are you sure it’s bug-free?

  • No, and we can never be sure. Even worse – every larger piece of software has bugs. That’s just one more thing to accept in this industry.
  • There are many factors that can cause issues, code is just one of them. Some of the other ones are: network infrastructure, server and client hardware and software, system integration mechanisms, web browsers, etc.
  • We are using tens or hundreds of third-party components. Each of them may contain bugs. No, we cannot get rid of them if you want the release to happen this decade.
  • Even when all the other components are fine, there’s a risk that we missed some edge case that nobody ever thought of – not even the analysts or the users.

4. Why can’t you just add more resources to finish earlier?

  • First, developers are not resources. They are not interchangeable, and you cannot easily add or remove them with proportional impact on the results.
  • Recruiting developers can take a long time. If we hire the wrong person, the impact on the project could even be negative.
  • Training developers takes time. The more complicated the system is, the longer it will take before a new person is fluent on the project. And they will make more mistakes that will need to be corrected by other developers.
  • All of these require time investment from the team, which will leave less time for growing the product. That’s why you won’t usually get any short-term benefits. Oh, that next month’s release you wanted to speed up? Better move it till next quarter.

5. Why can’t you tell me when it will be done?

  • We can estimate, at best. We can never predict with full certainty.
  • As explained, even the smallest and simplest change can have unpredicted complications.
  • Every task is a bit different. Even when building similar features for the same application, the related code areas might have been designed differently. Until we start working on them, we won’t fully know what lies beneath.
  • Even if tasks were identical, people working on them can vary in skills and experience. The differences in development time between team members can sometimes be an order of magnitude.

building photo

6. Why are you less productive than that other team?

  • How do you know that? How can you measure that? How do you define ‘productivity’ at all?
  • Every team is different – different people, skills, experiences, distractions, additional duties, etc.
  • Each team may be following a bit different set of practices, which have an impact on development time, as well as quality of the final product. For instance, some teams write unit tests, which increases development time, but also improves the system’s long-term maintainability (when applied properly).
  • Every system is different. One could be based on more problematic technology stack, have poor design, less readable code, etc. Or, quite contrary – it might actually be designed in a better way, having better security or scalability, at the price of more expensive future enhancements.

Are you getting similar questions frequently? Or maybe you have other typical examples? Please share your thoughts in the comments.

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard