My Summer Internship

Last summer, I researched cloud network security through an internship with the Information Trust Institute at the University of Illinois at Urbana-Champaign. It was the best summer I've ever had.

First, it was exhilarating and terrifying to move to a new city with only the things I could carry on a plane. I spent my first weekend in Urbana acquiring the things I needed to live: food, towels, toiletries, and a bicycle. Once I had settled in, I found Urbana-Champaign to be a wonderful place to live. When I spent time exploring the city, it rewarded with delicious restaurants, fascinating architecture, and stimulating culture. Exposure to Black Dog's barbeque pork sandwiches and brisket burnt ends and Murphy's Pub's hamburgers has destroyed my appetite for the substandard barbeque and burgers I've found here. Every day I wish I were back in Urbana.

Second, I enjoyed working on something substantial. My job was to research computer network security, devise a new network security system, build a prototype, and document the work. The research time gave me an excuse to learn how networks work. The planning stage introduced me to the process of brainstorming and planning with a team. In the prototyping phase, John and I managed to assemble a test network with 32 virtual machines, build two prototype security enforcers, and test our prototypes on the test network. To document our work, we created two posters and wrote a research paper which will be published by the International Workshop on Resilience Assessment of Complex Systems 2011. I'm proud of what I accomplished during the summer.

Third, I was honored and delighted to befriend my colleagues and fellow interns. It was a thrill to work closely with John, my partner on the project. We spent hours together slinging code, debugging the test bed, and writing posters and papers. I also enjoyed eating lunch with the other ITI interns Tuesdays and Thursdays at the internship seminars. On the weekends, my posse and I would meet to go bowling or eat dinner. We also had a few events at Europa House for all the summer iterns: a Walking Dead marathon, movie nights, and potlucks. The things I miss most about last summer are the friends I made. However, I expect to meet them again in the coming years on the cutting edge of industry and computer science research.

In summary, my summer internship at UIUC allowed me to live in a new city, research cutting-edge technology, and make new friends. Next summer will be even better.

My epic internship quest

Here's the story of how I spent four months of my life locating and applying for internships.

My initial plan was simple. Spend the summer doing a research internship at a major CS university to simulate pursuing a postgraduate degree. I had been receiving contradictory advice on whether I should attend grad school or go straight to work once I finish my Bachelor's degree. I thought I would settle the issue by experiencing research first-hand.

I applied to two REU programs: the Information Trust Institute at the University of Illinois at Urbana-Champaign and the Summer Undergraduate Program in Engineering Research at Berkeley – Information Technology for Sustainability at the University of California Berkeley. I sent seven inquiries by email to professors from both programs, receiving two positive responses. I spoke with Dr. Roy Campbell, a researcher at UIUC, and Leo Meyerovich, a grad student working with Dr. Ras Bodik at UC Berkeley. I submitted my applications successfully around the middle of February, although my UC Berkeley application was a day late.

During the application period, I stumbled upon another internship opportunity I couldn't ignore. Fog Creek Software in New York, NY was looking for a summer intern to help them build tools for programmers. The idea of working in New York under the venerable Joel Spolsky was irresistible. I didn't think I had a chance, so I drafted an email of application and sent it within two days. I didn't want to waste too much time on a fantasy.

When Fog Creek contacted me to set up a phone interview, I was both surprised and elated. I solved a few programming challenges from Project Euler to prepare for the programming examination, and I tried to anticipate the interview questions. Unfortunately, I forgot about most important question, "What programming projects have you done recently?" When the interviewer asked that question, my confidence was shattered, and I slipped into panic mode. During my programming test, I forgot how to use static variables, writing some terrible C. However, I spent my next class mentally debugging it, and I rewrote, tested, and resubmitted a not obviously broken version with a brief explanation later that evening.

At the end of the interview, I was told that I would be told whether I got the job within a couple days. I didn't hear back for about a week. At the time, I thought that meant that everybody at Fog Creek was too busy to bother sending me a rejection email, but in retrospect, I was probably a finalist who wasn't ruled out until the end.

Around this time I realized that what I wanted was an industry internship, so I refocused my efforts on finding an internship with a big tech company. I started gathering links and working on my resume.

Early in March, I heard about the Cascadia Fellowship, a program that matched technical students with Seattle-based startups. I answered a couple questions and provided a statement of intent. The following week, I received a mass-mailed rejection, in error, and then a personalized request for my resume and couple programming puzzles. Everything was due the following day. However, before the deadline, they sent me another impersonal rejection email. I ignored it and submitted my code before the deadline (barely). When I hadn't heard from them for a week, I asked if the second rejection was sent in error. I never received a response.

It was late in March now, and I didn't have an offer. I had narrowed down my list of major tech companies offering summer internships to Facebook, Google, Microsoft, and IBM. I missed the unpublished deadline for the Facebook software engineering internship, so that left Google, Microsoft, and IBM. I wrote a spartan list of reasons for Google to hire me and submitted my application. I filled out Microsoft's on-rails application, and submitted that next. Finally, I answered IBM's primarily experience-related application and turned it in.

After all this, I had only to apply to one more program: the Google Summer of Code. GSoC was my ultimate fail safe. I was accepted last year, and I felt that I had the process figured out. Unfortunately, I didn't have much time left to apply; I hadn't even looked at the list of mentoring organizations when the student application period began. I had eleven days to find at least two interesting organizations, pick interesting summer projects, and submit a detailed proposal to each, plus another two weeks to convince the organizations that I could complete my chosen projects.

I chose two organizations: Learning Unlimited, producers of a sophisticated Django-based web app; and Sencha Labs, developers of the JavaScript InfoVis Toolkit. I thought that LU was a long shot, but I found the project more interesting than the JIT. I split my application time between designing a student registration system for LU and fixing bugs for JIT. I had some independent experience with JavaScript graphics, and the project I chose was well within my capability, but I got cocky. I didn't spent nearly enough time learning about the core library; I simply assumed I would get the project. I worked hard on the LU project because I wanted it more and it was far more demanding. In the end, I was rejected by both projects because I didn't focus on either one. If I had dedicated myself to either project, I would've gotten it.

After the GSoC application deadline but before the decision date, I received a surprising message from UIUC. Dr. Masooda Bashir informed me that two researchers were interested in working with me over the summer, Dr. Klara Nahrstedt and Dr. Roy Campbell. Dr. Nahrstedt asked me for my resume, but Dr. Campbell remained silent. I sent him an email asking what he would be working on over the summer, but I didn't receive a response.

At this point, I was frantic. I hadn't received a positive response from any of the companies I had applied to, and when I didn't receive a decision from Drs. Campbell and Nahrstedt, I assumed that I hadn't made it into the highly competitive ITI internship. I tried to start over, looking for less exclusive internships, because I didn't want to waste my summer taking classes.

It was the beginning of May now. I had almost given up, but I decided to ask Drs. Campbell and Nahrstedt for final decisions. When I asked them whether they were still interested in working with me, Dr. Nahrstedt told me that I hadn't made the cut, but Dr. Campbell responded with an enthusiastic "Yes!" It was almost too late to file the paperwork, but Dr. Bashir came through for me. I received the official offer letter May 4.

Now, I've spent half my summer working at the University of Illinois at Urbana-Champaign, and I couldn't be happier. You could say that all my hard work paid off, or you could say that I got lucky at the last second. Either way, I'm just happy that I won't have to submit any more applications until the fall.

Lessons from gonzo programming

I recently experienced writing code under a looming deadline for the first time. After applying for the Cascadia Innovation Fellowship, I received a request for my résumé and two code samples due the following day.

The request described two pieces of code and asked me to implement them. I started immediately, dispatching the first with little effort and working on the second for a couple hours in the evening. Then, I unwisely decided to stay up to finish my second sample. I “finished” the code, “tested” it, and, satisfied, went to bed.

The following day, I worked on my résumé for most of the day, looking at the code again late in the evening. A simple test revealed a fundamental flaw in my algorithm, and I stayed up until 2:30 AM rewriting the algorithm, submitting my code only 30 minutes before the deadline.

I feel pretty good about my final code, but I didn't enjoy staying up late and coding frantically.

I learned a few valuable lessons worth sharing:

• Test thoroughly. If you're not trying to break your code, you're not testing.
• Prioritize. My résumé contained virtually no information I hadn't already submitted through my original application, yet I spent precious hours polishing it obsessively. I knew that the quality of my code would be the most important factor in my application, but I left my coding until the last minute.
• Use the obvious solution first. When I first considered the second piece of code, I skipped over the obvious solution in favor of a “faster” and “more general” solution that didn't work. I made the classic mistake of trying to solve a recursive problem non-recursively without first implementing the intuitive solution.
• Use git. After identifying the fatal flaw in my original code, I attempted to solve it with a set of small changes throughout the program. After working on the algorithm for about an hour, I rediscovered the obvious solution which was based on my original code. Thanks to git, it was easy for me to stash my changes in a new branch and resume work on my original version.
• Don't use C++. Because the prompt implied that solutions should be written in Java, I started working in C++ and asked if that would be OK. Instead, I should have asked if I could use Python: both of the challenges would have been almost trivial in Python.
• Never be without Programming Pearls. I left my copy at my dorm when I went home for spring break, so I couldn't refer to it to help me solve the problem. From now on, it's not leaving my side.

Thoughtfully designed electric razor

When I plugged in my inexpensive electric razor to charge, I pleasantly surprised by this delightful animation. I deeply respect this level of attention to detail. Whoever created this animation has converted at least one Remington user into a loyal Remington customer.

Why I want to work at Fog Creek

I'm applying for a summer internship at Fog Creek Software, a well-respected software company in NYC. I'm going to be interviewed by one of their developers next Tuesday, so I've been trying to anticipate the questions I will be asked and give them some thought. Tonight, I asked myself a simple but important question: "Why do you want to work at Fog Creek?"

First, I thought I wanted the experience. An internship at a reputable software company would look great on my résumé. I briefly considered whether I was in it for the office. Then, I thought that I wanted to prove to the world that I could build software, not just make little toys and read big books. However, I quickly realized the true source of my motivation: I want to work at Fog Creek to prove to myself that I can build software.

Until now, my most substantial project has been my work on OpenInkpot last summer. Assembling a cross-toolchain is highly technical work, but it's not a creative act. I didn't design the structure of the toolchain; I just put the pieces together.

I've tried to prepare myself for a career as a software developer by reading books on software structure and construction, but I know that's not enough. I won't know that I'm ready until I've built something real.

To become a software developer, I must develop software.

I was dead wrong

More than a year ago, I posted Programming is more than pointers and recursion, arguing that CS students don't need to learn about pointers and recursion. I wrote it in response to The Perils of JavaSchools, a 2005 blog entry in the legendary programming blog Joel on Software. I realize now that I was dead wrong, and I've decided to explain why (not only because someone from Fog Creek Software will be evaluating my blog.)

My central argument was that since pointers and recursion aren't often used in the software development industry, they aren't necessary topics for CS curricula. I was high on Python and Design Patterns at the time and fervent in my belief that all problems could be solved with straightforward, readable code. What I failed to realize is that if you can't (not don't) understand pointers and recursion, you can't have a meaningful career in programming.

Understanding pointers means more than memorizing the illogical C pointer syntax. It's an understanding of the difference between reference and value, between creating lightweight pointers and copying massive objects. Any programming job that doesn't require you to think about whether a variable should be a pointer or a value probably doesn't provide any challenge or variety. It certainly wouldn't provide any job security or marketable skills. Pointers are fundamental to programming.

Likewise, recursion is more than replacing a function call with the function's body; it's an illustration of the encapsulation of functions. Recursion is a stepping stone to first-class functions and closures. These aren't academic knick knacks with no practical application; they are powerful features in many popular languages.

In summary, Spolsky was right and I was wrong. Pointers and recursion are powerful tools that belong in the belt of every software developer. If you can't learn them, stick to HTML and CSS.

Where I have been

I haven't written an entry on this blog for about a month and a half. I stopped posting because I was unsatisfied with the quality of my entries. In a word, they sucked.

I realized this after listening to 149 Surprising Ways to Turbocharge Your Blog With Credibility!, Merlin Mann's and John Gruber's talk at the SxSW Interactive conference. Their advice to aspiring writers is simple: write well about topics which interest you.

Before now, I was putting frequency before quality, partially due to a foolish commitment to write one blog post a week during this year. I was writing pointless updates because I didn't have the time to create anything meaningful. Now I know that was a mistake. I am not a blogger; I'm a college student who enjoys writing.

Of course, this isn't the end of Welcome to Obscurity; it's the end of the shallow updates that have composed most of this blog's content for the last year. I will be writing infrequent, in-depth, polished entries about things about which I care.

Other news

Although I haven't been updating this blog lately, I have been blogging elsewhere. I started Life at the U to share my college experience with my family. It's been a huge hit within my social circle, so I've been updating frequently, sometimes multiple times per day.