Interviewing and Social Interactions – Jr Software Developer insights

The social part of a job are both my favorite and least favorite parts. They can be amazing because of the amazing people you can work with. These people have shaped my philosophy, challenged my perspectives, and overall improved my quality of life. On the flip side, it can be equally dreadful because not everyone I have met are prepared, engaging, or motivated individuals. Sometimes people want to drag their feet in teams or generally lack effort in team camaraderie. Furthermore, people’s reactions are easily predictable with any guarantee. Some people I meet are types that I have not met, up until that point, or simply lie outside my usual social bubble. Maybe that’s why I love software development. The bugs make sense and are expected. And a console.log(‘hello world’) will always log ‘hello world’.

Even this potential downside of general social interactions isn’t that bad. In fact, it’s a great way to see different sides of people and observe how different people all fit in the single mold of our civilization. Truly no person is an island.

These constant observations have helped me with interviews. Some interviewers are much more methodical and others a lot more loose in structure. Others still are natural speakers and are easy to talk to. In this wild spectrum, filled with many hues, are all the types of people, and therefore interviewers, you may come to meet. The trick isn’t to be able to connect in each interview on some intimate level to guarantee success and to move onto the next stage of the process. In fact, it’s a little more roundabout.

Authenticity is the theme and being genuine is the key. Listen to the question asked, take a moment to breath and form your answer, and then be genuine. Don’t respond with what you think they want to hear, respond with you want to say. Team player, self motivated, independent, etc. These are all characteristics everyone wants other people to have in their teams. These are already a given which means it’s pretty redundant to respond with these answers.

What has helped me is that instead of trying to force these points in the conversation, rather simply move where the conversation naturally goes.

In an interview, early in my job search, I was asked “When was the last time you had a bug or problem in your code that took you days to solve? How did you solve it?” This was a technical interview which meant I had to respond with actual technical jargon. I couldn’t think of a single time I’ve had a bug that took me more than a day or two to solve so I made up an answer.

The answer was unconvincing to myself and frankly disingenuous. Looking back, I should have said that I couldn’t remember off the top of my head and rather go straight into the problem solving aspect and what I usually do when I hit walls. I try to break different things to receive different code errors. I consult stack overflow. I consult other colleagues. I take a night to reset my mind. If all else fails, I go back in my progress to a point where the code wasn’t broken and rebuild my code.

Even though that wouldn’t have been the initial answer he may have been looking for, it would have been a straight answer that not only I knew was authentic and true, but also would have given the interviewer insight into the type of developer I was. After all, that’s what an interview is about.

Leave a comment

Design a site like this with WordPress.com
Get started