5 Answers to common (and difficult) interview questions

After several posts focused on product release, I finally have some time to write about life as a Developer, and to answer some questions asked by my (few) readers. The most common questions I receive are about job interviews. Competition from other Developers is getting higher every day, and Companies are, understandably, getting picky, looking for Professionals who can “tick all the boxes”.

The difficulty in passing an interview, however, is not just showing that you can write code. Ironically, that’s the easy part. The difficult questions come later, when the technical interview is over, and are meant to test your personality. People who spend most of their time “talking” to machines can, sometimes, have a hard time answering human-related questions, therefore it becomes vital to prepare some answers upfront.

Below you can find my personal answers to some of the most common questions I got asked in my career. Just keep in mind that such answers are based on my personal experience and my personality and that some of them are a bit… “sharp”. The purpose of this post is to give you an idea of how you could answer, without relying on the usual canned answers provided by recruitment agencies.

Interview Questions (and Answers)

Q1: Why do you want to work for us?

A1: I don’t “want” to work for you. I’m here to evaluate the possibility of a collaboration that can be profitable for both of us in an equal manner. I can provide skills and experience that I believe would be useful to your project(s), and I think that your Company can provide an environment where I can expand my knowledge.

Reason: we are in 21st century. Unless you are starving and in desperate need of a job, an interview is a dialogue between two Professional entities. The times when Companies had the upper hand throughout the interviews is over, and it’s important to keep it in mind. Unless you really want, or need, to work for a specific Company (which would give them an unfair advantage), don’t come up with lies just to make them happy.

Q2: What can you do for our Company?

A2: As I explained earlier, it’s more a matter of what we can do for each other. Highlight how you can contribute to Company’s success, and what you would expect in return, as done in Question 1.

Reason: same as Question 1. It’s not only you who has to prove their worth, the prospective employer should do the same.

Q3: Are you able to work under pressure and/or with tight deadlines?

A3: I know how to deal with pressure and tight deadlines, and I learned how to make sure that the conditions that caused them won’t repeat. Pressure derives from urgency, which can be caused by an emergency, by inefficiency, or by mistakes. While it’s important to deal with the urgent tasks first, it’s even more important that the root cause of emergencies is addressed permanently, so that they won’t happen again. A system that is constantly under pressure is fundamentally flawed.

Similarly, I can organise my work to ensure that occasional tight deadlines are met. However, such condition should never present itself, as all deadlines should be established together with the Development Team. If team members are experienced enough, they will be able to set reasonable deadlines, allowing for some margin (thus reducing the change of working under pressure as well). If they are mostly juniors, I can help them learning how to give proper estimates. In the end, there should be no chance of having tight deadlines at all, resulting in an increase of productivity.

Reason: constant pressure and tight deadlines are bugs. They are not in the software, but in the management. Since you are a great Professional Developer, you know that fixing the damage done by a bug is important, but fixing the bug once and for all is vital.

Continuous pressure is bad. Poor managers believe that a Team who is constantly under pressure will perform better, while the opposite is true. Pressure means stress, which turns into fatigue and poor results. Poor results become bugs, misunderstandings and delays, which bring even more pressure.

A similar logic applies to tight deadlines. Deadlines should be established by, or, at least, with the Team who is working on a project. Unless the Team members are too unexperienced and overly optimistic, tight deadlines should never exist. The only case in which they can appear regularly is where one or more of the “pressure-fanatics” managers (who, of course, don’t have to do any of the work) establish deadlines arbitrarily and enforce them because “they are the boss“.

It’s important that you, as a Professional, have the ability of coming out with a contingency plan when the above conditions arise, but also that you step forward with a solution to prevent them in the future. If the Company does not allow you to fix their management bugs, move forward. As I say when I find such kind of issues: I either change the environment, or I change environment.

Q4: Tell us one of your strengths and one of your weaknesses.

A4: One answer to both questions: I’m lazy, in the good sense. I don’t like to do repetitive or long, manual tasks, therefore I focus on finding efficient ways to automate them. I analyse all tasks that I receive and look for patterns which could allow me to delegate them to the machines, which results in a more efficient, consistent and predictable outcome. When coding, I focus on producing  high quality, reliable, well documented code, to minimise the chance of bugs and, indirectly, reducing the possibility of having to go over it too many times. I call this approach constructive laziness.

Reason: good Software Developers are creative people, not robots, and they don’t like to repeat the same stuff over and over again. In my case, I also tend to lose interest quickly when a task is not challenging enough, and I can’t focus on it for more than a couple of minutes. It makes much more sense, to me, to transform the boring tasks into a double challenge: finding a to tell the computers how to do the work for you, and making sure that they will do it forever. Better results, and faster!

Q5: It’s Friday, and you completed all your tasks by lunch time. One of your colleagues is behind with his work, what do you do?

A5: It depends on the circumstances. If my colleague were behind for causes outside his control, I would first help him completing his tasks, then analyse with him the cause of the delay, to make sure it won’t happen again (that brings us back to the answer given to Question 3).  If my colleague is behind due to his own negligence, then I would let him deal with it. Helping him, in such case, would give the wrong message, implying that one is free to be negligent, for someone else will pick up his slack. Negligence or, worse, incompetence, should never be rewarded.

Reason: while it’s true that a Team should be “jelled”, that should not be an excuse for any of its members to slack. If a member is fast and efficient, he should not be forced to always pick up the slack of someone who just doesn’t care. If the delay is due to external factors (emergencies, tight deadlines, etc), then it’s the whole Team’s duty to make sure that they won’t happen again. This will make sure that the Team will be done by Friday at lunch time, so that they can start their weekend with a good beer.

That’s it for now. Speaking of beer, it’s time to enjoy the weekend! See you soon!

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.