As a rising senior at Swarthmore College, I had the pleasure of interning at Nest, a home-automation/-innovation tech company started in 2009 - in true Silicon Valley fashion - in a founder's garage. Over the winter break of 2013/14, I happened upon a post from an alum on Swarthmore's Experience portal advertising internship opportunities at Nest, and proceeded to complete four interviews by February, three with members of the team I was joining and one with the team leader and manager, Yoky Matsuoka. Having the chance to interview with (and eventually work with!) a MacArthur Genius Award winner, one-time Head of Innovation at Google, and cofounder of Google[x] sold me on Nest and I accepted the subsequent internship offer without a second thought.
Nest is a wonderful, exciting place to work: a company with small-startup intensity, mid-sized-company clout, and Google-sized perks, it creates beautiful products with Apple-esque1 attention to detail and plenty of fascinating science powering them. I interned on the Technology/Algorithms team (naming teams is difficult when the company doubles in the space of months) that is responsible for designing, prototyping, testing, and developing the algorithms that make the products "smart". Being the sole undergraduate on a 23-person team (the next-youngest person was 25; the other two interns were PhD students) meant two things: that I was learning about software engineering at a somewhat alarming rate, and that Swat had uniquely prepared me to contribute to a superbly talented, incredibly intelligent, and mind-blowingly nice group of people.
Apart from getting you to think about trying to work at Nest, I'm writing this to give you some context for your time at Swat. These are the three things I took with me from Swat into the "real world".
Once you get a job, the code you write will directly impact it. School is really the only practice that you get to have, and so Swat is the best time to learn good coding habits. I'm sure your professors have lectured you about all of these things, but I'm hoping that hearing it from a student gives it more credibility. There are three simple things that I got a lot of practice with over summer, and having practice with these will get you a long way:
Git. Yes, "Git hell" is very much a thing. Yes, Git is weird and hard to learn. But Git (and version control in general) is a fundamental part of software development. And it becomes even fundamental-er when you work with other people. Working without version control is like not pressing "Save" when you write a paper. Version control is a Ctrl-z that keeps working long after you've closed your editor. Learn it. Start checking in your lab code to Git repositories (Github gives free private repos to students) and practice commiting, pulling, and pushing. I promise being familiar with Git will help you if you do anything with code after you graduate. And possibly even if you don't.2
Whiteboarding & Top-down Design. Being able to reason about and talk about your code without a computer - on whiteboards, on paper - is something people actually do outside of school. Writing pseudocode isn't just some made-up thing our professors like to do. Reasoning about your code's run-time complexity, figuring out a good top-down design, and planning the inputs and outputs of each function all allow you to write better code more effectively. Seriously practicing modular, top-down design will save you a lot of time and prevent you from having 200-line-long functions that even you don't fully understand. I geniuinely recommend that you use CS labs as a chance to practice good coding habits, so that you don't have to figure it out while juggling the real-world consequences of after-graduation-work.3
Documentation. Hearing people say "My code is done, I just need to add comments" makes me sad. Remember my harping on about top-down design? A big part of that is documentation. When you start writing a function, don't just start writing it: take some time to think about what steps you'll have to take. Use comments like a paper outline: write out the big steps, then start fleshing them out. My functions start out as a series of comments, and the code grows into the spaces between them. Often, I take a shortcut and make a single function call under a comment, before that function is actually written. That way I break down what functions I need to implement into smaller and smaller pieces. Bite before chewing, call before implementing. This is an easy everyone-wins way to have comments in place when your code is already done.
There's a pragmatic reason for comments too. In school, we think of code as something that's written once and graded once. But in reality, while code is written once, it's read and used dozens, hundreds of times. Code is written to be used, and the comments are the instructions, the logic, the reasoning behind it. When you put a ton of work into code that does something useful, you usually hope that lots of people will use it and tell you how awesome you are, how much time you saved them, etc. But no-one will use code that they don't understand. That's why function comments (docstrings) are so important. Imagine Googling a function that you want to use and not being told what it does, what arguments to pass it, or what it returns. And then imagine crawling through the source code only to realize that it has no comments whatsoever. How is that?
Professors don't want you to comment code just for their sake. It helps you understand what your code is doing when you read it a week later, and it's crucial for when you write real code that real people will use. I promise comments are only a pain when you put them off for the end. Comments are friends, not food.
2. Working with People
I think a good motto to think about work by is "Don't be a butt." Most jobs require you to work with someone; most people don't like working with butts. Be someone that you'd want to work with. If you know that you need to be a butt to do well in your chosen field, go for it. But as far as my now-less-limited experience goes, people try not to hire butts. So if you have the choice, choose to not be a butt.
The one thing that all the VPs (and the two co-founders) at Nest that we got to hear from as part of the internship agreed on was that the adage "It's not what you know, it's who you know" still applies today. There are an unprecedented number of great people graduating from upper-level institutions today looking for jobs at great places. How do recruiters sort through all of them? Eye-catching resumés and solid cover letters help, but getting someone to refer you, to vouch for your not being a butt, and/or making a personal impression at a career fair will make it more likely that they'll actually even read your documents. And having somewhere that they can learn more about you will get you that first interview.
So trick out that LinkedIn profile. Work with career services on your resumé. Network. Networking isn't a dirty word: treat it like making friends with people that could help you and that you could help someday. Go to career fairs, introduce yourself to people, talk to alums and friends that might know someone you want to meet. Add them to your LinkedIn network so that you can get in touch about internships, jobs, and the like. When you do get your internship, meet your coworkers. Remain steadfastly unbuttish. Don't burn bridges. You don't have to be a bubbly extrovert - I'm certainly not. But meeting people, leaving enough of an impression that they remember you when you email them, being enough of a non-butt that they don't just dismiss any request you make, will open more doors for you than any number of cover letter drafts.
3. Being a Swattie
In the end, what I came to appreciate at Nest was just how many doors open for students with CS experience who can do more than just CS. Liberal arts students who can leverage their knowledge in other fields can really add value. In my case, my Physics major allowed me to be comfortable with the mathematical modeling and analyses we were doing; being able to talk about ideas clearly (like in seminars) and write papers / emails clearly (like in all classes) was invaluable. So flaunt those non-major classes. Really sell the fact that you're a flexible learner. Anyone with access to the Internet can learn to program - it's Swatties that do that and juggle 20 classes outside their major.
And the best thing about us liberal arts kids is that we know how to learn quickly. My favorite kudos from this summer was for being quick on my feet, for digging in and asking questions about things I had never even heard about before. And we all do it every day that we go to classes, or struggle with problem sets, or trudge through reading. Every day of hard work is learning practice. And I think it's safe to say that people like hard workers.
I got my internship through Swat's Career Services. The programming skills I learned and practiced in CS classes were put to use every day at work. But it wasn't just CS: Swat set me up for success by springboarding me into this internship, and equipping me with the skills I needed to learn fast, work hard, and contribute to multiple teams at Nest. And I must've done something right because I was invited to work for them full-time after I graduate - an invitation I gladly accepted.
I'm sure that you are worrying, or will worry at some point, about your place in the real world as a tiny liberal arts college graduate. I'm here to tell you, people like Swatties! We work hard, we learn fast, and we can write and talk about our ideas like the intelligent people that we are. And even if you've only taken CS21, Python and the basics of progamming that you've learned will be incredibly helpful: you can make a computer do things. In an age of computers being everywhere, that's pretty cool. So be proud of your CS experience, rock your Swarthmore pride, and do things that'll make you happy. And above all, don't be a butt.
Thanks for reading.
 Nest drew lots of talent from Apple - for example, Tony and Matt (the cofounders of Nest) were former Apple engineers.
 Using Git allowed my supervisor and I to easily work on research papers while on opposite sides of the country. Yes there are Google Doc-like programs for LaTeX (ShareLaTeX and WriteLaTeX are both great) but they don't work offline. And if you overwrite each other's edits you can't get them back.