How Not To Apply For Summer Of Code

Posted on by

Here are some ways to make sure your Summer of Code application fails. All are inspired by actual applications to the Mozilla project this year.

Don’t:

  1. Fail to state your project idea. This may seem obvious, but if you don’t tell us what you want to do, we aren’t going to choose you to do it.
  2. Cut-and-paste your CV. If you say you have a Class Q driving licence, what it tells me is you haven’t really thought about the content of your application.
  3. Suggest hard work is a substitute for experience. If you are applying to do a complicated technical task, “I’ve got no experience of your codebase or project but I’ll work really hard” doesn’t cut much ice.
  4. Give us a vague timeline. Project plans like: “Week 1-2: Ramp up on code. Week 3-7: Implement project. Week 8-10: Testing and debugging” don’t inspire confidence.
  5. Use enthusiasm as a substitute for competence. “This feature would be really cool!” isn’t a good reason to choose you to implement it if you’ve never written a line of C++ in your life.
  6. Assume using the software means you can hack on it. “I use Firefox every day” is not going to make it more likely for us to choose you to improve its networking layer.
  7. Leave template residue in your application. We had a number of applications which ended “(Thanks to Fyodor from Nmap for his help in creating this template.)” This shouts “zero-effort application spam”.
  8. Put all your info in an external web page. Mentors are lazy. Anyway, if you need more than 7500 characters, you should probably trim your text.
  9. When asked about experience with a technology, put “Good”. ‘Nuff said.
  10. Tell us you are applying because you need the money. However true it is.

Having said all that, there were many good applications which we were unable to fund. Please don’t think that if you weren’t chosen, your application was therefore rubbish.

I’ll write a more constructive Summer-of-Code-related post soon.

6 thoughts on “How Not To Apply For Summer Of Code”

  1. > We had a number of applications which ended “(Thanks to
    > Fyodor from Nmap for his help in creating this template.)”

    Although I didn’t use the template provided by Google for my applicaion, some people might have felt that after using that template, that they were obliged to keep the credit too. That’s just some of the text which was presented to applicants when they are asked to write their proposal, it isn’t as if there is a site with SOC templates on it which people are spamming you with.

    Having said that, thanks for the feedback and I look forward to reading your next post!

    Douglas

  2. A more extreme variation of 7. we saw at OSAF a few times:

    7b. Submit only the project template without filling in anything.

    Also a new one:

    11. You have worked on a personal project for a few years and want us to mentor you and Google to give you money. The project is not open source. The project has no connection with any other open source (or proprietary) project.

    And finally a handful of people submitted their project to wrong organization. Hopefully these got resolved eventually.

  4. I wonder if #6 was caused by a part of the application template that asked if the applicant had any familiarity using the mentoring organization’s software. That question probably applied to some projects more than others: for the Wikimedia Foundation, depending on whether you worked on the frontend or backend, I’d guess that it was important whether you knew how to use the MediaWiki software, so that you’d know what to improve.

  5. Minh: Could be; I was more thinking of people who used usage as (yet another) substitute for experience.

  6. > Give us a vague timeline. Project plans like: “Week 1-2: Ramp up on code. Week 3-7: Implement project. Week 8-10: Testing and debugging” don’t inspire confidence.

    Not to mention displays an amazing lack of Programming 101. Debugging ALWAYS takes longer than implementing.