This week, I took a bit of a break from doing learning new concepts online, because I actually had my first techincal interview!!... I didn't pass it. I think that it was definitely a sign of progress that I was able to land the interview in the first place, but I guess I just wanted to share some of my thoughts on what went right and how I can improve, so that I can share some of my insights with others.
Getting the technical interview
Believe it or not, the first round of interviews was actually more nerve racking for me. To me, the idea of having to talk about who I am, advocate for my software skills, as well maintaining a sense of personability seemed like a juggling exercise. I remember 5 minutes before having to call, I was having a mild panic attack and pacing around back and forth in my room.
I actually had one other opportunity at a behavioral interview
before this, and it actually went really badly. As soon as the interviewer asked me to tell me about myself (which is a que for your elevator pitch), I talked for about 5 minutes about my entire life story and how I got to pick software engineering. I didn't want to repeat the horror story that was my first behavioral interview, and before I went in this one, I kept having flashbacks to the previous interview.
Trying to forget my past experience, the behavioral interview started. I still had a lot of jitters, but it was nice, because the interview was very conversational in tone, and it went very smoothly. There were 3 main points that I think guided this first part of the interview to be successful.
1) Maintain curiosity
I think the thing that made my first interview bad, was I put myself into a kind of spotlight. As soon as the interviewer asked her first questions, I thought that I had been put into an interrogation room. Don't have that mentality! That is setting up yourself for failure, and sending out a lot of awkward energy to the interviewer. The behavioral interview isn't all about you.
It is easy to get into that mentality, because obviously we want to show the interviewer that we are capable engineers worthy of being hired. To counteract this fear, I think most people will say that this is an opportunity for you to interview the company. That is not necessarily how I approach the company, because frankly, I'm not that picky about where I'm trying to work.
Instead I went in with the mentality of being inquisitive specifically about what the person was saying, and asking follow up questions. I wasn't necessarily trying to find out a whole lot about the company (which I feel like can come off as a bit demanding... 'do you have benefits/ free lattes?'). I just decided to treat this like a normal conversation, where if the other person says something, maintaining an inquisitive attitude about what the other person is saying.
I think this kind of easy-going, inquisitive attitude was a big factor in allowing me to calm down, since my disposition towards everything wasn't so high pressure and it gave the sense to the employer that I was personable. Especially
2) Keep things short and simple
The other thing I realized was when the employer asks you questions about yourself you should have your 30 second pitch ready, and remember that your answers don't necessarily have to be very long. This is what screwed me over during my first interview. If they ask about particular experiences give your STAR story(Situation - Task - Action - Result). The interviewer will easily lose interest, and it will also give you the potential to say something off track. You're a hardworking individual passionate about software development through particular experiences. Good.
3) Show interest in programming
This is somewhat similar to the first point, but I would say specifically you need to show somehow that you are interested in programming. Talk about something that you studied that interests you or about one of the projects you do. One of the main things the interviewer in hiring a programmer is to make sure the person enjoys what he does. Again, I think a key factor is just be natural.
Technical Interview
So great I was able to nail down that part of the interview, the next part is the one I failed. As an overview, the interviewer asked me about one of the projects that I worked on, and then we jumped right into the problem. Without getting too much into detail, the problem gave you a list of courses, students, and a table with a many to many relationship between them. We had to write code that went through all the student models and found all the courses that each student was in, how many students
Things I did well:
1) Mindset of having a learning experience
I think my mentality was for the most part good. I think I was much less nervous for this one than the previous one, and I think that was mainly due to my disposition towards this interview as a learning experience. It was much easier to think about it this way too, because the interview would consist of actually coding, instead of just talking about myself.
I think this really helps to calm down to the nerves, but also to solve the problem. The problem itself is a maze full of details which you have to navigate around. Going into the interview with a curious mindset is vital to being able to ask perceptive questions and understand the nature of the problem. This probably seems obvious, but without this mindset to 'learn the problem', it is very easy to approach a problem as a version of another one you've solved before, when small details can make them very different.
2) I explained all my steps
With everything that I did, I tried to write out comments and communicate to the interviewer what I was thinking. Every step that I took, whether it was as simple as looping through an array of users, or finding a particular course, I would vocalize the step and the code that would proceed from that. A software engineer I networked with today told me that one of the most important things that an interviewer is testing for is not whether you know the solution, but whether you can communicate that solution.
Things I did not so good:
1) I lacked an overview/plan of approach
I did explain a lot of things... but I don't think the explanations had continuity. I think that I had a lot of dots that were the right dots. I was saying relevant content... "we need to loop through the list of users", "we should create a data structure", and the interviewer would give me an approval 'yes', only to be followed by a defeaning silence when I gave a lackluster approach to connecting it to the next step of the solution. This lack of connectionshowed partly in the step by step approach of solving the problem itself, but mostly in the lack of a plan before I even started coding. This is probably related to my habit of just jumping into code to guess at a solution when I'm working at something on Leetcode, but I really need to stop doing that and make a habit of getting a detailed overview before starting to solve a problem.
2) I didn't really understand algorithms/data structures, no context
The thing is the problems that I worked on during the interview were very simple questions. One of the things that tripped me up though, was I was worried that I would be asked a dynamic programming question, and so I wasn't able to see that the problem didn't require one. We learn all sorts of algorithms, but we can't just try to remember its content, but how to describe the specific (and perhpas diverse kinds) of situations they are used in. I think as I get back to the drawing board, one of my concerns is trying to remember what kinds of situations algorithms are used in. When starting to study data structures and algorithms, there's definitely the challenge of trying to remember all of them, but if you don't know when and how to use them, you'll be just as lost as if you didn't know them at all.
3) I was a little too relaxed
This is a bit of a contrast to the first positive point I made, but I think I might have taken it too easy. I didn't feel the pressure to come up with a solution, but I just looked at it as a coding session with a buddy. To see things like that definitely help to calm the nerves and reduce the pressure for the very daunting first technical interview, but it also gives the impression to the interviewer that you might not be taking things seriously, which is also bad. Not only that, but you're also being tested on your ability to solve a particular problem, so if you don't actually solve the problem, and only get to two of the three questions like I did, it's not a good look.
Overview
So all in all, it still sucks that I didn't get to the next round, but I'm looking at this as a learning experience. As you prepare and take away from these positives and negatives, I hope you are able to develop the right attitude and tools to pass that infamous technical interview.
Onto the next!
Top comments (3)
Be careful with this. As someone who's been on the other side of that chair, it's very obvious when you're just going through a memorized script. I can tell that you're talking at me and not with me, when you're giving me a memorized response.
Correct. Out of a group of equally qualified candidates, I've previously narrowed it down to the person who was most active on dev communities (StackOverflow, etc). It was a good indicator of their passion, but it's also not totally necessary. There's nothing wrong with this just being your job. But the idea that you love something enough to do it even when you're not getting paid is certainly something people will take notice of.
Correct. Furthermore, your ability to find that solution means more to me than you memorizing it.
I don't think there's anything wrong with this. Especially in contrast to you previously having a panic attack. Believe it or not, I've had someone suffer from a panic attack mid-interview. Its our job to empathize with that. Its our job to understand how much pressure you're under and make you feel comfortable enough to proceed with the interview. If we can't do a good job of that during the interview process, then how will we do it during the day-to-day stresses of work? So yes, feel relaxed. Feel free to see the person interviewing you as a friend you're coding with, because chances are (depending who's interviewing you) that's what you want them to eventually be. That doesn't mean you need to take it any less serious.
The idea that someone would expect you memorize most, yet alone "all" is absurd. Instead, focus on memorizing how to correctly re-surface the answer. Whether that be google, SO, personal notes, etc. I'm not a fan of the "show me you memorized this algorithm" approach to interviewing. While I appreciate the approach still exists, I think many are getting away from this. I'm more interested in your ability to find an answer than I am in you memorizing it. The former will be useful even on topics unknown. The latter has plenty of limitations.
Hi Gio,
I appreicate you taking the time to give me your perspective to help clarify some of the things I was trying to voice from my experience.
I agree with your point on being relaxed, I think at the end of the day, I was leaning to being in that mindset, mainly because you can't think when your mind is anxious. I also, appreciate you sharing your desire to help interviewees, I think this helps understand the interviewers' perspective and to overall trust you guys more, haha.
As for memorizing an 'act', I agree. It's definitely easier to memorize a solution for a type of problem, than to actually understand the problem and the solution, so you can better understand how those apply to specific situations. I feel like this is mostly due to my lack of experience/practice, and also creating good habits like understanding the problem before I choose to code and try out a half-baked solution.
Yea, of course! I think its awesome that you're sharing this with the world. Reflecting in public like this takes a lot of courage and is very useful for others. So my hat's off to you 🤘🏻