Picking Up Where I Left Off

I kind of abandoned this project. No, I did abandon this project. When I stopped writing, I had a lot going on in my life; it was the kind of stuff that I didn't think I could write about without affecting my professional relationships. So I just stopped writing.

I had a hard time continuing this blog because everything that I wanted to write about, I felt that I couldn't. It's hard to write about something that doesn't interest you, and that's why I had such a hard time coming back to work on this.

It's hard deciding what to make public, especially today when it's so easy to over share on social media. I ended up just choosing not to write anything. I guess that's the safer choice, but I can't improve as a writer by not writing.

As I've said before, it's hard to start. As it seems now though, continuing is also hard. Maybe it's just hard the whole way through, and that's life. I'm trying to get better at following through on this. Right now I've been forcing myself to come to my site everyday (if it's so hard for me to do it, I imagine it would be even harder for others). Once I make a habit out of it, it will be easier to keep on writing. As they say, don't break the chain.

I'm trying to get better at breaking tasks down into manageable pieces. I think the the goals I listed when I started this blog can be a bit overwhelming sometimes. Instead of writing 500 words in one sitting, it's less daunting to write 100 words every day. So far, I've been doing a good job coming back and doing that. Making this task part of my daily routine will ensure the growth of this blog.

Anyways, don't call it a comeback. I'm looking forward to documenting my life in the future. I have a lot on my plate right now, and I'm sure it will make a lot of great posts.

How to Get the Interview

I've been seeing a disturbing trend: many of my friends who I know are smart, talented people are failing to receive an interview with the companies they apply for. I have had (mostly) good luck with this and usually get an interview when I apply. However, early on in my career this was not always the case. It's hard to understand what recruiters look for when they decide whether to have someone in for an interview, but I can describe what it has been like from my side of the fence, and what has helped me the most in my job hunts.

Typically, the summer internship job hunt ends with the beginning of spring. It is very difficult to find a summer internship in spring; most people look in fall and winter. If you are still looking now, it is crunch time. You need to devote a significant portion of your time to the job hunt. With that said here are some tips that have helped me, ranked in their usefulness:

  1. Talk to someone directly
    Of the interviews I get, I'd estimate that ~80% or more came from direct interaction with a recruiter or employee at a career function. At my university, we have Tech Talks, where a company will come talk about the interesting technology work they are doing right now. I got my current job from speaking to one of the talk's speakers and giving them my resume. The Computer Science and Engineering Department's job fair at my university has also been a great resource for me to get an interview at a company. If you are in school, and not taking advantage of the career placement opportunities that your school offers, you are making a big mistake. Get out there and talk yourself up!

  2. Rely on your connections
    The job fair advice is probably more heavily weighted to those in school. The second best method for me to find a way into a company is to talk to the people around me. Asking my employed friends to pass my resume along has been a great way to get an interview. Also, asking my friends for the email addresses of the recruiters who contacted them has been a useful in establishing a direct link to someone at a company.

    Other than your friends, you can ask those in your community for help. When I was living in San Francisco, I was very involved in the Python community, and I would regularly go to meetups. The meetups were usually held at some hip startup's office, and I was able to speak to recruiters and employees of the company directly. Other Pythonistas were super friendly and were always willing be my in at their company too.

  3. Find a listing on a job board
    There are lots of online job boards that having postings for open positions. The narrower the scope of board, the more success I've had getting an interview. This one is tangentially related to my previous tip, as I've gotten a lot of interviews from the Hacker News community. The who is hiring posts on HN have been a great way for me to get a direct contact at a company, and reaching out to them via HN has been helpful in getting an interview.

Applying online has never been much help to me, so I can't recommend it. I've never had much success applying to a job through their online application, and as far as I'm concerned they're just black holes to throw your resume into.

If my recommendations did not help you get an interview, take a look at your resume and skill set. Does your resume clearly describe your skills? Do your skills match the needs of the job you are applying to? These tips listed here are just for getting your foot in the door at a company and getting an interview. Actually having the technical chops to land the job is left as an exercise for the reader.

The Hardest Part is Starting

I am having trouble right now finding a side-project to work on in my spare time. I often find that starting a project is the hardest part of it. This was a common problem for me especially when I was just getting started programming. I've often wanted to contribute to an open-source project, or start my own project, but the perceived high barrier of entry often prevented me from working on it. I've found the most important factor in my success in a project is whether or not I do the first step. For a programming project, it can be as simple as writing a single line of code.

When I used to start personal projects, I would often start by hemming and hawing over deciding the best platform and language to use, then looking at the relevant examples and working through them. This was such a time consuming process, and one that often included lots of second guessing, that by the time I felt I was ready to begin, I would have already lost the initial enthusiasm I felt for the project. I would give up, and conclude that the project was no longer interesting and not worth my time.

The projects where I have learned the most have been the ones where I did as little preparation as possible, and just started writing code. Often times, I would write my self into a corner, but it was a worthwhile time sacrifice because I would have gained first hand experience with the project and the technology I was planning on using. Additionally, if there were technical limitations to my platform choice, I would be able to switch after gaining experience with the project at hand. This experience falls in line with Fred Brooks' software engineering advice from his fantastic book, The Mythical Man-Month. In the book while discussing building software, Fred writes, "plan to throw one away; you will, anyhow". I have used a variation on this when working on my projects: Write one to throw away.

Knowing that you can throw your code away let's you experiment more, move faster, and learn more. It let's me ignore focusing on coding style and efficiency and instead allows me to focus on learning. After I feel like I have either learned enough to start the real project, or I have completed a minimum viable example, I can get to work on the real thing. It will also take me less time to complete the project, because I will have a clearer understanding of where I am headed. There is a danger though of growing too attached to the "rough draft code". If you follow this strategy, you must be prepared to throw away the first attempt so that you don't use a poor implementation with bad style. Hackathons have been a great place for me to learn using this technique, as it allows me to learn a language or platform quickly, and then throw it away at the end of the event.

As I look for my next side project, I need to commit to diving into the code. As long as the project is started, and something is learned, I view it as a worthwhile endeavor.