Job Interviews in the IT Sector: Complete Guide for Developers

📋 Table of Contents

Introduction: The reality of interviews in IT
Types of technical interviews
How to prepare for each type
Red flags: Warning signs in selection processes
Salary negotiation: Practical strategies
The probationary period: Your opportunity to evaluate
Frequently asked questions
Conclusion and checklist

Introduction: The reality of interviews in IT

As a software developer with years of experience, I have gone through various job interviews. Although I haven’t changed companies as many times as other colleagues in the sector, I have had my fair share of interviews due to my meticulous and indecisive nature. Apart from my experiences, I have also read and heard many stories in forums that show a wide variety of situations in these processes.

In the IT sector, we are very lucky compared to other sectors that face a lack of offers and precarious treatment of the interviewee. However, this does not mean that everything is perfect. We cannot justify certain practices just because it is worse elsewhere. In all sectors, there should be a minimum of respect for the interviewee.

💡 Important fact: According to a Stack Overflow 2023 survey, the interview process is one of the main friction points for developers looking for work, with 47% reporting negative experiences.

Although elsewhere I have seen atrocities such as being offended if salary and vacation time are asked about, citing 20 people at the same time for a 15-minute group interview, or asking about personal relationships, in this article I will focus on IT interviews, I will review briefly and from my point of view the processes that usually exist and the things I have encountered.

Types of technical interviews

Multiple choice exams

One of the types of tests I have encountered has been multiple choice. It was a small consultancy that gave me a generic exam that didn’t have much to do with the job offer. It was a battery of questions covering a wide range of topics, many of which were not relevant to the position I was applying for.

Real example: I was asked about specific Apache server configurations when the position was for a React frontend developer. This demonstrates the disconnect that sometimes exists between who designs the selection process and the real needs of the team.

Why companies use them:

Quick candidate filter
Process standardization
Lower cost than human interviews

Problems:

They do not reflect real programming skills
They favor memorization over reasoning
They can be outdated

My recommendation: If you encounter this type of test and feel it makes no sense, evaluate if that company really values your technical skills or is just looking to “pass filters”.

How to prepare for technical tests

Although I am not a fan of this format, here are strategies if you encounter them:

Review fundamental concepts:
- Basic data structures
- Algorithmic complexity (Big O)
- SOLID principles
- Common design patterns
Practice with platforms:
- TestDome - Technical tests by technology
- Codility - Code tests
- HackerRank - General preparation
Strategy during the test:
- Read the entire question before answering
- Eliminate clearly incorrect options
- Manage time well (don’t get stuck on a question)

Live Coding tests

Live coding tests are a very popular option among many companies, although I do not share the enthusiasm for them. In theory, they allow assessing how a programmer thinks and solves problems in real time. However, the reality is that in a real work environment, a programmer does not have someone constantly watching them, with a timer running and without internet access to search for information or solutions.

The pressure of live coding:

This artificial situation can add unnecessary pressure and does not always reflect a candidate’s true potential. Furthermore, working under these conditions is not representative of a typical work environment, where one is expected to collaborate with the team, consult documentation and online resources, and take time to think and solve problems effectively.

Personal experience: On one occasion, I was asked to implement a binary tree search algorithm in 20 minutes while two people watched me. It turns out that in my day-to-day life I had never needed to implement this from scratch - I use standard libraries. This doesn’t make me a worse developer, it just indicates that they measure academic vs. practical skills.

How to survive live coding

Before the interview:

Practice out loud: Explain your reasoning while coding
Master the environment: Make sure you know the IDE/editor you will use

Prepare a mental template:

// Always start by understanding the problem
function solveProblem(input) {
  // 1. Validate inputs
  // 2. Edge cases
  // 3. Main solution
  // 4. Optimize if there is time
}

During the interview:

Ask before coding:
- “What should it return if the input is null?”
- “Does optimization or readability matter?”
- “Are there memory/time constraints?”
Think out loud:
- “I’m going to use a Map because I need O(1) search”
- “First I’ll do the naive version, then I optimize”

Test your code:

// Example: If you implement a function, test with real cases
console.log(solveProblem([1, 2, 3])); // Expected: ?
console.log(solveProblem(null));      // Expected: ?
console.log(solveProblem([]));        // Expected: ?

Resources to practice:

Pramp - Free practice with other candidates
Interviewing.io - Anonymous simulations
LeetCode - Problems by difficulty

Exercise resolution

Another common practice is assigning exercises or problems to solve within a period of several days. In theory, this allows the candidate to demonstrate their skills in a more realistic context, without time pressure.

Real advantages:

Shows how you structure a real project
You can use your usual tools
You demonstrate documentation skills
Including tests shows professionalism

The ethical problem: However, this practice also has its dangers. On one hand, there are rumors that some companies use these tests to get free solutions for their own pending projects. Although in my case I don’t think they have taken advantage in this way, the possibility of it happening is worrying.

My advice: If you are asked to do an exercise that looks like a complete real project (more than 4-6 hours of work), consider:

Asking how much time they expect you to dedicate
Proposing a simplified solution
Clearly documenting what you did and why

Template for submitting exercises

# Exercise Solution [Name]

## Time spent: X hours

## Technical decisions
- Used [technology] because...
- Folder structure: ...

## Instructions to run
1. git clone ...
2. npm install
3. npm run dev

## Testing
- Coverage: X%
- Tests included in /tests

## Pending improvements (if I had more time)
- [ ] Optimization of...
- [ ] Add...

## Notes
Any clarification on technical decisions

Verbal technical interviews

Last but not least, there are verbal technical interviews. In my opinion, this is the best option for evaluating a candidate. During these interviews, you are asked about the specific technology for the position and how you would solve certain problems, but everything is done conversationally.

Why they work better:

Evaluate real technical knowledge
Show communication skills
Allow evaluating “design thinking”
They are faster and more human
You can ask for clarifications and dialogue

Example of effective question:

“You have an API that starts responding slowly under load. What steps would you follow to diagnose and solve the problem?”

This question allows evaluating:

Debugging knowledge
Experience with performance
Ability to prioritize
Knowledge of monitoring tools

How to shine in verbal interviews

Use the STAR method:
- Situation: “In my previous project…”
- Task: “We had to reduce loading time…”
- Action: “I implemented caching and optimized queries…”
- Result: “We reduced response time by 60%”
Be honest about what you don’t know:
- ❌ “Yes, of course, I’ve used it a lot” (lie)
- ✅ “I haven’t worked directly with X, but I’ve used Y which is similar. I understand that X works…”
Ask smart questions:
- “What stack do you currently use?”
- “What is the team’s biggest technical challenge?”
- “How do you handle code review?”

How to prepare for each type

General preparation checklist

1. Technical preparation (1-2 weeks before):

Review fundamentals of your main stack
Practice basic algorithms (if applicable)
Prepare 3-4 projects to talk about in detail
Have an “elevator pitch” about yourself ready

2. Company research:

Read their technical blog
Look at their stack on StackShare or GitHub
Prepare specific questions about their business

3. Logistical preparation:

Test your camera/microphone
Have backup connection (mobile data)
Prepare water and paper for notes
Arrive/virtually 5 minutes early

Red flags: Warning signs in selection processes

🚩 Excessively long processes

It’s not always like this, I’m not going to generalize, but there are offers that have you interviewing for weeks, long and boring processes, first, second, third and even fourth interview done. All for a job position, I see it as excessive.

Specific warning signs:

More than 4 interviews for a non-executive position
They don’t tell you the salary range after the first interview
They make you wait weeks between phases without communication
They asked for free work (exercise that takes +8 hours)

🚩 Waiting without response

After all this, if you are lucky, the company will answer you. However, I have seen that many times there is no response, which is quite rude considering the time and effort the candidate has dedicated. Although I understand they may have many applications, the minimum would be to inform if you haven’t passed.

🚩 Last minute changes

Processes in IT can be long and exhausting. The ironic thing is that, after all the effort, some companies may reduce the agreed salary at the last minute. Personally, I have rejected offers for this reason. Although changing jobs in IT is relatively simple due to the number of offers, you have to be very careful.

Salary negotiation: Practical strategies

Before the interview

Research salary ranges:

Glassdoor - Salaries by company
Levels.fyi - For big tech companies
Talent.com - Ranges by country/region

Define your number:

Minimum acceptable: €X (to pay bills)
Realistic goal: €Y (improves your current situation)
Golden dream: €Z (great improvement)

During negotiation

Effective phrases:

“Based on my market research and my experience in [X], I expect a range of [Y-Z]”
“I understand the team’s budget. Is there flexibility in benefits like schedule/remote/training?”
“Currently I am considering other offers in the range of [X], but I am especially interested in this project because…”

NEVER say your current number first: The question “how much do you earn now?” is a trap. Answer:

“I am looking for roles in the range of [X-Y]”
“My current compensation includes benefits I value, I am looking for [goal]”

Total negotiation: Remember that salary is only one part:

Flexible schedule / Remote
Training budget
Extra vacation days
Performance bonuses
Equipment (computer, chair, etc.)

The probationary period: Your opportunity to evaluate

Also, don’t forget that when you enter a new company you have a probationary period of ‘x’ months. These months not only serve for you to demonstrate how good you are, but also for you to evaluate the company.

Evaluation checklist (first month)

Technical aspects:

The code is documented
There is real code review, not just “LGTM”
There are tests (even if basic)
You can ask questions without fear
The stack is what they promised

Cultural aspects:

Schedules are respected
There is clear communication
Your opinion is valued
There is no covert “toxicity”

Remember: A job is a job, and it is important to ensure that the company meets your expectations and needs.

Frequently asked questions

How many interviews is normal?

For a mid-level developer position, typical is:

HR Screening (15-30 min) - Culture fit, salary expectations
Technical interview (45-60 min) - With someone from the team
Final interview (30 min) - With CTO/manager

More than 3-4 interviews is excessive except for very senior or special positions.

Should I study algorithms if I’m going to do frontend?

It depends on the type of company:

Big Tech (Google, Meta, etc.): Yes, inevitable
Product Startups: Probably not, more practical
Consultancies: Varies, ask before

My recommendation: Have basic notions (searches, sorts, structures) just in case.

What to do if I get rejected?

Ask for feedback: “Is there any area where I could improve?”
Don’t take it personal: Many times it’s “fit” not competence
Keep the relationship: Connect on LinkedIn, you may cross paths again
Learn: If you detect a gap, work on it

Is it normal for them to ask for references?

Yes, especially in medium/large companies. Have ready:

2-3 previous professional contacts
Notify your references before
Choose people who really know your work

Should I lie about my experience?

ABSOLUTELY NOT. The tech world is small:

It is easily discovered
You can end up blacklisted
It is better to under-promise and over-deliver

Conclusion and checklist

Changing jobs in IT can be an adventure full of traps. It is essential to be meticulous and cautious. I have been lucky to dodge many bullets, but not everyone has the same fortune. Keep a sharp eye and remember that your professional and personal life are worth much more than any trap offer!

✅ Checklist before accepting an offer

Technical:

I have seen the current code (or at least architecture explained)
I know who I will work with (team, not just manager)
The stack is reasonably modern
There is a defined onboarding process

Legal/Economic:

I have the offer in writing
The salary is clear (gross/annual)
I know what the probationary period is
I understand the contract clauses

Cultural:

I have spoken with someone from the team (not just managers)
I know what the remote/hybrid policy is
I understand schedule expectations
I have seen the facilities (or at least photos) if on-site

Post-acceptance:

I have confirmed start date
I know who my “buddy” will be the first days
I have access to basic documentation

A hug, and good luck in your future interviews!

Was this guide useful to you? Share it with someone who is looking for a job. Do you have an interview experience you want to share? Leave it in the comments.

What do you think?

Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .