Monday, December 29, 2014

Getting People to Be Better

I’m obsessed with self-improvement. I like to think of it as a more productive form of narcissism. I don’t spend much time staring into mirrors or having power fantasies, but I do spend an inordinate amount of time thinking about how I can be better. Be it the tools I use, the technology I pursue, exercise, or even recent forays into the world of meditation and mindfulness, I always try to have some “construction site” in my self that is making me better. To me, stagnation is the enemy.

Watching these changes occur in myself and slowly becoming the person I want to be is one of the most deeply gratifying experiences of my life. I see the benefits in myself, and can’t help but turn that introspective lens around. Perhaps the second most gratifying experiences in my life come from helping others in the same way I try to help myself. I love sharing knowledge. It’s how humanity progresses.

In this post, I want to share my experience with sharing knowledge, and encouraging others to develop skills that I think would improve their life. This is simply the most consistent approach I’ve derived from many failed and successful attempts.

The obvious question has probably already come up: what business do you have pushing your experiences onto others?  If there’s one thing you take away from this post, it’s this: none. There are very few things more unwelcome than undesired help. The very first checkbox in getting people to be better is asking yourself whether or not this person could legitimately benefit from your help. Or, more practically, if they even give a shit.

Let’s take the text editor war as an example. If you’re like me, you probably started off using a good, but basic text editor like Sublime Text. I was productive enough, and didn’t see a need to change. Every time somebody would insist that Vim or Emacs were superior, my internal response would always be the same: go away. No degree of compassion or pedagogical skill would have steered me away from Sublime, because I didn’t care.

The most important factor in sharing improvement is being welcome. At the end of the day, their drive has to come from within. Pushing your practices onto others will never work. Instead, make non-threatening suggestions. Discuss your alternative way of doing things, and how it’s benefitted you. How did meditation help you? Why do you think the month-long Vim learning-curve is worth it? Don’t push an agenda; pique interest. If that doesn’t work, back off.

Eventually, I did undertake the head-bangingly arduous task of learning Vim. After watching a friend manipulate a Javascript file like a musician, I decided myself to welcome his advice and switch over.

My friend, who we’ll call “Alexa”, was a History major at my university. From when I first met her, I knew that she was smart, driven, and even technically minded. Being in Berkeley, she’s started to hear more and more about coding. People always say it’s worth learning, but she was never really sure how or why to approach it.

Once Alexa shared this with me, I realized I had legitimate knowledge to offer her. I talked to her about my experiences with programming, how it’s helped me, and how I think it could help her. No agenda pushing, no lesson plans, no technical talk. Pure interest piquing.

If you manage to succeed at this, you have to be careful. This is the most unstable period of the learning process. The most common approaches I’ve seen at this point are: (1) going on a huge rant about the subject and why it’s amazing and how you do it and how you learn it and why it’s amazing… (2) passing over a single webpage with a few paragraphs on the topic, then leaving the person in the dust, (3) saying your way is the best and telling them exactly what to do (“learn Python using Vol. 2.0.3.7 of Advanced Python for Air-traffic Controllers…”).

People love to learn. Getting people excited about learning is easy, but cultivating sustainable interest is a subtle and fragile exercise. There needs to be a easy entry point. (1) ignores this by overloading the person with information and immediately diffusing any interest via unintentional intimidation. Next, there needs to be a clear path. (2) ignores this by leaving them to fend for themselves, where they’ll likely lose interest and return their focus to something more familiar. Finally, there needs to be the freedom to explore a little, and personalize the learning experience. (3) ignores this by over-specifying, removing all possibility of creativity and breadth.

The question I always ask myself at this point is this: how did I learn? What was my entry point? If my entry point sucked, what do I wish it was? Your goal is to present a initial, detailed plan that should always leave them with the feeling of knowing what to do next. For Alexa, I suggested a series of Coursera classes on programming, followed by enrolling in some of the University’s introductory CS programs. That’s effectively how I started, after all.

Learning something new is like exploring a blackened cave without a light. Without guidance, trying to understand where you are at first is a daunting and hopeless task. You flail around in the dark, making little progress. The game plan you provide is like taking their hand and putting in on the cave wall, where they can follow it and begin to mentally etch out their surroundings.

Once that hand is on the wall, there is very little you need to or should do. Independence and self-discovery are the keys to learning. Holding onto them and making them feel out every nook and cranny of the cave as you know it will do nothing but confuse them. Guidance can be provided when it’s requested, and you may want to check in periodically and ask how things are going. Connect with them as a mentor, a resource, but don’t helicopter.

I’d see Alexa and ask her how the classes were going. Usually very well (they can teach her better than I can after all), but sometimes she would have a question that I would try to answer. No problem. She was feeling out the cave by herself, understanding what it looked like, and asking for help when she knew she needed it.

Watching your friends go through the path of learning you yourself went through is an awesome experience. Once they start to know their stuff, I try to do one last, somewhat counterintuitive thing: diminish my status as their mentor. The last thing you want to do is keep talking down to them as some absolute word of authority, putting them in a never-ending game of catch-up. Have equal-eyed discussions with them about the subject, besides being mutually beneficial and a ton of fun, helps to confirm their efforts. Of course you can still provide help, but do your best to validate as well.

Alexa decided to change her major to CS, and we still talk about technology and coding all the time. Her excitement about the subject is contagious, and I feel constantly invigorated by her newfound interest. Bringing people into your world is incredibly gratifying. Your experiences and techniques for living life are invaluable to others. Not sharing them is just inefficient; not to mention you get serious return on investment. You should give it a try, but do it right.

Tuesday, August 19, 2014

Coding in the Real World

Tis the season of job hunting once again. Job listings are blossoming and us eager college students have begun to swarm. Resumes are being dusted off, and the sounds of keyboards implementing practice algorithms and data structures fills the air. 

In a previous post, I outlined my experience with the internship application process. I had spent several months embedded in it, and wanted to share what wisdom I had managed to scrape together. What I couldn’t share was the experience of the internship itself. What’s the point of all of this? Is an internship hard? Will I be able to handle it even if I get an offer?

It’s funny how overlooked those questions are. It’s almost suspicious that nearly the entire focus of the internship process is in the application. Amongst the Berkeley community, those who have withstood the trials of an internship seem to radiate this mythical aura from the perspective of those who haven’t. The kids today might describe them as “legit”. People want them in their group projects because they must know so much now.

This past summer I interned at a San Francisco startup called Endless that does really awesome stuff. I want to convey not only my experience, but the experience of several of my friends and colleges that also went through this mythical ringer. How “legit” did we become?

Well, it turns out that the answer depends very much in how you define “legit”. My friends and I are all walking away from internships with the same impression of difficulty: the application process was much more strenuous and challenging than the job itself. Don’t get me wrong, we faced a problem massive in scope and so to were the number of problems that came along with it. Problems of engineering, design, communication, marketing, you name it. It simply turns out that writing code in the “real world” is a very different experience than writing it in the classroom.

The problems you face in the professional world of software production will tend towards design, not concept. This is a very bizarre transition for someone who had learned to code in a college environment. Professors give skeleton code, leaving the details of implementation to us. Writing a program for them isn’t hard once you’ve grasped it conceptually. For example, implementing a modified tree data structure or optimizing matrix multiplication in a multi-threaded environment.

Production code seems to be the opposite. You’re given nothing other than a blank text editor and a list of requirements. Very rarely will you have to employ some mind blowing data structure or algorithm, and even if you do, it will be even more rare that you have to implement it yourself. It’s an exercise more akin to writing the skeleton code itself and then filling in the blanks with libraries and technologies, instead of student code.

The most valuable thing you’ll learn at a internship is simply the process of writing code in a productive way. How to effectively use tools like Git and GitHub. Collaborating with pair programming and code reviews. In school, programming is all about writing code. In the real world, programming is all about talking with other people, and then writing some code maybe.

What about all of those trendy technologies like Node.js, MongoDB, etc? What about APIs? Do you get to learn those? Yes. And they’re easy. Learning MongoDB or jQuery is nothing like taking a class in Databases or Web Design. These technologies are highly optimized to be as simple and magical as possible. They abstract out the difficulty. It’s why they’re popular!

There’s a phrase I ran into once that I think describes the situation very nicely. In school, the requirements of code are easy and the implementation is difficult. In the professional world, its the requirements that are hard and the implementation that is easy. A lot of my friends are intimidated by an internship because they see the difficulty of the interview process and believe that they have nothing to offer. Or, they believe that the difficulty of a computer science education is analogous to the work of a programmer. Forget about that. Getting an internship means that you are more than capable of handling the work.

This isn't to say that the work is easy. Most of us became interested in programming due to the challenges it so often provides us. As a student, you will be forced to constantly learn and grow and build upon your knowledge. Funnily enough, this doesn't change much once you leave college; it's just different. Conceptual rigor gives way to domain familiarity, and your obstacles become less about your intellectual limitations, and more so your willingness to plan ahead and become familiar with new tools.

With all of this in mind, my advice for a successful internship is this: be friendly, collaborative, inquisitive, and willing to learn. Don’t be afraid to voice your confusion or lack of knowledge. An internship is a training program in collaboration and software development. You aren’t expected to be a genius, or even know anything about their particular technology stack. Learn as much as you can. 

You won’t come back to college and destroy your compilers class because you’ve ascended into your planar coding form. Instead, you’ll be comfortable organizing the GitHub repo, know the best practices for organizing your code and keeping it readable, have intelligent and iterative code writing habits, be familiar with different coding models and project structures, be willing to review your friend’s code having confidence that you can help, and be a leader amongst your class project group.

If you’re at the point where you’ve got the offer and don’t know what to expect, relax, because you have nothing to worry about. If you’re still working on that offer, relax, because it’ll never be harder than it is now.

Tuesday, April 22, 2014

I Wrote This Post With My Mind (I Wish).

Looking back on those ridiculous old-timey predictions of the future is becoming increasingly surreal. Five years ago I would laugh at their naiveté, but recently it's become more humorous how much progress has actually been made towards those visions (FaceTime anyone?). Strides in AI have rendered movies like “Her” something that could be described as a relevant comedy. Machine learning has made Facebook more apt than us at recognizing human faces; something bred into our very neural circuitry.

I had the pleasure of installing a floppy disk drive for the very William Kahan today. He explained to me the technical limitations of his day which led to delightfully hacky quirks such as the shameless twist in a floppy drive IDA cable (a remnant of the A-B hard drive configuration of old Intel computers, apparently). It all sounded so much more makeshift than it is today. I couldn't help but think: “it's a pretty chill time to be alive.”

While that's all well and good, we're not going to talk about lame things like life-saving medicine, unbelievably powerful mobile phones, or automated cars. We're talking about the real important stuff: videogames.

On the advent of the Oculus Rift, Omni, Leap Motion, it's pretty safe to say that it's an awesome time to be a game developer. It's a kind of “wild west” situation that we haven't seen since the dawn of 3D-graphics. The excitement is obviously well earned, and will usher in a freaking awesome phase of immersive entertainment. Of course, you've heard this all before.

Something's missing. Those old-timey predictions never included us swiveling around in a chair with an awkward looking headset on, mouth agape like we're trying to attract a family of meerkats (they stick their head in your mouth to smell you; you didn't know that?). What did movies like Tron predict about our virtual reality future? What's the final frontier? Simple: full mental immersion. No controllers, no physical limitations, just a headset and a transplantation of our consciousness into the virtual world.

Don't get me wrong. We're very close to insanely deep immersion with things like the Oculus, and not so close to the Tron reality. That being said, there's no reason why we can't start trying to reach it.

A few weeks ago I had the privilege of participating in the Intel Wearable Games Hackathon in San Francisco. There I got to play with the new Galileo (it seriously sucks and that's all I say about that) and do what I love to do: make games. I was persuaded to go by my friend John, who's a cognitive-science major here at UC-Berkeley. We had been playing around with Arduinos, and John had been looking into EEG hacks. We took a crappy Mindflex headset he had soldered to an Arduino and decided it would be pretty sweet to base a game off of it.

John suggested a mind-controlled Tetris variant, which would have been an awesome modification to my Tetrocity project, however we ended up going with a more realistic vision of making a Warioware style game in which the player is prompted with a series of quick challenges, which we would tailor to the EEG. We eventually stuck a few more sensors on there, like a heart-rate monitor and pressure sensor, as an attempt to create a game around the mastery of your biosensory data. We called it the Mind Body Fitness Challenge.

Unfortunately the build wasn't very well documented. There's source code on my Github which isn't very interesting. It worked okay past some Galileo setbacks and the inherent poor quality of the Mindflex headset. What was really surprising was the amount of interest it generated. We were invited to present our project at the Intel 2014 GDC, and even to an incubator for the sake of turning the project into a real product. A few days ago we were invited to host a booth at a health fair. Like I said before: this thing barely even works.

Brain-based virtual reality isn't some far fetched pipe dream for loony futurists anymore. Technology has reached the point of absurd innovation that what was once reserved for the fantasy realm of Tron is capable of generating real interest, because it's actually possible. Or at the very least, it seems like it could be.

Neurohacking is very much in its infant stages. A new group on my campus is dedicated to cognitive technology and finding uses for the slew of new, powerful EEG headsets hitting the market like the Emotiv. It's a weird experience. There's so many applications, but nobody has really touched it yet. It's like a gold mine for inventors. For example, my friend John wants to change the way we test for impairment by using brain waves themselves instead of secondary indicators. Others want to track your circadian rhythm throughout the day so you can optimize your sleep schedule. I want to control videogames with my mind.

Imagine the layer of depth that could be added to a game like Amnesia. Imagine running for your life, scrambling into a hiding spot and trying like hell to calm down because the monster can smell your fear from the EEG and track you down. Imagine manipulating an entire game world so that your friend can literally explore your mind-scape (credit to my friend Niko for that idea). It's all very very cool.

Is any of that currently possible? Well, no. EEGs are very limited in what they read, and extracting meaningful information from them is a salty experience at best. Not to mention, they're way too expensive for commercial use. But, wasn't the same thing said of visual virtual reality 3 years ago? Now everybody is jumping on that bandwagon. Interest is what pushes industries forward.

There's clearly interest in neurohacking, so why isn't it a more popular sector of VR? Most likely because there isn't a tangible experience out there that's fueled by it. The technology simply isn't good enough. It's an awkward situation. To generate interest, you need to show that it has power. To show that it has power, you need the technology. To get the technology, you need interest. It really makes you appreciate the difficulties and risk faced by companies like Oculus.

I think neurohacking itself will eventually overcome the hump by hackers taking advantage of the Emotivs of the industry. Once we can show that even a primitive EEG can change the way we interface with technology in a deep and fundamental way, the technological innovation will explode. Maybe that application lies in videogames, maybe it doesn't. Either way, I'll certainly be trying my best.

The big question to ask is whether or not neuro-based technology is even worth bothering with at all right now. If we're some unknown distance away from viable, consumer-grade neurofeedback technology, then shouldn't we just ignore it until it actually happens? I would say no. Current EEGs are noisy and inconsistent, but we don't need to build technologies around current EEGs. If we accept that EEGs will approach some arbitrary degree of accuracy, then why not just build around that assumption? The only risk we run is that assumption proving false, which the very development of the technology will prevent.


Stay tuned for my brain-wave based survival horror game, Epinephrine. ETA: *cough cough* 

Saturday, January 25, 2014

On College Party Culture

The semester is fresh and Berkeley is slowly waking up from its winter stasis. The streets are packed and loud with students looking for a place to party.

The more time I spend in college the further removed I feel from that mindset. I certainly had it as a freshman. As someone who's always preferred a night relaxing with my buddies (or even on my own) than raging, I really wonder why I felt that way. How many of these freshman trying to get into my fraternity's party really want to be here?

I think nobody will need convincing that this comes from the popular image of college life, which we see in movies, TV shows, songs, liquor commercials, etc. At the end of the day watching a raging college party is way more entertaining than seeing a few friends study in the library, even though the latter is probably a more accurate representation.

As is typical for the pop-culture industry, it's also about selling you something: an image. An image which you have to live up to if you want to "do college right", and which you may have to buy a few brand-name liquors and albums to achieve.

First things first. There is nothing wrong with participating in the party culture. Seriously. Tons of people genuinely enjoy it and that's fantastic. If you're one of those people: party on.

Unfortunately, I'm not. While I had a lot of fun pledging my fraternity, my biggest regret in college is forsaking my studies that semester and permanently dropping my GPA 0.5 points. It's closed a lot of doors. I'd wager that a great deal of college students are also not willing participants of the college party culture and are facing an enormous amount of pressure to conform to it.

The irony is that college is about the complete opposite of what the party culture promotes: individual development. Not just academically, but development of every aspect of your persona.

I've found that there are four critical rules to maximizing your time at college: study hard, socialize, be physically healthy, and enjoy life. Do these however you want, but do them.

This is where party culture becomes damaging. Will partying help you be social? Definitely. But what about the rest? Studying? Definitely not. Physically healthy? Hard to say, but given the calorie intake of liquor we'll go with 'probably not'. Enjoyable? Entirely depends on you. If you're like me: not really.

College party culture promotes a lifestyle that is not only not universally enjoyed by those that are pressured to participate, but also damaging to the college experience in general. When I look back at how I've spent my time in college, I value the nights gaming or watching movie with my few, close friends far higher than partying at my fraternity. I've skipped tons of nights on frat row to spend it in San Francisco with my girlfriend and I've never regretted it once.

College is about becoming your own person. Don't let anybody or any body dictate how you should do it.

Friday, January 10, 2014

How to Interview for an Intership

These past few months I've been interviewing for an internship. For a lot of people, there's nothing special about this. Most of my close friends have done dozens of interviews already, but the experience was brand new to me. In fact, before November I had only ever done 2 interviews in my lifetime: one for Stanford, and one for my part-time job. I found the internship interview process very stressful, likely as a result of having such little experience with it all. You always want to know as much as possible about something you're getting into, but the nature of interviews seems to make this impossible.

This post is for the me of two months ago. Or at least, people like the me of two months ago. I want to share some of the nuggets of wisdom I gained by going through the motions, and ways you can prepare yourself. First off, I could end this post by deferring you to two books: Cracking the Coding Interview and The Google Resume. Both are by the same author, and both are great. If you have the time to make your way through these books, I highly recommend you do. You'll be mega prepared.

Preparation
Perfect your resume

This step seems obvious, but you should be aware that resumes in the tech biz differ a lot from resumes you've probably made before. Things like work experience are generally weighed less heavily than things like coding projects. Academic achievements are fine, but recruiters are going to be more impressed with your interaction and contributions to the "real world".

One of the main concerns I encountered while perusing interview advice was the impression that you haven't "done" anything, or that you haven't learned enough to be able to offer anything in particular. I have several friends who didn't even try because they thought they were so unqualified that they would just be wasting their time; that their resume would be tossed out immediately.

First off, this is almost definitely false. If you know basic algorithms and data structures (the second programming class I ever took), you're ready to interview. A close friend of mine will be interning for Facebook without a single college project on his resume (his GPA is stellar to be fair). At the very least, there's no harm in trying. Companies aren't like colleges. They won't hold it against you if you apply and get rejected. In fact, you're usually encouraged to try again, as they know you have the potential to grow as a coder.

If you really want to beef up your resume, try to work on something outside of the classroom. There's nothing wrong with putting class projects on your resume (as an intern you aren't expected to have tons of experience), but independent projects usually take precedence. One way to beef up your list is to take a project you've done in school and expand on it in your own time. I've had to program several games throughout my time in college, and it would be pretty simple to go back and add my own features, or implement a GUI, etc.

Another thing you can do is get involved with open source projects. You can find tons of these with a quick Google session, and there are almost always opportunities to contribute for all skill levels. Check out VLC Media Player for a good starting point.

The best thing you can do it think of a project you'll be passionate about and just do it. Not only for your resume, but to enjoy the process and learn as much as you can. I spent 3 intense weeks coding a game idea I had (Tetrocity), and it eventually became a main talking point of a lot of interviews. Even when it wasn't, a lot of the concepts and nuances I had learned in the process of making it came up.

This subreddit was also a great resource for me when I was working out the kinks of my resume. There's a ton of examples and experienced people willing to help out.

Prepare your expectations

This step is not so obvious, but is a harsh reality of the process. I once heard a quote along the lines of "apply for 30, interview for 7, get an offer from 1". The numbers will obviously vary based on your abilities, but the main point is that you need to prepare for rejection. In fact, you need to prepare for a lot of it. I was fortunate enough to get an offer from my favorite company, but I was rejected quite a few times elsewhere. If you aren't ready for it, it can be pretty disheartening.

First things first, a rejection does not always mean you "failed". Sometimes it does, and you should see those as opportunities for improvement, but a lot of the time the decision will simply be out of your control. I've interviewed for positions I didn't have the experience for, done well, and then been rejected because I didn't have the right experience. Oh well. I've been rejected because I wrote a code base that the company didn't take the time to read properly. Oh well.

I'm not saying you shouldn't take responsibility for negative outcomes. I could have made that code base more readable. The point is that rejections aren't the end of the world. They're an opportunity to learn and be better prepared for the next time. Say "oh well", learn from your mistake, and move on.

A direct consequence of all of this is that you need to apply to a lot of companies. A LOT. The competition is fierce and unless you're a rock star you don't want to put all of your eggs in one basket. It doesn't even matter if you aren't really qualified. Just apply anyway.

Apply correctly

This is one of those areas that I don't agree with, but it's how things go. The best piece of advice I can give in this regard is to avoid applying online. You're chances are simply much better if you can give your resume directly to a recruiter. If you go to college, attend your info sessions and career fairs. If not, look for events put on by companies and attend them. Try to find connections to the company. If you have a friend who has a friend that works at a company you like, ask to be put in contact. A lot of employees of tech companies are actually rewarded for referring a candidate, so they'll be more than happy to help you out.

If you can't do any of that, it isn't the end of the world. I found and applied to the fantastic company that I will be interning for on an online job listing website. In this case the idea of applying to as many companies as possible is even more important. Your chances are less, so increase your sample size!

Know the company

There really isn't a faster way to disappoint your interviewer than not knowing what their company does. It's in both your and the company's best interest if you are applying not just because you want a job, but because you find their work particularly interesting. Companies usually have tons of information online, so take the time before an interview to learn as much as possible. This will also help you ask intelligent questions and really get a feel for what the company is like. It's important that you'll be happy there!

Practice practice practice

I found that there are three main types of interviews: who-you-are, do-you-know, and can-you-do. You'll usually have many interviews per company (anywhere between 3 and 12), and how many of each type you get completely depends on the company. In any case, try to do your best to prepare for each.

Who-you-are interviews (aka "behavioral") are conversations about you as a human being. You'll be asked about your life, background, hobbies, experience, goals, interests, etc ("what kind of software do you like to write?"). These are meant to form a picture of who you are and if you'll fit into the company. There's no better advice for these interviews than to simply be honest. Acting like someone you're not just so the company will like you is only going to hurt everyone in the long run.

Other than that, simply be prepared to talk about everything on your resume (this shouldn't be too hard). Mock interviews are great for this.

Do-you-know interviews are akin to a game of programming trivia. You'll be asked a good deal of relatively factual questions ("what does the Java finalize() method do?"). While a lot of these questions will be 'you either know it or you don't', there's nothing wrong with making an educated guess if you're stumped. Sometimes deducing the correct answer is even more impressive than simply knowing it.

The subject of these questions is pretty dependent on the job qualifications. I've found that a lot of "general" internship programs will include questions about Object Oriented design, and language-specific questions for Python, Java, and C. To best prepare for these, make sure you're very familiar with your favorite language and don't claim to know something you don't on your resume. Brush up on your data structures and algorithms (including implementation features such as Java's HashSet load factor) and know their complexities. Also, pay attention in class!

Can-you-do interviews are harder to prepare for. They usually follow the do-you-know interview and involve you solving a problem on the spot. These questions can range designing an entire program to developing a single algorithm ("how can you check if a player has won a game of tic-tac-toe?"). The best way to prepare for these is to simply practice with as many of them as possible. Check out the two books at the beginning of this post for some great sources of practice problems. I made it my mission 3 months before my first interview to do 2 practice coding questions a day, and it helped immensely. CareerCup is another great source of questions and active discussion. Remember to try and do these with pen and paper or a bare-bones text editor. You won't have Google or Eclipse auto-complete in an interview.

The Interview
Deal with nervousness

My friends seem to vary wildly on how nervous they get for an interview. Some freak out, some don't seem phased at all. I'm certainly closer the freak out side, so I have extensive experience in dealing with nerves.

The first thing you need to do is understand that even if the interview goes terribly, you will still be proud of yourself for trying. It's like getting rejected by your crush. Hey, at least you tried. You can't get an internship if you don't interview, so overcoming your nerves and going through with it is doing yourself a huge favor.

My second piece of advice is go into it with zero expectations. When I was younger I used to try and prepare for every possible outcome of a stressful situation so I could be prepared for anything. This is bad. Don't plan what you're going to say or how you're going to act. This will make it incredibly hard to act naturally and 'lose yourself' in the moment. Just be yourself. You're great!

Something that helped me immensely is to try and connect with your interviewer on a casual level before the technical portion begins. They're people too, and usually incredibly kind and fun to talk to. Spend the first few minutes making small talk if you can (some interviewers jump right into it, so don't force it). It'll help you be more comfortable with your interviewer and the process will seem less daunting. This also has the added benefit of giving you insight into the company's culture, and can entirely change how you perceive a them. Do you really want to spend your internship working with people who aren't friendly?

Above all else, the nervousness will diminish with experience. It's like taking an exam in college. The first time is mortifying, but loses virtually all stress over time.

Think out loud

When you're asked a do-you-know kind of question, it's almost guaranteed that you won't know how to do it immediately. Don't panic. The point is to see how you think through the problem. Keep your interviewer informed with what you're doing. Saying things like "my first thought is this...", "I'm not sure if this will work out, but I'm going to try this...", or "I don't see a solution right now, but I'm going to work through this example to figuring something out..." are a fantastic way to do this. At the very least, your interviewer can't help you if they don't know what you're doing!

I should say that there is a fine line here. Don't babble and talk for the sake of talking. Long periods of silence are absolutely fine. Do what you need to do to think clearly and figure it out.

Don't panic

I can't tell you how many times I've heard "I thought I did terribly, but I got the offer!". It's really easy to walk away from an interview thinking you failed if you didn't answer everything. This is totally false. If the question is hard, then the chances are most other people didn't it either. The point is to see how far you got, or what your process was before you got stuck. A hint isn't the end of the world. If you can't figure something out, don't worry. Just stay calm and tell your interviewer that you're stuck. They'll want to help and will usually guide you in the right direction.

You're being evaluated relative to everyone else, so think of it like a curved test. A 60% may still be an A+.

Ask questions

Once the technical portion is over, you'll usually have the opportunity to ask the interviewer anything you want. I usually have a few questions I ask every company ("what is the coolest thing you've worked on?", "what's something an intern has made that is still being used today?"), and then a few specific to that company. This is your opportunity to interview them and get to know the company better. It may also help to assert your value. After all, you are incredibly desired in the industry and it's their job to convince you just as much as it is yours to convince them. However, make sure you're respectful. Adobe won't be impressed by you asking about their security leak.

---

At the end of the day remember to enjoy the experience. Even if you don't land an internship, which a lot of people don't, it's great experience for when you apply to a full-time position and will give you a huge edge over people who didn't try. I won't say that internships aren't important, but it isn't the end of the world if you don't get one.

Good luck and don't worry! After awhile you'll have interviews mastered and they'll simply be part of your daily routine.