***My Interview Experience with Tower Research Capital in Montreal*** I wanted to share my interview experience with Tower Research Capital in Montreal for other engineers who may be considering opportunities with the company. I did not apply directly to Tower. A recruiter contacted me on LinkedIn with what sounded like an excellent job description. At that time, Tower Research Capital was new to me. I had not heard much about the company before, but the role looked interesting and technically strong. Currently, I am working with one of the major banks in the United States. The main reason I agreed to explore the opportunity was not because I was actively looking for a job, but because I have family near Montreal. The possibility of being closer to family made the opportunity worth considering. The interview process started with two virtual coding interviews. I passed both of them. After that, I was invited to Montreal for in-person interviews. I was told that I would have interviews with five people, each lasting about one hour. Because I had already completed and passed two coding rounds, I expected the in-person interviews to focus more on senior-level engineering topics. I was expecting discussions around system design, architecture, scalability, production support, data systems, or possibly more advanced algorithmic problems. However, the experience was very different from what I expected. After waiting for some time in a conference room, I was informed that the first interview would actually be virtual. That confused me because I had traveled to Montreal expecting all the interviews to be in person. The interviewer then started with a very basic but tricky Python question. At that point, I was honestly confused. I found myself wondering why I had traveled all the way to Montreal for another basic coding-style interview, especially after already passing two virtual coding rounds. When I answered the first question, I had the impression that the interviewer was going to continue with more tricky Python questions. These types of questions may test attention to detail, but in my opinion, they do not always reflect the level of experience, judgment, system design ability, or real-world engineering maturity expected from a senior developer. The second interviewer, however, came with what I considered a more mature and realistic engineering problem. It was closer to the kind of real-world problem senior engineers actually face. I solved that problem, and I felt much more comfortable with that discussion. However, by that time, I had the impression that the first interviewer had already made a negative decision, and that decision had already influenced the rest of the process. This is one of the concerns I want to share with other engineers. In many interview processes, if the first interviewer does not like you or does not think you are a fit, the later interviewers may already hear that feedback before they meet you. I have personally been involved in many interviews myself. Normally, after each interview or at the end of the process, the interview panel discusses the suitability of the candidate. That discussion is expected. But in this case, it felt different. It did not feel like each interviewer was independently evaluating me. It felt as if the first interview had already determined the outcome. After the second interview, the remaining three interviewers did not even come to speak with me. To be honest, by that point I was already done in my heart. I had traveled to Montreal, reduced my salary expectations, considered giving up an extremely comfortable work situation, and was open to moving into a much smaller and more crowded work environment mainly because I wanted to be closer to family. But the process did not make me feel that the company was equally serious about understanding my full experience and senior-level capabilities. For senior engineers, especially those with many years of experience building production systems, I believe interviews should evaluate more than isolated tricky questions. They should also explore how a candidate thinks about trade-offs, system reliability, data quality, ownership, maintainability, debugging production issues, and working with business and engineering teams. To be fair, every company has its own hiring process, and Tower may have reasons for structuring interviews this way. Also, some candidates may enjoy this type of interview format. But for me personally, there was a mismatch between the role description, the stage of the process, the travel involved, and what I experienced during the onsite interview. My takeaway for other engineers is this: Before traveling for an onsite interview, especially if you are already employed and taking time away from work, ask very clearly what each interview round will cover. Ask whether the onsite interviews will include additional coding rounds, system design, architecture, behavioral discussions, or team-specific conversations. A good question to ask the recruiter would be: “Since I have already completed two coding interviews, could you please confirm the structure of the onsite interviews and the focus of each round? Also, will each interviewer evaluate me independently, or can feedback from an earlier round affect whether the later interviews continue?” Overall, I appreciate the opportunity to interview with Tower Research Capital. The company appears to have strong technical standards, and the role itself was interesting. However, my experience reminded me that candidates should clarify the interview structure in advance, especially when travel, salary trade-offs, relocation considerations, and major career decisions are involved.