You could try a briefcase problem. My buddy at work wrote about it: https://sendgrid.com/blog/im-great-technical-interviews-got-hired/ https://sendgrid.com/blo

You could try a briefcase problem. My buddy at work wrote about it: https://sendgrid.com/blog/im-great-technical-interviews-got-hired/ https://sendgrid.com/blog/im-great-technical-interviews-got-... I recall when this happened. For us interviewers, it was really exciting how much thought a candidate had put towards our business. His onsite interview was practically a checkbox after his briefcase problem (to ensure some basics like communication and non-jerkiness). To be more inline with your question, as an interviewer, I look for communication, how you accept/reject suggestions, familiarity/fluency with your choice of tooling (if you say you are a Java person, and do some Java coding on site, you should be able to get something with simple unit tests to compile and run), understanding on how to productionize services (what metrics, logs, and traces you would implement on some sample code), and be able to communication about system design and tradeoffs. Do some digging in on the culture of the place you would be working. They might be looking for like-minded folks in some areas. Fo us, at work we look for candidates that have (what we call) our 4H's. They should be happy, humble, honest, and hungry. We have some questions that help ferret these out. But an example would be talking about past projects and team work, and the candidate is talking about "I, I, I," instead of "we, we, we." In most non-trivial team projects, there should be an aspect of "team" in the responses. While this would not rule-out a candidate, it would raise a flag that all the interviewers would talk about when deciding to move forward with the candidate.