About a month and a half ago, right at the end of my sabbatical, I went on a interview with the company AutoDesk for a position working on their Inventor product. In the end, I didn’t get the job; they went with an internal transfer, but the experience was a great learning experience for me anyway.
The last time that I interviewed for a job, the only time, really, was 15 years ago. I was fresh out of college and hence it was a different kind of experience. This time around, I’ve had years of experience and the questioning goes beyond the stuff you learn in computer science classes. I’ve interviewed a bunch of people for Intel. How to prepare? What will they ask?
About a week before the interview, I got an email with my interview schedule with the topics each person is supposed to drill me about. Some of it was easy stuff. Basic programming skills, design patterns… Some of it worried me more: math concepts, geometric modelling. Knowing that they deal all day with 3-dimensional curves and shapes, I dug out my old computer graphics book and did a bit studying.
The day of the interview came and went. I fielded all of their questions and I’m mostly happy with my answers, but it wasn’t quite the “shock and awe” I had hoped for. It took them 2.5 weeks to give me their decision, so I would tend to believe that they went with a transfer. You never know though. The majority of applicants to Intel that I’ve screened/interviewed were pretty marginal (at best) but perhaps AutoDesk gets a different breed of programmer.
I did learn a lot through the process.
- Getting an interview schedule can be helpful. Going through a bit of my computer graphics book made it easier to field several of the questions.
- A standard question that people ask (I’ve asked it myself) is, “tell me about something that you’re worked on that you feel good about and what was your contribution to it.” I didn’t really have an impressive answer to this.
- A bunch of the questions were about how to handle certain situations. These are often best answered in terms of work already done. when doing this, I repeated used my most recent work, but I’d done much more. I could have squeezed in references to those.
- Back in the 90s my dept (I’ve been in the same dept for the whole 15 years I’ve been at Intel), we had a lot of buzz around the CS concepts/books of the day. Code Complete, 10 things for better c++, and design patterns. We don’t really do that anymore. From the schedule, I knew they would ask me about Design Patterns, but I didn’t brush up on them thinking that I’d lived it. The problem was, I forgot the names of most of the patterns, so during the interview, I probably gave the appearance of figuring it out as I went along more than actually knowing it. Either way, the key learning here is that I need to be sure to review stuff I already know and make sure I stay up to date with current trends. Not just for interviewing, but to make sure I know it.
- If someone asks me a riddle type question that I’ve already seen, after I telling them I already know the answer, instead of just giving it to them, explain the logic behind it anyway. It feels a bit car saleman not to.
Either way, it seems fair for them to hire someone from inside the company with a track record. Also, it’s harder to take the risk on someone with my expected pay grade than someone fresh out of college. Maybe I’ll get a call from one of them sometime in the future.
I’m glad I did it.
Oh, there was one interesting thing that did happen. One of the guys, a younger member, asked me how to take a string and reverse the words in place. The answer is to first reverse all of the letters and then use the same function again to reverse each word in place. The follow up question is, “what’s the time complexity?”. The answer is O(n), but he insisted it’s O(n^2). He tried to explain why, and it wasn’t complete rubbish.
It was still wrong though.