Positive first two rounds, but a disappointing final technical interview I interviewed with Kinaxis for an Operations Research position. The process began under the title Architect, Operations Research, but during the process I was asked to continue for a developer-titled role that was also focused on operations research. The first round with the hiring manager was a strong and substantive technical discussion. We discussed the team’s work on supply-chain optimization, including the transition from heuristic approaches toward MILP formulations and the challenges of scaling large optimization models. The conversation was relevant to the role and gave me a positive impression of the team’s technical direction. The second round was also reasonable. It involved a panel discussion and covered my experience with mathematical modeling, decomposition methods, and operations-research applications. The questions were technical but generally aligned with the position. My experience changed significantly in the third round, which was described as a subject-matter-expert interview with two senior technical team members. From the beginning, the tone felt unusually cold. Before the second interviewer joined, I greeted the first interviewer and received only a minimal response, to the point that I initially wondered whether my audio was working. After the second interviewer joined, the atmosphere became somewhat smoother, but one of the first comments was that he had never heard of my most recent company. Since interviewers are not expected to recognize every company, this would not normally be an issue, but the way it was expressed felt dismissive rather than curious. The technical questions then became progressively narrower and more difficult. I had no issue discussing decomposition methods or other advanced OR topics. However, some questions such as SOS constraints, seemed disconnected from the main technical direction discussed earlier in the process. The format increasingly felt like an effort to identify a topic I could not answer immediately rather than an evaluation of my broader modeling experience, technical judgment, and ability to solve relevant optimization problems. The interview concluded with an unannounced live-coding exercise on a shared board involving a sorting problem and a time-complexity question. This was unexpected because the meeting had been presented as a subject-matter-expert interview, and the preparation description did not indicate that a coding assessment would be included. More importantly, the exercise did not appear meaningfully connected to applied operations-research modeling, MILP formulation, decomposition methods, or the practical development of optimization solutions. For a senior applied-optimization position, evaluating immediate recall of coding syntax through a generic algorithm question provides limited insight into a candidate’s ability to formulate, implement, and scale real-world optimization models. I was rejected after the third round. I appreciated the technical depth and professionalism of the first two conversations, but the final interview left me with a negative impression. A clearer explanation of the expected format and a more consistent focus on role-relevant skills would have improved the process. More importantly, the third-round interview did not feel like an objective or good-faith evaluation. The dismissive tone from the beginning, the comment about never having heard of my most recent company, and the progression toward increasingly narrow questions created the impression that the interviewers were looking for a reason to reject the candidate rather than making a balanced assessment of relevant experience.

Kinaxis has a very automated and an impersonal interview process. Call me old-fashioned, but when I interviewed people I would book my own meeting and communicate with the candidates myself. The only time you were contacted by a human was during question and answer portions. I had applied to Kinaxis several times over the years through the standard careers site and never received a response, despite a PhD in operations research from a school they recruit at and twenty years of relevant experience. The only path that worked was a direct introduction to someone inside the company. If you are applying cold, expect the resume to disappear. Round 1 was a 1:1 with the hiring manager. It was a substantive conversation. He described the actual problem the team was trying to solve: moving from heuristic solvers to MIP formulations, hitting a vertical scaling wall on a single large server, and needing someone who could take them to a decomposition-based approach. He also surfaced an organizational gap — a sister ML team that the OR side had not been able to engage technically. The role he described was architect-level: set direction, bridge two teams, push past a ceiling the current team cannot get past on its own. Round 2 was 45 minutes, hybrid format — one senior engineering manager on video, one director in the room. The questions were almost entirely depth-on-current-practice: walk us through a formulation you wrote, walk us through a decomposition you applied, explain the mechanics of the technique your PhD thesis used (in my case, work that is 19 years old). One interviewer checked his watch about thirty minutes in. In my mind there was a mismatch that senior candidates should be aware of. An architect or principal-level hire is evaluated for judgment, breadth, and the ability to set direction across teams. That is a different bar from "can you, today, formulate a problem on a whiteboard and recall the mechanics of Lagrangean relaxation under questioning." There is reason why I moved on from old technologies to new technologies and I don't regret not using something like Gurobi anymore. The rejection arrived the day after round 2. I was relieved.