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:
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!
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.
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.
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.
This is the first sentence, of the first post, of my first blog. I've been meaning to start a blog for a while, as many people I look up to say blogging is worthwhile. I'm not totally sure yet of what I plan to write about, how often I will post, or what this blog will be for me. Right now I plan on using it as a platform to become a better writer in a public space.
The best way to get better at something is to do it often. As Eric Schmidt says, "Repetition doesn't spoil the prayer". I'll outline my writing goals here, so that I have something in public to compare myself to. I'll make my goals simple now, so that they are attainable. If they are attainable, then I hope to be able to stick to them and some day achieve fame and success.
- Publish something once a week.
- Write at least 500 words each week. It doesn't matter if I publish less.
- Come up with 3 ideas for topics each week for the following week's post. Having two to throw away (or save for later) will help my posts be interesting.
I've already linked to http://blog.codinghorror.com/ twice in my first post. If it's not obvious yet, Jeff Atwood is one of my programming heroes. His blog has really inspired me to become a better programmer and to take pride in software construction.
Blogging about blogging is a bit incestuous. I have some upcoming posts that will discuss this subject a little more. I don't want those posts to be vacuous, so I will have to do a lot of editing. I think that there are 3 keys to a successful blog:
Keys to a Successful Blog
- Have a voice. You need to have something to say to have something to write about.
- Edit ruthlessly. The content needs to be concise, well formatted, and grammatically correct so that it is easy to read. There is an analogy to be made here to the "Ruthless Testing" chapter of The Pragmatic Programmer, but I plan to explain that more in another post.
- Update regularly. If there are readers of a blog, new content must be published to keep them coming back. This step is also important for the author to grow as a writer.
The state of this blog is in flux for the time being. The style, content, and my commitment to it are not yet established. The style is easy to change, the content will come in time, but my willingness to work on this project can only come from me.