Preparation

I have never prepared less for a trip in my life. We all had finals before we left for Tokyo, and thus were focused on gulping down caffeine to study instead of planning our awesome trip. Literally the only thing we did in preparation was book a place to stay the night before we left. It was a running joke up until we took off to Japan when we realized none of us had any clue what we were doing and none of us spoke Japanese.

Initial arrival

As mentioned before, we knew nothing about Tokyo and then were forced to face the consequences upon arrival. Immediately after landing (in Narita airport) we had to figure out how to get to Tokyo. Unsurprisingly, we were stumped at the ticket machine. Luckily for us, a Japanese businessman decided to help three bumbling americans. He showed us which tickets to buy, and then, since he was going the same direction, rode with us back to our train stop.

At the train stop, he suggested we grab dinner together. Who were we to refuse such an offer? So our now good friend Abe (pronounced Ah-bay), took us to our hostel, waited for us to change, and then took us all to a nice japanese restaurant with his girlfriend. Abe began to tell us about all sorts of japanese culture. One of which is drinking. Abe ordered everyone many rounds of beer, of which his girlfriend immediately pounded. I’ve never seen 90 pound japanese woman drink so much so fast. Props.

Abe told us about his company and how many japanese have to trade off between being a family man and a career man. He was of the career type. There is unusual amounts of stress in Japan. So much so that his company averages 3-5 suicides a year! Also in Japan, there isn’t a way to fire a person (at least at his company), so the company will stop giving him work until he quits. This came as a surprise to us considering that if the same were done to us in America, we believe that we’d be ecstatic to receive no work yet still get paid. I think this probably has to do with the deeply rooted sense of honor in Japan, something that doesn’t quite exist in America. At midnight we finished dinner and Abe amazingly picked up the tab for three american strangers.

We were all incredibly thankful for his help and thanked our lucky stars that we had run into Abe. It seemed like something that would likely never happen again. Yet, the japanese surprised us again. Charlie, the 4th member of our group, came late to Tokyo due to exams. We had no cell communication with Charlie, no email, no nothing. The only thing Charlie knew was some outdated plan that would no longer work and the name of the hostel we were staying at.

I was honestly not expecting to see Charlie until our flight home. In my mind, there was no way Charlie would be able to figure out the train system, realize the plan he knew was no longer the plan and find his way through the winding streets to our hostel. Amazingly, Charlie ran into another friendly japanese businessman. The man travelled with Charlie to Tokyo and then rode with him in a cab to our hostel. What’s more, he paid for the cab.

If it weren’t for these encounters, I’m quite sure we would’ve been living on the streets of Tokyo for nine days. And it would have been lonely too; there were very few homeless people as far as we could tell.

Living situation

One of the most interesting parts of Japan is the concept of capsules. Capsules are pod-like structures that you scoot into and sleep. They’re especially common among the cheap places to live (which is why we lived in them). They’re actually surprisingly cozy and private. We all slept extremely well.

Except for one night. Charlie and I were on a floor together sleeping in our capsules peacefully. When at 3am we were awoken by blood curdling screams. The stuff that gives you goosebumps. I’ve never heard a scream like that in my life and I hope to never hear one again; it is truly terrifying. Then we began to hear things being thrown around in addition to the screaming. There were about ten capsules on the floor. I was trying with all my might to try and figure out if he was right outside my capsule. No one dared to make a move, yet I’m positive everyone heard him. Amped up adrenaline I moved my myself into the most strategic defense position I could think of. I was basically ready to donkey kick anyone that opened my curtain. All of sudden, I heard a second voice, telling him to calm down. Then the screaming and throwing stopped, and he started stammering in a broken voice “I’m so sorry. I’m so sorry.” I was too scared to go outside and look what happened so I have no idea what went on that night, but I would guess it had to with nightmares or stress. Made for quite a night!

Beyond the sleeping situation, the bathing consisted of sitting on a small stool and using a handheld shower head to wash yourself. There was definitely some sort of specific routine you were supposed to go through, but none of us could figure it out. The stool idea was a great one though, sitting in a shower makes so much more sense.

Trip highlights

We visited a ton of places in Tokyo. Here are a few of my favorite.

Akihabara

Akihabara is called the “Electric City” and for good reason. This district is filled with lots of random electronics, most of which seem like they have no use. The streets are packed and there are tons of brightly lit buildings – almost enough to cause a small seizure. Within the alleys of electronics and lights, you can find yourself plenty of anime porn. This seems to be really big in Tokyo. Giant posters of half-naked cartoons are everywhere. Girls even dress like anime characters. The posters of women are photoshopped to make them look like children with big eyes which is supposed to make them look like anime.

Akihabara

Ueno Park

Ueno park is absolutely beautiful. The park is filled with Sakura trees otherwise known as cherry blossom trees. We were very lucky to see the trees in bloom (they only bloom for two weeks out of the year). During this time of year people come to the park to drink and soak in the beauty. There’s also a zoo right next to the park which features a giant panda that eats bamboo all day long. Literally all day long.

Ueno park. The lady tried to cut Calvin’s grumpy face out but to no avail. Sakura trees are in the background.

Asakusa

If you want your dose of old Japan, this is the place. It has multiple shrines and temples. The place is usually packed. The streets are filled with stores where you can buy “traditional” japanese gifts (made in China). There are also tons of street vendors selling delicious foods — many of which are bean based.

The streets of Asakusa

Shibuya Crossing

Great place to chill out and watch hundreds of people cross the street. After walking around for hours during the day, we found Shibuya crossing to be an excellent spot for recuperation and caffeine drinking. It’s actually pretty incredible how many people cross the street at this intersection.

Shibuya crossing

Random cultural observations

I’m by no means a japanese culture expert, and these are just based on my impressions.

Generosity/Politeness

This was shown when we first arrived by the businessmen. Beyond that though, it was the norm for us to ask for directions and then have the person actually stop what they were doing and walk us to our destination. They were also extremely understanding when it came to trains. If we bought the wrong ticket (happened often), the staff were more than happy to refund our ticket.

Non-confrontational

This probably stems from politeness, but, as foreigners, we could get away with anything. There were a few times we walked right through the gates to get to the train without a ticket, having the beeper sound, and no one would say anything.

Work hard play hard

Tokyo seemed to take this to an extreme. These guys really know how to drink. Any day of the week you can see businessmen packed into bars. Then they’ll go to work the next day for 18 hours.

Small portion sizes

With the exception of a few places, most restaurants served us extremely small portions (in comparison to the US). As four college-aged men, we spent most of our time hungry and looking for more food.

Fashion

I thought Tokyo was extremely fashionable. No one wore sweat pants and the women always dressed up in extraordinarily high heels. Lots of the women were really into pocket mirrors. The men would either wear suits or something very chic. We were definitely underdressed.

Cleanliness

Tokyo is very very clean. Especially inside many of the stores. In fact, the floors were so clean, that I felt like my reflection was making them dirtier. In the same vein, Tokyo has the nicest toilets ever. On multiple occasions I used heated toilet seats with multiple pressure bidet settings. One even had a blow drier for your butt after the bidet. The bidet had sniper like accuracy. Not sure how they always found my butt, but it never ever missed.

—

Go to Tokyo! It’s awesome.

First you need to install CouchDB, which is pretty straightforward. Just download the binary for windows here, or if you’re on a mac use this guide. Now run:

sudo -i -u root couchdb -b

Or for windows go to the CouchDB/bin folder and run couchdb.bat

And you should see a welcoming message telling you that it’s time to relax (it’s not time to relax yet). Once you get CouchDB setup, you’ll need a CORS proxy to allow access to your CouchDB database from a different domain. The easiest and simplest one I found is a node package called corsproxy. Simply run:

npm install -g corsproxy

And now you have your corsproxy. Run it by typing corsproxy. Alright, you have all the necessary requirements for setting up PouchDB and CouchDB replication. Normally in your javascript file you’d replicate like this:

Pouch.replicate('idb://myapp', 'http://localhost:5984/myapp', myCallback)

Where 'idb://myapp' is your local database and 'http://localhost:5984' is your CouchDB database. However since your app is being hosted on a different port you will get a Access-control-allow-origin error. Change that remote database to now point to the corsproxy you setup which has a default port of 9292:

Pouch.replicate('idb://myapp', 'http://localhost:9292/localhost:5984/myapp', myCallback)

Kazam! There you go, replicating PouchDB to/from a remote CouchDB! Now it’s time to relax.

Know what you’re doing

This sounds simple, yet this seems to be the most common cause of death for my software creations. My old thought process would be to think of some cool idea, say gesture recognizing glasses. Then, immediately start coding and realize later that there is no way I’d be able to finish such a project. I don’t have a small video camera to sit atop my glasses, nor do I have a super powerful microcontroller to process real-time video. Granted, these things can be bought, but it sure takes the wind out of those sails.

In order to actually figure out what I’m doing, I like to take an idea I have and flesh out some of its parts. Usually this involves pencil and paper and drawing what the application will do or how it will function. Sometimes I’ll go so far as to write a small design document briefly describing the technologies I’ll use and what I think the toughest parts will be. Any system will do, just find something that works for you so that you have a big picture of how your project will turn out.

Rewards

Building out a complete project often has loads of fun and interesting aspects, but there are always, always the dreaded parts that are necessary to finish the application (usually those darn tests). To knock out these more painful steps, I setup a reward system for myself. If I finish something mundane like error handling (my software doesn’t have bugs, right?), then I’ll reward myself with something cool like animating a graph. Or if there just isn’t anything fun left to do, I’ll eat my feelings and pull out a bag of sugar coated almonds. Probably not the healthiest way to code.

Version control

Version control didn’t initially strike me as a tool to boost me to finish the line. Sure, it’ll save you in an event of crisis, and it definitely keeps the morale up when you go charging down the wrong path only to realize you have to undo your work. But there is something much more subtle about version control that enables me to finish projects, and that is the power of incremental steps. Breaking your project down into small commit-sized bites makes it easier to swallow a large task.

It’s also important to actually breakdown your commits into logical chunks of progress. For me at least, it never feels quite right when I write a commit message outlining 4-5 half finished features. I yearn for that good wholesome git commit where I’ve completed a solid feature like “Added search functionality to message model.” I mean, who doesn’t?

The List

This one is simple but effective. Every time I start a project now I always start a TODO list to keep track of things I need to finish in the near future. It’s enough to just put down four or five items that I’m working on currently; it doesn’t have to be an exhaustive list. The evolution of the TODO list is pretty interesting as well, as I watch the list of features that need to be completed be turned into a list of bugs I need to fix.

—

Alas, there is no end-all-be-all method to completing every project. Sometimes it just takes a little bit of focus and determination to get ‘er done. No doubt there will be a few stranded, empty repositories in that projects folder, but I’ve found that it’s much better to have a few completed projects than loads of broken applications.

What I made

London 2012

My very first visualization was a static one:

This visualization is a scatter plot of 2012 Olympic countries’ medal count vs their per capita income. The radius of the data points is proportionate to the number of people that country sent, and the pie chart is the break down of gold, silver and bronze medals.

This project was a hack. I had no idea how to use D3 and was just aiming to get something to work. Those pie charts are all carefully crafted path elements. This sort of thing is made easy by the D3 library and you should never ever see “M” “L” or “Z” in your D3 code when creating paths. I didn’t take advantage of D3′s capabilities and ended up creating long, hard-to-read path declarations. Here’s a snippet taken directly from my javascript file that should never be used:

 path = "M" + startPoint.x + " " + startPoint.y +
        " L" + (startPoint.x + radius) + " " + (startPoint.y) +
        " A" + radius + " " + radius + " 0 " + longArc + " 0 " + 
             endX + " " + endY +
        " Z"

In addition, you can even see on the yaxis that the label is vertical text facing the wrong direction. I was a sad man and couldn’t rotate the text the other way without it ending up somewhere way off the page. This poor fellow ran into my same problem, but had the sense to ask on stackoverflow.

Refugee Flows

For my next project, I decided to try making an interactive map. I found a bunch of data on this UN site about where refugees originate from and where they are seeking asylum. This seemed to be screaming for some sort of map visualization. So I made this:

http://refugeeflows.herokuapp.com/

This was a great exercise for my first interactive visualization. D3 makes it extremely easy to do mapping. All in all, the project took around 10 hours to complete and I learned loads more about SVG.

Student Surveys

I made this one with a partner. We chose to visualize a huge chunk of student survey data. The students were in 8th grade when the survey started and there was a second round conducted when the students were in 10th grade. Our main purpose for this visualization was to tell a story. We ended up deciding that parallel coordinates was the best way to communicate the information we found most intriguing.

http://studentsurveys.herokuapp.com/

Our visualization was built on top of one of parellel coordinate examples in the D3 gallery. This was great because we got to really understand a well made D3 example and then extend it to fit our needs. It also introduced me to brushing and linking, which is a great tool for visualizing huge datasets.

African refugee populations

After digging deeper into the UNHCR (United Nations High Commissioner for Refugees) database, I found even more interesting data albeit in a worse format. I found Data Wrangler an invaluable tool when formatting the data.

http://africanrefugees.herokuapp.com/

This particular visualization required loads of brushing and linking which was a lot of fun to do in D3. I used a very “object oriented” javascript approach with a world object that linked all of my separate visualizations with each other. I also got to play with the GoogleMaps API for the first time. This vis taught me just how hard it is to keep all the graphics within a page and make it still look clean.

Diabetes Visualization

For my final visualization, I worked with a partner again to visualize 4 years worth blood glucose levels, sampled every 5 minutes, from an actual diabetic patient. We worked closely with a clinician and a father of a diabetic patient to construct a useful representation of the data.

http://diabetesvis.herokuapp.com/

Once again, brushing and linking was essential for this visualization. By now, Reno, my partner, and I had become fluent enough in D3 to code most of what we envisioned; the hardest part of this project was making it responsive. We had almost 300,000 data points yet we needed our application to be snappy. Since our dataset wasn’t changing, we took advantage using lots of indexes on the database. Also during this endeavor, we learned how painful it is to work with dates. To mitigate some of the nastiness, we found a nice date library for rails called by_star. Also essential was this blog post about converting javascript dates to ruby dates. By the end of this project we were ready to start a petition to remove time zones from the world.

Then, if I succeed in wooing my interviewer, I’ll get invited to an onsite interview, usually for a grueling 4-5 hours in San Francisco. Plus the Caltrain trip, which costs something like $14 round trip now, and that’s two chipotle burritos with chips! Once I’m there, I’ll get drilled again and again on all sorts of trick problems. Sometimes a product guy will come in and we’ll talk about where the company is headed and all that stuff. At the end of the day, I’ll go home and either get a job offer or never hear back. And that’s that. I’ve only been in one or two interviews where it varied significantly from this format.

I can’t help but think that this is a really backwards approach to recruiting ideal employees and is only useful at recruiting pure coding talent. I’m onboard with the phone interview process. Sure, you have to check to make sure this person can write code (maybe just look at his or her github/previous work?). However, these onsite interviews baffle me. Coding on a whiteboard while someone is breathing down your neck? This is the far from real coding. Maybe you’ll find a candidate who is good under pressure and can breeze through the implementation of a new kind of hash map that no one has heard of. Different people code in different ways. Most people use Google, references and other resources to figure out coding problems. Most people also test their code by actually running it on the computer. So what does coding on a whiteboard do? One could argue it “shows” the interviewer how the interviewee thinks. Honestly, I never feel the same when coding on a whiteboard and I’ve only gotten better at it because I’ve done so many interviews.

All that being said, interviewing and finding the right candidate is extraordinarily hard to do in four hours. The current process is definitely an imperfect solution, but it does have its merits. If a candidate zips through the whiteboard challenges, then yeah, he might be a good coder.

Ultimately though, I wholeheartedly believe companies are focusing on the wrong  aspects. Things to be sought after are character and communication skills. I’d argue they’re far more important than some coding chops or a pretty looking degree. Coding, data structures and algorithms can, for the most part, be taught. Character on the other hand, well, I don’t believe Coursera offers a 10 week course on that.

So why character? This has always seemed like a no-brainer question to me. Throughout my career as a gymnast, I’ve watched the most talented gymnasts fall from grace because they no longer put in the effort at the gym. Without hesitation, I would take a hardworking gymnast on my team over the slacker but extremely talented gymnast; I would hope most people would. Perhaps gymnastics is a bit different from software engineering, but I don’t think it’s too much of a stretch. Talented coders are a dime a dozen; it’s the intangibles like work ethic, even-temperedness and perseverance that transform a talented (or not so talented) coder into an ideal software engineer. Yet, companies that offer me jobs or reject me know very little about my character — who I am and what I value. At  my previous internship at Ooyala, the CEO would talk about keeping the ego to smartness ratio in check, and he’s damn right. A few big egos can literally ruin a team, no matter if they can code Kruskal’s algorithm iteratively blindfolded on the whiteboard. But no one checks for big egos in an interview.

Lastly, communication — the jelly in the peanut butter sandwich that makes it possible to swallow. As much as us software engineers have tried to hide ourselves from the world of communication by waddling around knee deep in python code, there is no escaping it. Working at a company means working with a team. Even if Google snags the mutant who can devote all 100% of his brain to coding, if he cannot explain what he has done, how to use it or how it works, then I’d argue he’s of no value. Imagine having that brilliant engineer write some brilliant piece of code. Then he leaves to start a start-up. If no one knows what he has done and there happens to be a bug, well, I guess you’re up a creek without a paddle! Communication is indirectly tested for in interviews by having the interviewee explain his or her solution, but often times the code speaks for itself and interviewers are just making sure that his or her communication skills aren’t really  bad.

Finding character and communication skills are not easy tasks and nothing can be assured of in a four hour interview, but I propose talking to the candidate, you know, like an actual conversation — figure out who he or she is, what lights his or her fire. Talk about things besides what he or she has coded in the past or will code in the future. I’m not saying drop all technical questions (I enjoy the challenge), but spending maybe one of those hours just getting to know the person you’re interviewing might be beneficial.

This piece of overused advice is misleading for a large portion of society. Granted I don’t have the wisdom or experience of the older folk who have been part of the game for a much longer time, so perhaps my views will change as I mature into a respectable member of the work force.

Constantly doing what you love, kills what you love

As a simple example, take a song that you love (You make my dreams come true – Hall & Oates), now listen to it 100 times today, and the next day, and the next day, and so on. How long will you love this song for? What if you listened to that song only once or twice a day?

While listening to music is not exactly analogous to work, the concept is the same. Turning your most enjoyable hobby into work is a sure-fire way to banish all the love you ever had for that hobby. This has happened countless times in my life: go full bore into some new technology, do it non-stop, and 6 months later I find myself burnt out.

Save what you really love for extracurriculars. You know, those projects you can’t stop thinking about during the day; the ones that stop you from sleeping at night. A little moderation will keep the fire burning inside and make those moments when working on that which you love even more special.

Reality

While I’m a strong believer in the fact that if anyone practices something long enough they can become skilled enough to make a living off of it, that kind of practice takes a long time. I’m just now starting to realize that I probably can’t go travel after school or go slacklining in crazy corners of the world. Why? Simply because I don’t have the money. I’m going to have to work first in order to make that money, and it might be work that I don’t absolutely love.

If not pursue love, then pursue what?

This is a question that has haunted me again and again. After much pondering, I believe there are 3 requirements that can give me a rewarding and happy career.

• Do something that’s meaningful to you
• Don’t do something you hate
• Make enough money to pay the bills

Meaning – Doing something meaningful is sustainable. If I believe I’m making a real change or truly believe in the cause of my work, I hope that that will lead to a rewarding career. In ten years, I want to proud of what I’ve done for society. I want to be able to talk about my work with passion and explain to people how I helped make a difference.

Hate - It’s all for naught if you hate your job. I could be saving the world’s poor or teaching the world’s young, but if I despise waking up every morning, then I surely will not have a rewarding career.

Money - Unfortunately, money does play a part. Plenty of studies have shown that happiness is increased when you can at least pay your bills. The amount of money you need varies from person to person, but as much as graduation speakers hate to admit it, your job needs to satisfy your basic needs.

—

While finding a job that you don’t hate, that has meaning, and that pays you is not an easy task, it’s a much more sane and grounded one than aimlessly pursuing a job you absolutely love regardless of the consequences. However, if you’re lucky, you might get it all, someone must’ve done it.

Just as writing allowed me to engage the world at a new level, so has taking photographs. I fell in love with Humans of New York, where Brandon, a solo photographer, goes around New York, interacts with interesting people he sees, and then photographs them. While he is a professional grade photographer, I thought I could do the same. So I made a Humans of Stanford facebook page, gathered my courage and went out to talk to strangers. The results were remarkable. By no means were any of my pictures amazing, but the interactions I had were. I met a man who told me about how he was going to change the world and about his philosophy of “Human’s Best” (can’t say understand it fully though). I found two engineers exploring a playstation controller by destroying it. I learned about and practiced the art of Falun Dafa.

Photographing people makes you seek out other people. It makes you search for an interesting person to talk to. It makes you walk with your eyes open. There are so many times when I would walk from point A to point B barely keeping note of my surroundings. However, with a camera always at hand, I’m always scanning around looking for people wearing weird hats or building the next electric car. So yes, writing made me think about and question the world, but taking photos let me interact with it.

Ctrl-P (Vim)

Before Ctrl-P entered my life, I was a sad man who used :e in Vim. Ctrl-P binds, well, “Ctrl-P” in Vim to a fuzzy file search mode (shown below).

Ctrl-P fuzzy file search

This makes finding files SO much easier. No more trying to remember where everything is located. You don’t even need to remember the whole file name just maybe 4 or 5 consecutive letters. This will most definitely keep a few extra buffers open during your work day.

Slate (Mac OSX)

I’ve been a Windows/Linux user my entire life and have even been a little against using Apple products. However, this summer I was forced to make the switch over to OS X and was pleasantly surprised by many of the features it had to offer. One feature I wasn’t satisfied with was its windowing system. To me, the windows look like someone took a stack of papers and slammed them down on a desk – splayed in disarray across the screen. One thing Windows got correct is their Aerosnap for windows and I missed it gravely. Slate erases all that and allows you to partition your windows easily with a press of a few buttons. Slate can also do a slew of other very useful things, including preset window configurations and window resizing.

Perfectly split windows

Vimium

Vimium simply allows you to use Vim shortcuts for Chrome. While the browser is designed for the mouse, Vimium does a pretty darn good job of making it easy to explore the web with the keyboard. You can cleverly search for words using the oh-so-common “/” command in Vim and then, if that word is part of a link, simply hit enter twice to follow that link. All the basic Vim commands are what you expect as well (gg – top of page, G – bottom of the page… etc)

Vimium

—

At the end of the day, productivity software actually makes a difference and is worth the time and research in order to make you a more effective coder. Do you have any life changing productivity applications? Let me know!

Jab… jab… jab… CROSS!

In boxing there are two key punches that all newbies learn. The jab and the cross. The jab is like your poking stick. You fire it out quickly to test the waters and then bring it back just as fast, if not faster. The cross is your nasty knuckle sandwich. You start with a pivot on your back foot and twist your whole body until you launch your dominant arm into a cross. It’s a bit slower, but way more powerful. You use your jab to make a hole in your opponent’s guard, and then, when the time is right, whip out the cross.

So how does this have anything to do with programming? Well, one of the first things I learned (from experience) about boxing is that you can’t release your cross right away unless you want to get walloped in the face.  Similarly, when working at a mid-size company like Ooyala, you don’t want to unleash your killer new feature in one big go, or be prepared to feel the pain that is angry users from the new bugs that will inevitably pop up. At Ooyala, they home brewed their own tool to release their feature incrementally so that not every user received the new changes. This was a pretty awesome idea that none of the previous companies I worked at did. This was incredibly handy when a large feature release (something they’ve been working on for over a year) was finally put into production. And, what do ya know, there were some pretty critical bugs. Not to fear though, the problem was isolated to only a few users and we were able to disable the new feature on those users until the fixes were made.

Hitting the button

Getting hit on the button is one of the worst things that can happen to you  as boxer. The button is what regular people call the chin. The reason it’s called the button is simple: when you get knocked in the chin it propagates to the back of your head and affects the nerves there, which in turn cause your legs to go limp (sorry for the hand wavy answer — this is what my coach told me and what I’ve verified through experience). This is why boxers fall down after getting knocked in the chin hard enough. Often, when I was first sparring (let’s be real it still happens) I would get hit on the button and feel a little dizzy, but my veins were so pumped with adrenaline I didn’t even stop to gather myself; I just went right back at it without stopping to think, only to get brained again. Usually my coach would come in and grab me and tell me to recoup and then go in and fix what I did wrong.

This exact feeling, perhaps to a lesser degree, was replicated during my time at Ooyala. It happened when I pushed some of my code to production, only semi-confident that it was perfected. Then when a bug report came back, I would scramble and try to figure out what I messed up. My heart would start pounding and the little voice in my head would shout at me “Oh god you dumb intern you’re going to screw everything up.” And sure enough, I could not find out what was wrong. It was then that I would realize that I had to take a breath, keep calm, look at the problem objectively, and then dig in with a clear mind — much more effective than method number one.

You gotta run the 700 miles, do the 1000 push-ups, and punch the 5000 punches before you can hope to box 

One thing that I really liked about my coach is that he didn’t just throw you into the ring and hope you made it out alive. He made sure you were ready, even if it meant doing the boring conditioning. Everyone just likes to box; it’s a thrill. However, you’ll get your bell rung if you’re not prepared for it.

Ooyala similarly took the time to do all the boring stuff (and that’s a good thing). Sure, there was plenty of crazy development going on, with 2 week sprints where you could code whatever you wanted, but there was also a focus on having a polished, crisp product. And that takes discipline. Ooyala taught me to make sure my strings were translated in all their supported locales, to make sure that not a single line went over 110 characters, to never forget my nil checks, and so much more that helped make their product a well-oiled machine.

—

You’ll learn a lot boxing, seriously.

Step 1: Email potential interviewee

Start out normal. Email the victim interviewee explaining how interested you are in finding out more about him – how you’d like to see if he or she would be a good match for the company.

Step 2: Ask for potential dates for phone interview or in-person interview

Keep the facade going, lure him in by seeming like you will actually schedule this interview. This is an important step, this gives the interviewee hope. That ‘hope’ has to be enough so that he will stick with you until the dirty end.

Step 3: Wait until after those dates have passed to respond

Perfect way to start the process. You’ve probably peeved him a little, but his emails are still full of niceties like “Thank you” and “Hello.”

Step 4: Repeat Steps 2 & 3 a sufficient number of times

Break his will by repeating steps 2 & 3. What’s a “sufficient” number of times? Some key indicators are: the failure to address you by your name at the beginning of the email, no more “Thank you”s, noticeable terseness in his responses.

Step 5: Give the wrong address to your interviewee

So you’ve finally worked out a date. He’s probably pretty relieved and he might even ask you where the office is. Nail him here by “accidentally” sending him the wrong address. He’s a busy guy so taking time to drive somewhere during the work day is most likely a hassle at the least. Even better, the interviewee is a student and doesn’t even have a car. Now that student has to pay an arm and a leg to get/borrow someone’s car. Score.

Step 6: Reschedule with correct address

You can lose him here, so your apology email must be sincere. Pretend like you’ve turned a new leaf. Reschedule the interview with new vigor and assure him that you’ve given him the correct address.

Step 7: The interview

Give the guy hope. Toy with his emotions as much as possible. Tell him how much you need his skills and how he would be a great addition to the team. Throw him softball questions that you know he’ll knock out of the park. Make sure the interview lasts a long time – you want to make sure you really wasted his day. Then end the interview with a firm handshake and say “We’ll get back to you soon.”

Step 8: Never Respond

This is key. Up to this point, it’s all tolerable – the interview process is usually not fun. Miscommunications happen all the time, your interviewee can look past this. Long interviews are fine when your interviewee sees the value in it and got a chance to meet some of your team. However, simply not responding after he comes in for an interview, after taking time out of his day, after sweating through all your interview questions is a small push that will make him never want to come back. Maybe it’s because it’s so easy to write a response or maybe it’s because an answer would put to rest his thoughts – whatever it is, this usually does the trick.