Replacing a programmer is slow because the work is invisible and hard to verify before you hire
When a programmer leaves, you cannot just post a job and start interviewing candidates the next day. The hiring process for software roles typically takes three to six months from posting to first day of work. This is not because companies are disorganized — it is because evaluating whether someone can actually do the work requires time that other hiring processes do not need.
When you hire a plumber, you can watch them fix a pipe and see if it works. When you hire a programmer, you cannot watch them write code in an interview and know whether they will write good code on your actual problems. The skills that matter most — how someone thinks through a complex system, whether they write code that other people can read and maintain, how they handle a codebase they did not write — are nearly impossible to assess in a few hours.
This gap between what you can test and what you actually need to know is why the hiring process is long, expensive, and often still produces bad matches.
Key Takeaways
- Finding candidates takes weeks because most good programmers are not actively looking for work and do not respond to job postings.
- Screening and interviewing takes another four to eight weeks because companies need multiple rounds to assess whether someone can actually do the work.
- Background checks, reference calls, and offer negotiations add another two to four weeks after a decision is made.
- Even after hire, a new programmer is not productive for two to four weeks while they learn the codebase and how the team works.
- The total time from "we need to replace someone" to "this person is actually working on real projects" is typically four to seven months.
Why the candidate pool is smaller than it looks
A job posting for a programmer might get hundreds of applications, but most of those people cannot do the work. Someone with six months of coding experience and someone with six years look similar on a resume. Someone who learned to code from a bootcamp and someone who studied computer science for four years both list "Python" as a skill.
Recruiters and hiring managers have to filter through hundreds of applications to find maybe ten people worth interviewing. This filtering step alone takes two to three weeks. Then they discover that half of those ten people took the job because they were desperate, not because they actually want to work on this kind of problem. Another two people live in a different country and the visa process would take months. One person is already in final interviews at three other companies and will accept the first offer that comes.
The people who are actually good and actually available are rare. Most good programmers are already employed and not looking. The ones who are looking often have multiple offers within days. This means the hiring timeline is not just about how long it takes to interview people — it is about how long it takes to find people worth interviewing in the first place.
Screening and interviews take longer than other fields
A company hiring a programmer typically does four to six rounds of interviews. This is not because they are being thorough — it is because each round tests something different and none of them are very good at predicting whether someone will actually be good at the job.
The first round is usually a phone screen with a recruiter or junior engineer. This takes 30 minutes and mostly confirms that the person can speak English and did not lie about their job title. The second round is often a technical phone screen where someone asks coding questions. The third round is an in-person or video interview where the candidate solves a coding problem on a whiteboard or in a shared editor. The fourth round is usually a system design interview where they talk through how they would build something large. The fifth round might be a culture fit conversation with a manager or team lead. The sixth round, if there is one, is often a final conversation with a senior engineer or the person whose job they are replacing.
Each round takes a week or two to schedule because the interviewers have other work and the candidate might be interviewing at other companies. A candidate who makes it through all six rounds has spent 10 to 15 hours in interviews over six to eight weeks. At the end, the company still does not know whether this person will write maintainable code, whether they will ask good questions when they are stuck, or whether they will stay for more than a year.
Testing actual ability is nearly impossible in an interview
The skills that matter most in a programmer are the hardest to test. Can they read code they did not write? Can they find a bug in a system they have never seen? Can they explain their thinking to someone else? Can they know when they are wrong? Can they write code that will still make sense to someone else in six months?
A whiteboard coding interview tests whether someone can solve a problem they have never seen before under time pressure with someone watching. This is not how programming actually works. In real work, you have access to documentation, you can run the code and see what happens, you can ask teammates questions, and you have days or weeks to solve the problem. A person who is great at real programming might freeze on a whiteboard. A person who is good at whiteboard interviews might write terrible code in production.
Some companies try to solve this by giving candidates a take-home project — a small coding task they do on their own time and submit for review. This is better at testing real ability, but it takes the candidate three to eight hours and the reviewers two to four hours to evaluate. It also adds another week to the timeline because the candidate needs time to do it and the company needs time to review it.
Because no single interview method is reliable, companies do multiple rounds hoping that the combination will reveal whether someone is actually good. This is why the process is long.
Background checks and reference calls add weeks
After a company decides to make an offer, they usually run a background check. For a programmer, this is typically a criminal background check and a verification that the person actually worked at the companies they listed. This takes one to two weeks.
Many companies also call references — usually former managers or senior colleagues. A reference call takes 20 to 30 minutes and the reference has to be available. If the reference is in a different time zone or busy, this can take another week to schedule.
The candidate also needs time to negotiate. They might ask for more money, more vacation, a different start date, or remote work options. This back-and-forth can take a few days to a few weeks depending on how much the company is willing to negotiate.
By the time an offer is accepted and all the paperwork is done, another two to four weeks have passed since the decision to hire was made.
Onboarding a new programmer takes weeks before they are useful
The hiring process does not end when someone starts work. A new programmer cannot be productive on day one. They need to set up their computer, get access to the code repository, understand how the build system works, learn what the codebase actually does, and figure out how the team communicates.
For the first two to four weeks, a new programmer is reading code, asking questions, and maybe fixing small bugs or documentation. They are not shipping features. A good team will assign someone to help them — a mentor or buddy — which means that person is also less productive during this time.
Some of this ramp-up time is unavoidable. The codebase is complex and the new person needs to understand it. But some of it is wasted because the company did not prepare. If the onboarding process is not documented, if there is no one assigned to help, if the code is poorly organized, the ramp-up takes longer.
This is why the total time from "we need to replace someone" to "this person is actually working on real projects" is often four to seven months, even though the hiring process itself is only three to six months.
What companies do to make hiring faster
Some companies try to speed up hiring by skipping steps. They might do only two interview rounds instead of four, or they might skip the background check. This usually backfires — they end up hiring someone who cannot do the work or who leaves after a few months, and then they have to start the whole process over.
Other companies try to speed up hiring by hiring contractors or temporary workers while they search for a permanent replacement. This works if the contractor is good and if the work is something a contractor can do. But contractors are also expensive and hard to find, so this does not always save time.
The most effective way to speed up hiring is to start before you need to. If you know someone is leaving, you can start recruiting before their last day. If you have a pipeline of candidates you have already screened, you can move faster when you need to hire. Some companies do this by maintaining relationships with good candidates they did not hire, or by having a standing job posting that is always open.
Another approach is to improve the onboarding process so that new programmers are productive faster. This means documenting how the codebase works, assigning a mentor, and having small tasks ready for them to work on in their first week. This does not speed up hiring, but it reduces the cost of the hiring process by getting the new person productive sooner.
Frequently Asked Questions
Can a company hire a programmer in less than a month?
Rarely. A company might move very fast and hire someone in three to four weeks if they already have a strong candidate in mind, if that candidate is available immediately, and if the company skips some interview rounds. But this usually means they are taking on more risk — they might hire someone who cannot do the work or who leaves quickly.
Why do companies ask so many interview questions about things that do not matter?
Because they are trying to predict whether someone will be good at the job and they do not have a reliable way to do it. Whiteboard coding problems, system design questions, and behavioral questions are all imperfect proxies for real ability. Companies use multiple questions hoping that the combination will reveal something useful, even though each individual question is not very predictive.
What should I do if I am waiting to hear back from a company about a programming job?
Keep interviewing at other companies. The hiring process is long and unpredictable. A company might take two weeks to schedule your next interview, or they might decide to hire someone else and never call you back. If you have other options, pursue them. If you get multiple offers, you can choose the one you want most.
Does it matter if a programmer has a degree?
It depends on the company. Some companies require a computer science degree or equivalent. Others do not care about formal education and only care about what you can do. There is no strong evidence that a degree makes someone a better programmer, but some companies use it as a filter to reduce the number of applications they have to review.
Why do some companies hire programmers much faster than others?
Companies with strong employer brands, good compensation, and a reputation for treating employees well can hire faster because more people want to work there and they can move quickly through interviews. Companies in competitive markets or with poor reputations have to search longer to find people willing to work for them.