Tags: | Posted by Admin on 12/22/2010 9:24 AM | Comments (0)
I had the pleasure of interviewing at Google for the second time just a few days ago. It was for a SET (software engineer in test) position in Mountain View. I feel the need to write down what the experience was like for me as a second timer, how it was different from the first time, how I think I did and how I think I can improve myself as a software engineer.

The first time, I had studied like mad, everything from dynamic programming to self-balancing trees, all of which confused me when it came to solving the actual problems. It's probably analogous to having all your golf clubs in your bag when you're playing pitch and putt. You only need about 4 clubs, so the rest are just dead weight and can get in the way.

I also put way too much pressure on myself, I slept maybe 4 hours in the two days leading up to the interview, which is absolute insanity. I felt like a bowl of jello heading into the first interview. Pro-tip: I wouldn't wear a tie, but I would wear shoes (like not sandals) and not shorts and be comfortable.

My first interview was beyond awful and I had no idea why I'd be invited back to interview again, but the world is full of surprises it seems.

The second time around there was less pressure and stress. I knew what the questions were like based on the last go around and I had prepared in a more targeted way. Topcoder questions from division 2 as well as an algorithm review of the basics of trees/graphs/sorting and some OO Design stuff are enough.
I also slept quite a bit more, probably about 12 hours in the previous 48, which may have been enough to kick me off my game a bit but not enough to make my brain go mushy.

The questions this time seemed easier somehow, maybe it was the different interviewers or maybe it was just that I had more sleep or less clubs in the bag. But it seemed that I didn't have to struggle to get the basic algorithm down for the question at all. I had a few issues with a big-O (which really surprised me, usually I get these 90% of the time, I think I needed more practice there) as well as a few (probably about 6 total could be closer to 10 if you could look over the code later) mistakes, both logical and syntactic, as well as some general meandering answers for design related questions. All of which proved to be enough to boot me, I think I was much closer this time around and if I had taken a bit more time with things and been more careful to not "put my piece down" to use a chess analogy too early, I think I would have made it.

Failure always makes us look in the mirror, or for me it does anyway. But I hate the feeling, the sadness, the regret and especially in the case of interviews, I hate not knowing what I did wrong. But in this instance it was a bit different, my recruiter shared one of the areas in which some of the interviewers said I was lacking, which was really nice.

Looking back on the interview, I think I did well on identifying what the algorithm I'd use to solve the problem, however I made a few mistakes in the implementation.

The mistakes I made though I think were caused by two things, first I was so shocked that I figured out the algorithm so quickly that I wanted to just shoot through and finish and I didn't take my time with things. I also didn't check my work very throughly either, which has been a particular problem of mine forever.

I don't know why I don't check my work because I always seem to find mistakes when I do. Maybe it's because I put myself down so much when I find one that I don't like looking for them because it makes me feel bad about myself. There's a bit of self-analysis for you. This is why I think I'll always do a Google interview when I'm offered one because it's hard and I always find out something new about myself when I do, so I get better as a person.

The thing is I've known this about myself for a long time so when I'm coding something so I either use TDD and/or really bust my ass to create a lot of junit tests. Both strategies which I employ to catch my mistakes do not translate well to the tight timelines and boardspace of an interview. I'd imagine the only way you could truly work that way on an interview is to be locked up in a room with the interviewer in a forced pair programming exercise with a topcoder like problem. I don't think that's going to happen any time soon though, so I'll have to get better at doing it right the first time absent of junit.

The only thing I can think of to do that is to not only write code on a whiteboard or piece of paper as I had done, but one has to do coding competitions like topcoder so that you get familiar with writing a _correct_ solution to an algorithmic problem in a short time (just like a google interview). For the problems I had with big-O I think I was just rushing it, slowing things down is probably a really good thing for me to remember.

So until next year Google, I know you'll be just fine without me, and thanks for making me look in the mirror again.
Comments are closed