2016 - 2017

This document is a list of the various ways a company can sponsor an event at Berkeley EECS.

Numbers are estimates, and different fees can be negotiated.

About the CSUA

Thank you for considering partnering with the Computer Science Undergraduate Association (CSUA) at UC Berkeley. We are the largest club in the computer science department and have over 30 years of experience with planning events.

If you have any questions or would like to plan an event, please email [indrel@csua.berkeley.edu]{.underline}. We are also open to helping you craft a custom event not listed here. Thank you for your support!

1. CSUA Hackathon (Fall: November 4-5 2016, Spring: tbd)

This fun event is a time for students to hack together on projects, which they will present at the end of the event. As a sponsor, your company will send representatives who will judge hacks built by students and view talent at UC Berkeley. The CSUA will handle catering, advertising, flyers, room reservation, prizes, staffing, and ground logistics. This is a great time to find potential fits for your company! Typically around 150-300 people attend.

Sponsorship Levels:

  • Platinum: $6000 (7 reps, 5 or more judges, integrated full length tech talk, Gold benefits)

  • Gold: $4000 (7 judges/reps, 40 minute tech talk, Silver Benefits)

  • Silver: $2500 (4 reps/judges, 20 minute talk on company, ability to be named to choose and endow a prize, Bronze benefits)

  • Bronze: $1700 (3 reps, more prominent logo on website, 1 judge, Blue benefits)

  • Blue: $700 (1 rep, logo on flyer and website, swag distribution from company, company logo and summary posted on Hackathon website)

Details:

==Schedule==

5:00 PM 11/4: Tech Talk from Meraki

6:30 PM 11/4: Hacking starts

12:30 PM 11/5: Hacking ends

1:00 PM 11/5: Judging and presentations

3:00 PM 11/5: Prizes

4 meals will be served.

==Rules==

1) All code written must be written in the 18-hour period, or explicitly flagged as written beforehand.

2) Making significant use of pre-written non-framework/non-library code is strongly discouraged. Libraries are totally fine.

3) Anything reasonably called a "framework" should be fine.

Improvements to a library may not be considered in the main body of a work if they are merely incidental to the project, rather than a major component.

4) Preparation work, including non-coding design and/or product development is generally acceptable.

5) If a project does not pass a "smell test", judges may, at their discretion, take this factor into consideration when evaluating the project.

6) It is recommended that a README file be included which explains the necessary disclaimers for pre-work, libraries, etc., and summarizes the work done. However, this is neither required nor scored.