Technical Interview Advice

[deafboy]

I've posted this on other forums but thought I would post it here as well so I don't have to copy and paste essentially to various PMs I get. I'd also love for those of you that have gone through it to add you input, obviously the more the better. Figure it'll only be beneficial since I know a lot of you are doing CS type stuff.

Programming is my job and hardware/fab is my hobby, lol.

I'll just give a quick rundown of some things.

I'm first going to give you guys these:

There are also a bunch of other good ones but these ones are slightly more recent.

Those videos didn't entirely correlate to the experience I had but they are certainly still helpful videos to watch. Before you apply to one of the top tech companies I would suggest you make sure that is something you want to do and something you are good at. Depending on your background there are certainly plenty of job options at Google, at least the last I looked. If you really want to be a Software Engineer (SWE) then I would suggest it as long as you do really enjoy coding and problem solving and have a very strong work ethic as you are pretty much micro-managing yourself to get the job done.

If you are only familiar with a small number of languages I would suggest start practicing other languages, having a strong C background is awesome and certainly encouraged but most Google engineers use Java, JS, C++ and Python. But I have used C#, Ruby, and straight C elsewhere. If you have never done any Object Oriented (OO) programming I would certainly start with that. If you have zero fluency in trees/graphs/and the like, definitely start brushing up on that. Data structures are a major role in getting things done and be sure to learn as many as you can. Be aware of how things live in memory and how they operate at scale. While brute forcing problems is acceptable in some cases it's not really ideal at all, you want to be able to create solutions that are fast and can scale very well.

Being familiar and experienced with linux is a definite plus and pretty much required in a lot of companies. If you haven't used a source management tool before I would look into that, things like Git and Perforce would be handy.

As for the interviews itself, it's a long process so just be aware of that. If you make it past the screenings and phone interviews and bring you in for an onsite interview. Prepare to code on a white board, so if you have only ever coded on a computer, be sure you practice writing code down by hand and talking through it explaining why you are doing things the way you are. This way the people that are interviewing you are getting an idea why you are doing things the way you are and just understanding your though process. Some interviewers will make suggestions if you mess up while others won't.

Like I said, run time and scalability matter, so study up on your data structures and algorithms and know their best case and worst case run times. You might come up with a solution that works, but is slow when scaled and doesn't really solve the problem like they would expect. But feel free to write up whatever solution to the problem you can and then iterate on that making it better. But be sure to talk through it the whole time. You might realize while you're talking a better solution to the problem and/or they might suggest something if you're talking while you do it.

Introduction to Algorithms is one of my favorite books and is pretty much all you need when it comes to algorithms for the most part, it's my personal favorite and have seen it at many peoples desks at various jobs, lol. As for online resources, code.google.com is a very handy resource that covers a plethora of topics and of course various forums.

As far as the interview process itself, they all vary a bit from company to company. Pretty much all of mine have been full day endeavours, generally broken down into 2 in depth code interviews, lunch, followed by 2 other interviews that test overall knowledge of design, problem solving, and basic concepts of computer science. Not necessarily in that order. I've had some interviews were they let me go for 4 hours to solve certain problems, would then go to lunch with the team you'd be on, then small group talks talking about what you did earlier and why you did it that way and just getting to know you more on a bit more personal level.

The last part might sound weird, but I have been told many times that they have had amazingly knowledgeable people come in, but they just didn't fit with the team and had a hard time communicating with people in general. So don't be worried about not knowing everything, they are definitely not expecting you to. Most companies know that there is going to be a break in period since pretty much every company does their own proprietary thing.

Amoeba (see quote at below, he's a user on another forum) gave a good list of things to cover and should be a good list of things to practice.

Good to hear your coming into the field, make sure you have an area that you're most interested in and can explain why you're energetic about it (networking, search, database, storage, kernel, etc). When I interview ppl I want to see them excited about the stuff they want to do. For a fresh grad, energy and being "hungry" is a big positive.

Most ppl don't know how to interview new grads. They're used to interviewing ppl with experience and will try to adjust the questions accordingly. This means they'll ask academic questions which should be fresh in your mind. Frequently, ppl have standard programming questions that they like to ask:

- Reverse a string

- Find a loop in a linked list

- Determine if a string is a palindrome

- Different ways to count number of bits in an integer

- Add/Insert objects into a singly linked list

- How to find out if a system is big Endian or little Endian

- Calculating Fibonnaci numbers (serially, recursively)

- Common search algorithms, pros/cons, big O complexity

- multi-threaded programming, context switching, resource sharing

- various resource locking (spinlock, mutex), their pros/cons

- GDB experience, what's a segfault.

Then there are brain teasers. Many of which you can find by googling Microsoft's interview questions:

- why is the manhole round

- how to find the fake coin in a stack using a scale

- how to transport different animals across the river

- how many barbers are there in NY (detailed assumptions arriving at a reasonable answer)

Finally there are personality questions.

- Do you know what this company/department does? (VERY IMPORTANT)

- What field did you specialize in school? What CS field do you want to go into, and why?

- What problem have stumped you before and how did you find a solution to it?

- Where do you see yourself in 5 years? (stupid questions but you'll be surprised how unprepared ppl are for this question)

I just can't stress it enough, talk through your thought process when you're doing things during the interview, there really shouldn't be a whole lot of silent time. And if you can, try and not jump right into the code. If they give you an algorithm problem, run through some small test cases first to make sure you understand what is being asked of you and what to expect. Once you're done writing the code you're going to want test cases to make sure your code is actually doing what it's suppose to be doing. The coding itself shouldn't take you long, you should work through the problem first and then code should become kind of secondary. I've rarely been asked to program on the board in a specific language, they'll typically let you code in whatever language you are comfortable with as long as it's a common language and can solve the problem.

As for big business vs small business, bigger companies are nicer for starting out as they typically have bigger projects and more resources to learn from. That being said, it depends a lot on what you want to do. I did a start up thing for a short while and was amazing. Very fast passed and you're doing a lot of different things and learning on the fly. But you can definitely get that at bigger companies too.

Be sure you have something passionate you can talk about. lol. I had an interview question once where I was asked what I would like to talk about, something related to tech but outside of your general work experience. I usually go off about cloud or hardware stuff, but yeah, just keep that in mind. It typically doesn't happen during the interview unless you finish things earlier than expected or it might come up during lunch for some general chit-chat.

I don't really have any experience with non-software engineering interviews so I can't say much for specific subsets of technical interviews. I've done some networking stuff but nothing too in depth, aside from handshake and various error codes and redirection, nothing came up too in depth during the interviews. So maybe someone wants to cover that?

I have had questions come up about linux specific stuff, command line type stuff to test your knowledge to make sure you know how to do basic things (compile code, kill processes, check system settings, etc).

And try and study about the company a bit before you go in, at least know what they do and whatnot. Not a big deal but helps.

As for how to dress, most SWE dress pretty casual. If you can, go in or ask about it. For interviews most of the time I dress casually but not tore up clothes casual. lol. I tend to wear jeans, t-shirt, and a hoodie.

Um, if you guys can think of anything specific I'll try and answer but I'm not going to go into specific questions and things that I simply cannot talk about but if I can talk about it, I will try and help.

[deafboy]

Was going to flag it, but it's not really a flaggable reason. But can this thread please be moved to the programming section. Thanks.

[DLM_012]

Interesting post. While I'm not majoring in anything software related, I will keep all of these tips in mind. I interviewed for a college intern position for a state agency and will be starting this coming Monday. There are a few things that you pointed out about the interview that happened to me:

• where do you see yourself x years from now?
• I see _____ on your resume (a software program they were unfamiliar with) tell me about that
• they really do look for that "hunger" as you mentioned

The first question was really easy for me to deliver on. I told them I'd like to be a network administrator sometime in the near future possibly managing a small team. I could tell by their body language they loved the response. They also noticed on my resume that I had experience with Sony Vegas Pro which led me into a discussion about my hobbies. I went on into detail about how I have a passion for gaming so I create content for my youtube channel and edit video, etc. They also were thrilled/impressed with that too and I briefly talked about my custom rig. I would have showed pics but I thought that was an inappropriate time. The way you answer questions is important for that "hunger" to get across. I was completely honest about my knowledge of certain systems and emphasized that while my experience is lacking, I stated that I was looking to gain some more and learn quite a bit throughout the course of the internship. I said all of this while being genuinely enthusiastic and using gestures to further that.

 

Just some of my experiences.. that's all. To anyone reading this, it's actually a bit easier than you think. I'm a 20 y/o college student with no previous experience in IT. All I have is passion and people love that even if your knowledge is lacking a bit.

 

I'll try to add more to this thread when I actually start and am given some responsibilities