Expeditors Interview Questions
& Process

I recently interviewed for a Business Analyst/Product Owner role within IS Operational Experience, Accounting, Data Governance Services at Expeditors. Unfortunately, my experience was disappointing. The interview started with the managers talking about the company's downsides – specifically, the requirement to be onsite every day and a strict dress code. While I was okay with those things, it was weird and off-putting that they focused on them first. It felt like they were either trying to get ahead of common complaints or showing their own unhappiness. What was more concerning was the vibe. I didn't get asked many insightful or role-specific questions, making it hard to tell if the team understood or valued the Business Analyst/Product Owner job. There wasn't much clarity on what the role was supposed to achieve, do, or what its future looked like, which makes me wonder how important or supported this position really is. It was also strange that no recruiter reached out first. I was set up directly with the hiring team, adding to the feeling of disorganization and lack of a clear hiring process. All in all, the interview made me seriously doubt the team and the company culture. Expeditors might work for some, but I'd advise others – especially those used to modern, flexible, and cooperative workplaces – to really think if the company's old-fashioned and somewhat dated ways fit what you expect.

I had an initial HR screening call that went really well. After that, I had a video interview with the hiring manager. During the video interview, the hiring manager unexpectedly decided to make it a skills/technical test, which I wasn't prepared for. The interview lasted for over an hour. I was initially told I'd get a response by the end of the week, but I didn't hear back. I followed up the following week, and a few days later, I received a very brief response stating they were pursuing a different direction. While I understand interviews can vary, I wasn't expecting to be asked technical questions for more than 25 minutes in what was supposed to be an introductory interview. I also didn't like being ignored past the deadline for a response. Aside from those points, the rest of the experience was fine.

The interview process had four rounds in total. The first two rounds were an aptitude test, which was of average difficulty, and a group discussion. In the group discussion, my peers and I discussed topics that were both technical and social. The next two rounds were technical and cultural interviews. The interviewers were straightforward, direct, and polite. It was easy to express your views and also cope if you didn't know an answer. They mainly focused on the candidate's clarity and communication rather than technical specifics, as they believe attitude is more important and can't be trained. So, train your communication well and be careful about subtle checkpoints in a negotiation, as that's how they'll test your commitment to the company.

The interview process was quite efficient and realistic. It kicked off with a recruiter call to discuss the role. Following that, there was a meet and greet with the team, which included a technical interview. That was it, no more interviews. The technical part was mainly to check if I understood development concepts and had good fundamentals, without any difficult or Hacker Rank-style problems, which I think is how it should be. During the technical interview, I had to write a Java solution for a given problem, as Java is their main product language here. After that, they asked about alternative approaches I could consider and some questions about Java features to gauge my awareness and understanding. For instance, they asked 'Why are strings immutable in Java?'. Instead of a brief answer, I explained my understanding of Java strings, assuming that's what they were looking for, which I felt helped. Other general questions included 'Walk us through the process of a previous professional experience that was particularly hard or tricky for you to solve' and 'What are some ways to use Maps in Java?'. These are pretty standard questions that someone with experience should be able to discuss in depth. Many of these questions don't have a single 'right' answer but are more about assessing your experience depth. We then spent about 15 minutes just chatting informally. I asked about the team's current projects, shared some personal experiences related to their work, and generally built rapport. Overall, it was a great experience, one of the most reasonable and efficient interview processes I've encountered.