Wow, technical interviews! It’s like hopping into a time machine and teleporting into the future, isn’t it? You prepare so hard, master your code, but when that first question appears, it’s as if all the disks in your brain get formatted. I’ve experienced it too, many times. Sometimes, you confidently think you know an algorithm, and suddenly you forget everything, especially at crucial moments… Anyway, in this article, I will share insights based on my experiences and common knowledge on how to approach this monster called a technical interview more prepared. By the way, just recently, a friend of mine told me about a job application where they grilled him with an algorithm question during the interview. The result was disappointment. But we learn from it.
What we call a technical interview is not just about coding skills. It’s also about problem-solving ability, thought process, and even how well you can adapt within a team. So, it’s not enough to think, ‘Aha, the answer to this problem is C#.’ They ask questions like, ‘How would you approach this problem? Where would you start? Which data structures would you use? What about time and space complexity?’ The answers to these questions can actually change depending on your panic level at the moment, I guess. 🙂 But don’t worry, all these questions have a logic behind them.
Let’s start from the basics. Data structures and algorithms. Without these, a technical interview is like soup without tarhana. Arrays, linked lists, stacks, queues, trees, graphs… You need to know what they are used for, and when to use which. Sometimes, there are many ways to solve a problem; being able to choose the most efficient way depends on a solid understanding of these data structures. For example, if you’re going to perform a search. If the data is sorted, binary search is incredibly fast. But if not? Then you need to consider other methods. Also, when it comes to algorithms, knowing them isn’t enough. You should understand their complexity. The Big O notation should be your compass. It helps you grasp how an algorithm’s performance changes as data size increases. Sometimes, your code runs perfectly on your laptop but crashes when millions of users access it—here, Big O plays a role. Time complexity and space complexity are fundamental.
Now, moving on to coding. Usually, in interviews, you are given a problem to solve in a specific language. Regardless of the language, the core principles are the same. Write readable, maintainable, and most importantly, correct code. I usually develop REST APIs with C#/.NET and Dapper, so I will give an example from this perspective, but the logic applies to other languages as well. Sometimes, you need to send data to an API endpoint. For example, registering user information.
Let’s think about a scenario: You want to send data from a Vue.js frontend to a C# REST API. At first, you tried a simple POST request but couldn’t get it to work. The error messages weren’t very helpful either. It says ‘Request body is empty,’ but you are sending data, so what’s going on? Here, understanding how Dapper or ORMs generally work becomes essential. Perhaps the data isn’t parsed correctly or the server parameters don’t match. First, you would check the data sent from Vue.js. Is the JSON format correct? Are the field names identical? Then, check if the backend controller’s action method receives the request body properly. If you are using Dapper, verify your SQL query is correct. Do the parameters match? Sometimes, I’ve encountered a situation where I was sending data but getting an empty response back. It turned out I had omitted a parameter. It was such a simple mistake that I was furious.
Let’s move to the code example. Suppose you’re sending a username and password from Vue.js. Your initial attempt might look like this:
// WRONG ATTEMPT: Sending only parameters directly. [HttpPost] public async Task<IActionResult> CreateUser(string username, string password) { // Sending data to database // ... return Ok("User created."); }This approach might not work sometimes, especially when sending complex objects. The data might not be received correctly. The correct way is usually to define a DTO (Data Transfer Object) and bind the incoming JSON directly to it. This makes the code clearer and easier to debug.
Proper approach:
// CORRECT APPROACH: Using DTO to accept data. public class UserRegistrationDto { public string Username { get; set; } public string Password { get; set; } }
[HttpPost] public async Task<IActionResult> CreateUser([FromBody] UserRegistrationDto userDto) { if (userDto == null) { return BadRequest("Invalid user data."); }
// Here, you can use userDto.Username and userDto.Password for database operations using Dapper. // Example: await _connection.ExecuteAsync("INSERT INTO Users (Username, PasswordHash) VALUES (@Username, @PasswordHash)", new { Username = userDto.Username, PasswordHash = HashPassword(userDto.Password) }); return Ok("User created."); }
// Note: Password should be hashed before storage. // The HashPassword method isn't shown here for simplicity.
As you see, in the first example, only string parameters are accepted, whereas in the second, a DTO is used. This allows the incoming JSON to be directly mapped into a strongly-typed object. It makes the backend cleaner and the data structure clearer from the frontend. For these types of integrations, you can find plenty of examples on Google. I used to search a lot during my early days. Sometimes, I would watch short videos on YouTube to understand the concepts better.
Also, in technical interviews, you are not just asked to code. Sometimes, scenario questions like 'How would you handle this situation?' or 'What would you do if this problem occurred?' are asked. This is where problem-solving skills come into play. As I mentioned earlier, selecting an algorithm and explaining why, along with its pros and cons, is important. I realized recently that if I hadn't used Dapper, I could have found a simpler solution. Anyway, the main point is that these interviews might seem intimidating but become manageable once you understand the logic and practice a lot. Learn data structures, algorithms, and Big O notation thoroughly. Write code, experiment, and learn from your mistakes. The biggest teacher is your own projects and the errors you make there. I remember times when my code failed, and after hours of effort, I would finally realize it was a small syntax mistake. Hopefully, you don't want to relive those moments.
Also, during the interview, try not to panic. If you can't solve a question immediately, don't hesitate to ask for some time to think. Even discussing your approach with the interviewer, like 'Should I start with this approach or that one?' can be appreciated. Remember, they want to see not only your knowledge but also how you think and communicate. They're not expecting a robot who just writes code. From my experience, even the simplest questions can trip you up—what matters is not giving up and continuing to learn. Like climbing a mountain, the view from the top makes all the effort worth it. Interviews are similar. :) Also, you can find many discussions on Reddit.