There are different types of questions that are asked in Software Engineering interviews which are aimed to only be answered by more experienced developers and then there are questions that differentiate candidates based on the detail they give.
While working at Freetrade I conducted the initial software engineer interview frequently, this consisted of a brief intro, a set list of API questions, an unfamiliar coding walkthrough, and a short coding exercise. The format of the interview and the questions asked were always the same regardless of the level of an applicants experience and it was really interesting to see what answers candidates gave given their experience and level they were applying for.
For the first part of the interview, there are some pretty open-ended questions designed to not just test the knowledge of the candidate but also how well they can explain something and draw on their own experience. I think it’s important to remember that nobody in an interview is just looking for a memorised textbook answer to any question, of course people have the definition with some examples and conversation topics memorised, but the more interesting answers came from candidates that went into some detail but accepted some gaps in knowledge.
The first question “What is REST?” gave a lot of interesting answers and as an interviewer we’re looking for a few basic checkboxes being ticked on this one, did the candidate mention “endpoints to interact with resources”, did they talk about all the different HTTP verbs and what they mean, did they talk about the stateless nature of REST APIs? Ultimately, a good answer is going to be different to every interview, my own personal view is that a good candidate will draw from their experience of how they’ve worked with REST and what they took from it.
Always remember that not having any experience within a question is a valid and acceptable answer, whilst interviewing for a full-stack position there were a many applicants that came from a purely frontend position that had zero experience of writing REST APIs and so had little to no answer for this question. Circumstances can always be taken into consideration but guessing an answer won’t help in any interview.
The expectation is usually that there will be fewer questions at the start and a bit more guiding when writing code for more junior applicants but the more senior applicants tend to ask more questions earlier on to get a full set of requirements and then write code based on that. There are levels again to how testable and maintainable the solution is, but that always makes for an interesting conversation afterwards.
Some interviewers have the expectation that the more senior a candidate is the more complete their solution will be. Always remember that coding exercises start out with a simple problem and then the requirements are built up with things designed to make you change previous work to cater for. A perfect solution can always be made within the timeframe allowed by an interviewer but a passing interview doesn’t require a perfect solution, or even a working one in most cases, as long as the candidate demonstrates that they have a working knowledge of the language and they can explain their thought process and approach to the solution.
My Advice
For all interviews, always prepare beforehand and know the company and product. Prepare some questions for at the end of the interview for things that you would find useful, such as “what is the team structure?” or “what kind of programming languages and frameworks are used?”.
Remember that an interview is always a learning experience and you as an engineer will always have room to grow. If the interview doesn’t go so well, ask for feedback and if you don’t agree with it still try to learn from it and take it into the next interview.
In more general terms, I think that an interview is an opportunity to show your qualities. When a company reaches out for an interview, they have read your CV and think that you will be a good fit, so it’s simply just a case of proving that you can do what you said you can. Therefore, I would stick to these principles to make sure you are prepared for any interview:
Be Honest
I’m sure it’s different to every interviewer but I think a candidate saying that they don’t know the answer is better than trying to guess. I’d rather have a conversation about the solution and then the interview is a learning experience rather than exam.
Be Detailed
Come prepared to interviews and have your experience with different technologies ready to be questioned and tested. Remember that the set of questions are asked for a reason and that it’s always good to be thorough while also staying concise to what is required.
Be Calm
Take your time in answering questions and try to think clearly before starting with an answer. This particularly is important when attempting coding exercises, talk through all assumptions and requirements with the interviewer before writing a single line of code.
Be Curious
Curiosity is a great quality in an engineer, if you don’t know the answer to a question then ask what it is. You have the time in the interview to show that you are interested in what is being discussed and just because you haven’t used the technology or know what the theory is doesn’t mean it won’t be useful to hear the answer.
Be Confident
Know what you want and don’t waste your time and someone else’s if the interview isn’t making you want to work for the company. Don’t undersell yourself and know what you are worth, but don’t mistake confidence with arrogance, try to remain humble and see every interview as a learning opportunity.