Staff IT Engineer - Past Projects Deep Dive

Why Are We Doing This?

Going through one of your past projects in-depth lets us see what you would actually do on the job—like how you gather information, make decisions, plan work, and handle time constraints or setbacks.

The Interview

This interview will have you walk us through a Past Project with our Co-Founder and VP of Engineering for 50 minutes + 10 minutes for Q&A.

We'll ask you to lead, and we'll stop you for questions along the way. We might go very deep into pieces we find interesting or ask you to repeat or rephrase things we couldn't understand. It might derail your explanation, but we'll do our best to bring you back to where you left off.

You are welcome to use the same project throughout the interview process. This round gives us more time to dig into the details—just make sure there's enough to cover the length of time we have scheduled.

You are welcome to use diagrams or slides if they help you. We don't expect you to, and you don't get bonus points for doing so (or not). Use them solely if they help you communicate and help us understand. If you use slides, they can be as simple as black text on a white background.

If you're unsure about which project to choose or simply want to put your best foot forward, ask your hiring manager. They're happy to help, and we won't ding you for asking. Send over a couple of ideas with 1-2 sentence descriptions, or ask for 15 minutes with your hiring manager. This has sometimes helped candidates pick a better project!

Finally, it might be intimidating and nerve-wracking to spend one-on-one time with our Co-Founder and VP of Engineering. He'll do his best to relieve that tension, but we'll preface this interview by saying he wants to run a straightforward interview and to see you at your best (not your worst). There are no trick questions or other mind games.

Expectations

The project you present should be one you led and for which you made critical decisions. Additionally:

• There were ambiguous challenges that required creative solutions (this is subjective, but, for instance, we like projects that require you to map data models and logic across different systems and build an understanding of various departments to do that successfully).
• You led technical decision-making and implementation, and you can describe them in great detail (e.g., technologies used and why).
• You can speak to both the business context and technical architecture. You can explain how an internal customer or business need influenced your technical decisions (we get excited when you also make process decisions!).
• You're able to explain why important decisions were made, including technology choices, tradeoffs, testing, and reliability considerations.
• You can remember details like properties on a data model in a system you interfaced with, API or logic gaps between systems, timelines for milestones, end-user feedback.

We're particularly interested in understanding:

• How you scoped the problem and defined success
• The architecture and technology stack
• Key decisions and their tradeoffs
• How the project fit into the broader technical and business landscape
• Any interesting challenges or lessons learned during development or after release
• How long it took to reach important milestones and why that time was necessary

Here are a few helpful prompts to think about as you select your project(s):

• What's a project you're most proud of?
• What's the most technically challenging thing you've worked on (recently enough that you can remember key decisions and technical details)?

Effective communication is an important skill we're assessing in this interview. You may have an impressive project, but it doesn't matter if we can't understand it. While we'll ask questions, you should still decide where context is necessary and where it isn't. Your interviewers will be technical, so you can assume they'll understand basic technical concepts.

No slides or formal prep are required. We're just looking for a thoughtful, easy-to-follow conversation about your experience. Some folks do find it helpful to put diagrams or slides together. Sometimes it's easier to describe a complex system or data model and its relationships through a diagram. Some folks are a bit nervous unless they have a talk track they can reference, and slides can help. Do what's best for you to communicate your project effectively!

Examples

This isn't a comprehensive list, but it's better than no examples!

Projects we're interested in hearing about:

• A project providing API surfaces back to other areas of the business for heavy integration of IT tooling with the wider stack.
• A project to design and build a declarative setup around device and application patching, where the policy drives the configuration programmatically.

Projects we're much less interested in:

• A project that implemented a baseline or common setup for Okta and didn't use any of Okta's programmable features, like Okta Workflows.
• Formalizing a request approval process to speed things up by making a form for end users and using good documentation to make things clearer.