So I can't remember exactly what I told you before on facebook and what I haven't told you, so I'll just give a quick rundown of some things.
I'm first going to give you these:
There are also a bunch of other good interviews.
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. Given your background there are certainly plenty of job options at Google, at least the last I looked. If you really want to be a 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 OO programming I would certainly start with that. And as you mentioned already, 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, but 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 matters, 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.
Introduction to Algorithms is one of my favorite books and is pretty much all you need when it comes to algorithms. As for online resources, code.google.com is a very handy resource that covers a plethora of topics.
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 endevours, 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 knowledgable 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 thing.
Amoeba gave a good list of things to cover and should be a good list of things to practice.
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.
As for big business vs small business, I agree that 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.
Anyways, you know how to get a hold of me, lol.
-Cole aka bigtall*****
Originally Posted by Owtlaw333
You'll always be pretty in my eyes, Cole :luv:
Originally Posted by Chrissspyy
i was like passed out while she's shoving the entire bar in my mouth. :rofl: :rofl: