| layout | title |
|---|---|
default |
Project Intern |
Project Intern is about getting more SoC students summer internships with tech companies. We hope to consolidate all the information regarding getting an overseas summer internship. With a focus on:
- NUS SoC students
- Internships with tech companies in the U.S.
We don't mean to say that there are no interesting internships outside the US - in the past, SoC students have, in fact, interned at companies in Sweden, Canada, Japan and the UK. But the truth is that the biggest and most interesting tech companies are based in the US.
Every summer, talent pours into the Valley, with interns taking up apartments and hotels and train stations, filling up hackathons and picnic fields and event halls. (These things happen at other technology centers in the US, of course. But SV is where it's at).
This means you'll get to meet some incredibly talented people. It means that you're probably going to have a lot of fun doing it. And it also means - given that you'll be spending 3 months in such an environment - that you'll learn a lot.
You're an undergraduate, and you just survived yet another semester of NUS. You're probably awaiting your results, and worrying about your CAP, and planning some holiday trip (take your pick: Thailand/Vietnam/Bali) with friends.
A summer internship is a 3 month stint at a company. During which you'll essentially be working as you would a real job. Typically, you get assigned a team, a manager and you ship production code.
$1
An internship with a large company in the valley pays USD$7000-USD$8000 (Google, Facebook, Microsoft, Palantir), with free lodging, food, bikes, laptops, etc depending on the company and ridiculousness of the recruiting department. An internship with a valley startup pays USD$3000 - USD$8000, depending on the stage of the startup, and your role.
So reason #1: you'll earn a lot. Way more than if you spend your parent's money in Bali. (Well, you'll still be spending money - cough, Amazon Prime cough
- but at least it's yours).
Money is not a good enough reason, though. There are other more important reasons. We cover some of the more obvious ones here:
If you want to be good at what you do, you better optimize for learning. Interning in the valley, with some of the brightest people in computing, will teach you way more about the industry and computer science than studying books alone ever will.
Practically speaking, what this feels like is that you'll now return to school with context for all the things your Professors are teaching you. You'll find more things interesting and useful. You'll see why Machine Learning is hot, even if the equations your professor throws on the board are anything but. You might even begin reading papers, hoping to collect as many good ideas for technical projects in the future.
As you learn you become more attractive to future employers. Its win-win.
During your internship, you'll get to try out what you actually do after graduation. A tech internship is essentially a trial for what working full-time at the company is like. You spend three months discovering what works for you.
The best part is, if you like it, you'll already have a foot in the door at the company, or any other company for that matter. Imagine what having Google, Microsoft, Facebook or any other tech company on your resume will do for you.
Doing an overseas internship is pretty much like an extended vacation: you'll have a ton of fun.
There are plenty of places to go in the US, and too many things to do. Be it shopping discounted designer goods at Gilroy, wine tasting at Napa, fruit picking at Portola Valley, visiting the MoMA, skydiving, hacking at the hackathon of the week (there is one every week, trust us), or hiking at Yosemite
- you'll be spoilt for choice.
Additionally, you get to meet the who's who in tech and get to know other interns from other colleges.
The following list of companies have at some point taken interns from NUS.2
- Apple
- Asana
- Dropbox
- Microsoft
- Palantir
- Quora
Don't just restrict yourself to the companies here though. Applying to multiple companies greatly increases your odds of getting an offer (since tech companies are notorious for the false negatives in their recruitment process).
Be aware of various immigration restrictions such as the two-year home-country residency requirement for certain countries3 and the timeline for H-1B visa application which affects students that need H-1B visas and graduating in Semester 2.
Companies with offices outside of the U.S. usually are not too concerned about these issues, as they can post you to a global location first until they can bring you to America.
The recruitment process process differs from company to company, though they overlap somewhat.Here is an overview of the typical recruitment process:
- Apply
- First Contact
- Phone Screens & Technical Interviews
- Offer
This is the first step you need to take. Whether it's sending your resume, getting a referral, or contacting a recruiter. Many people don't even get to doing this. They think that they don't stand a chance and so they don't even bother trying.
If you don't make contact, you are never going to get recruited.
Application channels:
- Job's site, eg. <google.com/jobs>
- Career fair
- Info sessions/Tech talks
- Referrals (from friends, previous interns etc)
Internship applications start in the fall (Sept) and stretch till Jan. You should start ASAP. Don't wait till its too late.
As you would imagine, summer internships are highly sought after. You'll be competing with students from all over the world. Applications start as early as the fall (once the summer ends) and spots get taken over time. The latest you can probably expect to get an offer is one month before the summer. Though that is the exception. The later it gets, the less openings there'll be, both within the company and within the teams. Naturally, the more attractive companies and teams are the first to go.
There is usually a long and painful wait between the first step and this one. Most people don't even hear from the recruiters. Just imagine the number of resumes the recruiters receive and the number which they are physically capable of responding to. So don't lose heart if you don't hear from the them. See how you can make your application better the next time round and try again next summer.
When a recruiter gets back to you, he/she will then brief you on the upcoming rounds and also will be your point of contact for the process. This includes scheduling interviews and collecting various information from you.
The difference between a phone screen and technical interview is fairly arbitrary. You can think of the phone screen as a watered down technical interview. It is less demanding and usually way less technical. Phones screens are meant to weed out the people who look good on paper but really should not proceed any further.
Technical interviews, on the other hand, are usually more involved and involve coding and problem solving. You generally get at least 2 technical interviews (possibly more). Each interview usually lasts for about an hour and are conducted over skype/phone and an online collaborative document where you are expected to code.
Most people fail here due to a lack of preparation.
Some of the questions asked might include:
- Recall questions
- CS fundamentals
- algorithms
- operating systems
- networks
- Technical discussions
- Coding
- Problem solving
- Runtime analysis
Some companies prefer to have these instead of over-the-phone interviews. Some only do this for full time recruitment. Some companies fly their engineers down to interview a group of people instead of flying everyone there. It's different everywhere.
Onsites don't differ too much from over-the-phone interviews besides you having the advantage of body language.
Also, don't worry if a company proposes this. They'll cover all related costs (flight, hotel, transport, meals etc).
Great, you made it. Its time to decide if you want to take the offer from the company. You might want to think about the following things before you put your signature on the piece of paper. This applies even more so when you have more than one offer on the table.
- Product: What product will you be working on? Are you excited about it?
- Compensation: Don't forget to factor in taxes, housing, food, cost of living and other factors besides the absolute paycheck. These things add up.
- Location: This really boils down to personal preferences. Assuming its an internship in the U.S, you might want to try a different city if you've already been in one the previous summer.
This is one of the biggest barriers faced by students. We literally have nothing relevant to put to get the recruiter's attention. The good news is, that everyone if in the same boat, or at least the people trying to secure their first internship. The key point to note here is that tech resumes differ from normal resumes.
The following resources best explain how to get your resume right:
- http://www.careercup.com/resume
- https://www.quora.com/Job-Search/What-are-common-mistakes-that-applicants-make-when-writing-their-resumes-for-tech-companies/answer/Gayle-Laakmann-McDowell
- http://www.youtube.com/watch?v=rEJzOhC5ZtQ - Video of a presentation by Gayle Laakman McDowell who worked as a software engineer at Microsoft, Apple and Google and was on Google's hiring committee. Great insights.
There are a ton of resources for this on the internet.
At a high level, the interview is really meant to be a conversation to assess:
- If you can fit in as a "peer", based on your ability to take part in technical discussions and to converse on some level with your interviewer.
- How well you measure up against other candidates. Are you good enough?
- Whether you are someone they'd want to work with.
It will be expected of candidates to have the following set of knowledge (non-exhaustive list):
- Basic programming skills (able to write code)
- Appreciation for computation semantics - primitives, combination, abstractions, even if implicitly
- Algorithms and Data structures - you're expected to have completed and have scored well in the algorithms and data structures course, or have the equivalent knowledge
- Sensibility in systems design and database design - understanding the trade-offs
- Know at least one programming language well, and ability to pick up a new language on the fly
- Basic knowledge in logic, formal systems, and proof systems
- General problem solving skills
While most companies differ in their interviewing style and approach, there are some common patterns across the board.
Most interviews last from 45 minutes to an hour.
Outline of a typical interview:
- Intro, soft questions
- Actual questions (usually only one) - the bulk of time is spent here (30 - 45 mins)
- Q&A - you get to ask questions here.
There are 4 major types of question an interviewer may ask:
- Design - you'll be asked how you'd design a particular feature (the back-end, the database etc.). For instance, you may be asked how you would implement a simplified version of Facebook's news feed.
- Coding Question - You will be given a problem and you'll be asked to implement the solution. While algorithmic questions are highly likely, an ad hoc type of question may also be possible. Sometimes an interviewer wants to assess your basic coding ability or your familiarity with one specific programming language that you may have claimed you were familiar with (e.g a pointer specific question in C/C++).
- Test Question - You may be asked how you'd test a particular feature or code.
- Logic Puzzles - Brainteasers are increasingly becoming less common but they still exists.
- Tell me about a project that you've worked on that's technically challenging and walk me through your problems and how you solved them
- Tell me about yourself
- Tell me about X (where X is found on your resume)
- Do you use our product? What do you love about it and why?
- Why do you want to join X? (where X is the company)
- What is
0x05+0x1a? - What is a deadlock?
- What is the runtime of the various operations of a hashtable?
- What is the difference between a process and a thread?
- Explain to me what happens when I type "google.com" into the address bar
- Design a url link shortening service.
- Find an element in a sorted, pivoted array
- Pivoting a sorted array:
[1, 2, 3, 4, 5]=>[4, 5, 1, 2, 3]
- Pivoting a sorted array:
- How many ways are there to buy a given amount of coke if they come in the
following sizes: 1, 6 and 24?
7 => [1, 1, 1, 1, 1, 1, 1], [1, 6] => 2 ways
- Implement a stack with an additional
#minmethod that returns the min element in constant time.
Don't worry if the questions above seem hard or foreign. Interviewers were college students before and they know how much you are "supposed" to know based on the classes you've taken.
Contrary to some of the advice you might find on the internet. You really should practice technical interviews and not go into your first one cold. It helps more than you can imagine.
Don't just read questions and their answers off the internet. Get a friend, a senior to interview you. Prepare for it like you would the real thing and go though the motion.
Don't underestimate any interview. Even a phone screen. Your interviewers will probably expect you to bring your best self to the interview so make sure you're fresh and ready for it.
While not super critical, soft questions tend to start the interview. You won't want to get off to a bad, stuttering start do you?
No one expects you to parse the question the first time. No one expects you to respond immediately. When given a question take a few seconds to think before speaking. Jumping to conclusions is really bad and reflects badly on you.
A typical scenario:
- Interviewer: "What is the run-time of your solution?"
- Candidate: "
O(n)" - Candidate: "Oh. wait."
- Candidate: "Erm,
O(nlogn)" - Candidate: "jk. O(n)"
Breath, relax and think before you speak.
This is really about communication skills. When asked an ambiguious question, do you simply assume something is the case? You can and should always ask the interviewer to repeat stuff, to give examples, input/output to problems etc.
The aim of the interviewers is to assess your competency as an engineer in the short amount of time they have. Part of engineering is understanding and being able to weigh trade-offs involved in engineering decisions. For instance, you may be asked to implement an abstract data-type that can store data (perhaps something that emulates the behavior of an array). You may simply start with an array, to which you face a problem when your static array runs out of size. You may then change it to a linked-list, and you realize there are issues with fragmentations. Here, there are trade-offs and while the interviewer may guide you through it, it helps if you are mindful of them to begin with.
This applies to all types of problems (design, coding, etc.) For instance, when asked to implement a routine, it may be convenient to make assumptions like the validity of the argument values passed in. While this is generally a reasonable assumption to make, it doesn't hurt to check and to practice defensive coding in your implementation.
Do not underestimate problems that appear simple. Always assume that the interviewer is an experienced interviewer, and has a specific intent in giving you this problem. It may be that there are corner case traps that you were not careful of, or that there are even more efficient solutions that you did not think of. It could also be that the interviewer wants to see how elegant your coding is.
After all, much of a software engineer's work is to implement routines and modules that are not that complicated, but in an elegant, concise and maintainable manner.
That said, do not overthink when given a simple problem. It could simply be a warm-up problem or a necessary building block to other problems.
This is really important. The whole interview should be seen as a conversation with the interviewer and to allow him/her to understand you better. When you're stuck, don't be too afraid of asking for help (of course, you should spend some time thinking through the problem yourself first).
Its really hard to evaluate a candidate that doesn't speak or explain his/her thoughts. Getting the correct answer is only part of the process. How you get there is way more important and useful for evaluation purposes.
This is a simple rule: always err on the side that your interviewer has worst OCD. You won't want to come across as sloppy, would you? This includes semi-colons, braces, indentation, syntax (its not that hard). Unless explicitly stated, always use a proper language, not pseudocode.
Do you test your code? The interview should be no different. A typical mistake people often make is that they simply stop after they've written down the solution. Don't stop there, test it, check for edge cases, this shows your interviewer what kind of an engineer you will be if they hired you.
The way I usually go about doing this, is once I'm done, I'll say something like: "I'm going to step through my code now to make sure I didn't make any obvious errors". I'll then list down the testcases (input/output) that I'll be using and meticulously step through every line, every variable assignment...
This is a no-brainer. It demonstrates interest in the job. Do some research and have a couple of questions ready to ask at the end of the interview. Remember, the interview works both ways.
It can be pretty daunting. For some of you, you've just started computing/programming. You are probably thinking about how you can keep up with everyone else. Well, the good news is that you are not running out of time. Its not too late to start now, and you certainly can become good enough to get to where you want to be.
For a start, read this document: Notes to Computer Science Freshmen, From The Future.
Welcome back. If you didn't read the document and just stepped over the link above, you really should. The document contains information that students, like yourself, wished they knew when they were in your shoes. The document provides a nice basis for this section. It covers advice on how to do well in SoC, or Computer Science in general. Most of which is highly relevant if you want to do an internship at a tech company. After all, if you are doing well, you chances of getting that internship you dream about get that much higher.
The key point here is to optimize for learning and learn the basics well. Where possible, take harder classes and challenge yourself. Its also really important to not let your learning rate be dictated by class. There are hundreds of people in school just like yourself, what's going to set you apart from them?
We can't stress the importance of this enough. Unless you've somehow manage to prove that you can program (Winning Informatics Olympiad for instance), this is your best bet in showing the companies you can.
Being in college, your resume is probably empty or filled with irrelevant experience like National Service, being a Student Leader in some organization, Community service etc. Not to downplay these achievements, (which you should definitely put on your resume as they speak of your other qualities) but companies aren't exactly going to hire you to be a software engineer based solely on these qualities.
No. They are looking for evidence that:
- You can code
- You are passionate about what you are doing
- You are able to learn stuff on you own
Side projects are the best way to do all three. Plus, they have the added bonus having great learning value. Think of something, build it. Better yet, learn git, version control your code, and share it on github. See nusmods.com for a great example of a side project. You'll probably use it soon or already have.
As mentioned in the previous sections, internship applications are really competitive. This makes it even more important that you are able to differentiate yourself from your peers.
Summer and winter breaks are an excellent time to do just that. If you don't get an internship this summer, make the summer count towards making next year's application that much better. Companies re-interview candidates all the time (obviously with a reasonable period of time between interviews) so don't worry that you didn't make it this time around and focus on doing better the next.
Code widely. The more hours you clock coding under you, the more proficient you'll become. You don't need to be implementing complex algorithms or machine learning systems all the time. Even small web projects with some logic code help. The hours you put into the practice will train and strengthen your proficiency in implementing an intended logic in an elegant and concise manner. This helps a lot.
That said, be daring to explore. If you're feeling comfortable all the time when coding, something is wrong. When you learn a new algorithm or data structure, go implement it in your language of choice. Play with it. Optimize it. Understand it well. Internalize it.
Reading existing code also helps. There are many open source projects and there is no lack of good quality code you can learn from. Many programmers upload their code for certain data structure or algorithms freely on their website or blogs. Implement some yourself, and then look at how other (hopefully smarter and more experienced) people implemented theirs. There are a lot of things you can learn from this; from new programming language constructs or syntactic sugars you never knew existed, to very basic patterns and styles that make up good code.
You don't start preparing for technical interviews when you know you have one coming up.
Some things like data structures and algorithms knowledge, problem solving skills and coding proficiency take time to build up. You'll probably need more than a few months to get significantly better at this, so start early, and do it consistently. Practice makes perfect. The best part is that the skills are useful beyond just the technical interviews.
Going through the recruitment process is inevitable. Don't wait till its too late, when you're in your final year, when a lot is riding on the outcome of a particular interview to start.
In addition, ask seniors for help. They probably can give you more tailored advice and help you more than you imagine.
Getting an intership is hard but its really important that you keep at it (if you want to get one of course). You can only get better at interviewing and your experience through the process (even rejection) will help you find out the areas which you need to improve upon. Its never too early to start, even as a freshman (yes, we have precedence).
The following CS modules are mandatory for all students. Yet, it is easy to neglect them and/or not give them as much attention as they deserve. Many students mistakenly think that, for instance, discrete math is a waste of time and completely irrelevant to programming and so they take it less seriously.
Every incoming freshman has to take this module. It is super important. Don't take it lightly or give up when you find the module hard.
For most people, this module's project will be the first major software project they've done. Its a great opportunity to gain some experience regarding application design, working with a larger than usual codebase, as well as level up in terms of your coding competency.
In your first semester, you get a choice between CS1010 and CS1101S. Take the latter. No seriously. While CS1101S is obviously going to be more intensive, both in terms of time and effort, the rigor in the module helps you grow.
In addition, CS1101S is definitely more comparable to the introductory programming modules of top colleges than CS1010, and given the competition for internships, it should be pretty obvious why you would want to take the more rigorous module here.
Most freshmen fall into the trap of thinking that because they are new to Computer science, they should take the lighter module to learn progressively. Many of the seniors who took CS1101S had no background. They didn't do badly. There are, of course, exceptions. If you think you won't be able to cope with the heavier course load, ask a senior or better yet, the professor.
Some people take CS1010 for a free A. Frankly nothing is free. Think about what you are paying for this supposedly free A.
In your second semester, you get the choice between two tracks for Data Structures and Algorithms. The first is "accelerated", comprise one 6MC module. The other comprises two 4MC modules that will span two semesters.
If you can do it, (you need an A- and above for your introductory programming module), you should do CS2020. It cannot be stressed enough how important Data Structures and Algorithms is in getting an internship offer. (See the technical interview section.) Learning these concepts earlier means more time for you to think about them and get good at apply them.
Again, CS2020 is more aligned with the equivalent courses in the top CS colleges.
Take this class seriously. It is unfortunate due to the large class size that past iterations of this course have not been conducted in the most conducive manner. However do not underestimate the importance of acquiring strong and formal knowledge of algorithm, proofs, and basic complexity theory.
If you get the chance, become a TA. It is no secret that you learn when you teach. Most people are turned away because teaching is a highly time consuming endeavor. It's true, so do plan your time wisely.
It is hard to measure. Most of the recruiters are familiar with a US GPA system which is out of 4.0 but NUS's GPA is out of 5.0. That said, this is most likely not the most important factor.
Your grades should be good. After all, it's one of the signals recruiters use to tell if you know your stuff, albeit a pretty flawed one. That being said, your absolute CAP is way less important to the companies than the other skills mentioned.
Your CAP is probably only going to be useful in the early stages of the recruitment process. Even then, there are other ways, better ways, to make your resume stand out.
- A Guide for Technical Development from 'Grow Beyond With Google'
- Great article with advice on how to get an internship and why you should want one.
- Cracking the Coding Interview. Talks about the recruitment process, gives advice on how to ace the technical interviews and has many practice questions.
- A piece by the author of Cracking the Coding Interview on getting your resume suited to the company you are applying.
- Get that job at Google. Everyone links to this. A must read.
- http://www.quora.com/Algorithms/What-are-the-ways-to-utilize-6-months-to-build-skill-set-to-get-into-Facebook-or-Google
- https://www.quora.com/Engineering-Recruiting/What-should-I-do-in-the-next-6-months-to-get-into-a-company-like-Amazon-Google
- https://www.quora.com/Algorithms/What-are-the-ways-to-utilize-6-months-to-build-skill-set-to-get-into-Facebook-or-Google/answer/Nandish-Punter
- Get that job at Facebook: A note by an engineer at Facebook about the entire process and what to look out for.
Footnotes
-
http://www.vox.com/xpress/2014/11/24/7275635/tech-intern-salary ↩
-
Taking international interns is harder for companies as they have to deal with the visa process and it costs more to fly you over and house you. ↩
-
http://travel.state.gov/content/visas/english/study-exchange/student/residency-waiver/eligibility.html ↩