What are technical interviews based on?

🤓 What are the technical interviews based on?

They are usually interviews with a senior engineer, with an estimated duration of 45 minutes to 1 hour and a half. These tend to involve "puzzle" like questions and aim to test your algorithmic problem solving skills.

It is quite common for the interviewer to give tips during the interview, but this will show how much experience you have as a programmer, this could affect your categorization in his/her "competence" scale and impact how much salary you will receive. For example, an engineer could indicate having 10 years of experience and be classified as a “senior” while working in a startup, but when interviewing for a company with a broader and stronger engineering culture, they may be accepted under a "junior" or medium level category. This way of categorizing programmers is generally given according to their performance during technical interviews.

📈 Why is it good to know this?

Because answering technical questions is difficult, and it should be difficult. Given the nature of work it is important for the interviewer to know how the candidate thinks while solving a problem s/he has never seen before. Generally speaking, your performance will demonstrate your mental agility and how much practice you have performing this type of work.

These types of interviews also allow the engineer to focus on the logic of the problem and not on the code syntax since the problem is usually done on a blackboard before, if time permits, it translates to code that will be run in the compiler. It is completely acceptable for the code written on the board to not be 100% syntactically correct - nobody expects that. You are also not expected to write code such as getters / setters, boilerplate tests, etc. Only the functionality. Another of the great benefits of this is that it forces the interviewee to verbally explain their train of thoughts when solving a problem, something that programmers are not often used to doing.

For companies of any size, it is very expensive to hire “false positives,” programmers who have not been interviewed cautiously and have therefore passed the interview without the neccessary skills. These false positives require extra training and therefore are very expensive process for companies, since an engineer is not expected to be productive until after a few months. If you add the time it takes to train someone technically, it is difficult to justify hiring. For this reason, companies prefer to occasionally lose “good” engineers with this type of interviews, rather than let in many who would not be very useful in the short/medium term.

Generally the criteria on which the technical interviews are based are the following:

• Analytical skills: Did you need a lot of help to solve the problem? How optimal was your solution? How long did it take you to reach the solution? Did you structure the problem well and think about what different solutions could have been better?
• Programming skills: Could you successfully translate the algorithm to the machine? Was the code clean and organized sensibly? Did you think about possible mistakes?
• Fundamental knowledge of computer science: Is there a solid base in information technology and technologies relevant to the work to which s/he applies?
• Experience: Have you built challenging and interesting projects? Have you demonstrated initiative, curiosity and other important factors in past projects? What technical decisions (good or bad) have you made in the past?
• Adequate culture: Does you fit the culture and communication skills? Do the values ​​and personality of the individual align with those of the company and team? How did you communicate with the interviewer?

It is important to know that each company and role will give different weights to these areas.

❗️ Why do some candidates think they don't need this?

Because if they had time they could google the answers and resolve it eventually, but the goal is to verify how effective and trained the engineer is to face new algorithms. Companies are interested in knowing that it won't take you many hours to solve an easy problem, or that you don't have the ability to solve a bigger problem.

Very rarely in a work environment data structures such as Binary Search Trees or BST are used or they re-implement algorithms such as MergeSort. Knowing how data structures intrinsically work is indeed useful. This knowledge in the real world is not common, but in the occasions that are presented they are really valuable. This type of knowledge can be learned if necessary, but how do you know that you have to use a BST if you don't know it exists?

Many engineers argue that there is a correlation between these skills and being a good engineer. This means that the engineer has gone through computer courses or has learned these subjects on her/his own, which in both ways is a good sign. It also turns out that most of the technical conversations at work revolve around these basic concepts, and it is rare to ask problem-solving questions without having to involve basic concepts of algorithms.

Each company selects its questions randomly and usually renews them according to a certain periodicity. So you should not expect to find the questions on this list, rather you should expect to be able to practice, learn key fundamentals and possibly find optimal solutions that would have been achieved by your own thinking.