The interview process was lengthy and a bit intense. There was a skills test, a screening call, and 3 interviews (2 with people on the team and 1 with people outside the team).

Before each step, there was a description as to what to expect. I never felt surprised by the topics discussed at any point. Being able to prepare for the interviews made it much more manageable, considering it was a long process.

The skills test format was a 4-hour project for which I was able to select a time that worked best for me and do the work in my own environment. One of the interviews afterward allowed me to describe the code and my decisions in writing it. The 4 hours was a bit long, but I thought it was far more comfortable and similar to real work conditions than trying to screen-share and do a live coding test. Given the flexibility and the ability to discuss after the fact rather than in the moment, the 4-hour length didn't seem that bad.

The engineering managers I spoke with regarding the skills test were understanding that this was a 4-hour project, and not something I had time to plan for in a more contextual way, nor did I have time to include all the niceties I would have wanted if it were code that I was deploying to production. So when we reviewed it in one of the interviews, I was able to discuss what kinds of things I was considering as I wrote the code, why I made certain choices, etc. I was also able at a few points to say, "If I had more than 4 hours, I would have probably added this, or done this part differently," and I felt they were understanding of the limitation.

How could you rewrite your unit tests so that they run on a machine which does not have the same services running that run in production?