Tags: toronto |
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.