The main thing here is to talk through your direction of code. Ask validation questions to make sure you understand the question and what the outcome should be. Drawing some basic things out first and just speaking or showing your reasoning is a great way to get the conversation started. Again, it's not always about getting the right answer yourself but proving you can work with the the interviewers to come up with a solution that ideally will work, but at least is logical and highlights you as a skilled developer. From there, you can always ask if you should write tests.
Continue to work through the problem. Best thing is to start with perhaps the brute force method and see if you can make something that just works. Then go back and optimize. Continue asking questions and explaining your direction the whole time. If you run out of time, just explain quickly in the last few minutes what your steps were to get to completion and what your tests and optimization plans would be.
Skip some small things and indicate perhaps when syntax is off or something that wont effect the code or algorithm so you can really concentrate on how to get the best answer. Polish isn't as essential as showing your reasoning.It can start somewhat messy and hopefully by the end become more polished as you optimize.
For culture and other aspects, get a sense of what it is like to work there. How are projects assigned and distributed? Who do you report to and how is performance analyzed? Are you working closely with product managers and designers? How does the team decide on what to work on next? Get a good sense of the engineering culture and what it would be like to work there on a daily basis. Understanding of how something comes to the engineering team and how work divided is a pretty important aspect to any job.
Technical Interview Prep Sites:
