Application Review Process

Application Review Process

The application review process is essential for creating an enthusiastic and diverse cohort. The process should begin as soon as the application deadline has passed in order to release decisions by the end of June. The required materials needed to review applicants should include the Google Form application, as well as a spreadsheet that includes each applicant’s information, such as their name and Berkeley email. Additionally, the spreadsheet should have three columns for each reviewer, which will hold the applicant's rating and notes/comments for their application. For the justification column, the main reason a score was selected should be written down while the notes column is optional and can be used to write anything that stuck out. Application reading will be done independently and the notes/comments will be discussed at meetings where decisions (accepted, waitlisted, rejected) are made for each applicant.

Team

The application team will be comprised of 4 to 5 reviewers who will contribute to an applicant’s final score and write notes. There will also be an additional 2 to 3 reviewers who will only write notes for applicants and attend meetings to help discuss decisions.

Rating Scale

Applicants are rated on a 1-5 scale, 1 being the worst and 5 being the best:

• 1 - Absolute no: “I will throw a fit if this person is accepted.”

• 2 - Unfavorable: “I don’t think this person is a great fit”

• 3 - Neutral: "Let’s take this person if we can’t find anyone else.”

• 4 - Favorable: “I think this person is a good fit”

• 5 - Absolute yes: “I will throw a fit if this person is not accepted.”

This scale is used to give harsh ratings meaning most ratings should be 3s, then 2s and 4s.

1 and 5 should be given when a reviewer REALLY believe an applicant should/should not be accepted and they will fight for/against them if the rest of team doesn’t agree.

Note: If an applicant does not qualify for CS KickStart (not female-identifying, transfer student, continuing student, etc.), a 0 will be entered for their rating since they will more than likely be rejected.

What to look for:

Our mission is to retain more female students in computer science. We usually choose mostly students who we think would benefit (stay in computer science versus not stay in computer science) after being in the program. We also choose a few (under 10) students as “role models”: Students who seem friendly and have a good amount of CS experience. These are often students who may have already worked in a startup, created an app, started or participated in some Girls in CS organization, done research, etc. Someone to inspire the other students. Below are a few points that make for good/not good candidates. Most are pretty instinctual (friendly/enthusiastic), but some are pretty unintuitive/specific points that have been picked up from directors who have reviewed applications in the past.

Qualities of a GOOD candidate

• Eager to be a part of a community of women (we want people who are excited about the friendships they might make rather than those who are only concerned about making networking connections.)

• Enthusiastic about learning CS, even though understanding may be limited. (Don’t down rate students who have a misunderstanding of CS, such as someone who thinks CS is learning how to fix when your computer freezes. That’s totally fine. We were all there at some point.) This often comes in the form of someone who doesn’t know anything about CS, but is confidently “tech savvy” (always checking out new apps, good at learning how to use new phone/laptop, etc.)

• Thinks CS might be cool, isn’t entirely sure what it is, wants to learn more about the field

• On the border of CS or another subject

• No programming experience

• Might not do as well without the support group CSK can provide (This can take many forms—Never having done CS, new and nervous to the area/college life, etc. )

• L&S student who might have trouble getting declared. A common example is someone with no programming knowledge and didn’t take AP Calc (look at the high school transcript), meaning she will potentially struggle with 61A and also need to take Math 1A/B and 54. Without guidance and support, these people often will give up.

• Will help develop a diverse cohort. (underrepresented minority/low-income/first-generation/out of state/etc.)

• Interested in something in CS other than just code. Not a big priority, but it would be cool to find some students who might be interested in EE, design, networks, theory, databases, artificial intelligence, etc., even if they don’t really fully understand what those fields are.

• Active in school clubs/supportive of women in tech. This isn’t a big priority, but we want to make sure some of them will stick around and be organizers during the school year.

• Role models are fairly easy to spot. They stand out and have done something impressive for a high school student. Mark potential role models in your notes. You’ll get a lot of in-between people who have more programming knowledge than most but you’re not sure if they’re role model level. Role models should probably be the 10 people who stick out in your mind after reading ALL applications.

• Use judge of character—Friendly person you would want to have attended CS KickStart with.

Qualities of a NOT SO GOOD candidate

• Will almost definitely do CS regardless of CSK participation meaning we should prioritize applicants with more GOOD qualities over them (Good CS background, but not yet at level of role model. This is often EECS students with good programming knowledge.)

• Will almost definitely NOT do CS regardless of CS KickStart (Yes, some students apply just to come one week early and have early move in, etc. Also, “do CS” means take a CS class or learn to code somehow—It’s okay if they plan to major in something else but are they showing a genuine interest in CS?)

• Applied for PREP or some other tech/engineering program that seems like a better fit for them.
• Answers don’t seem honest or direct (This is often people who filled their essays with so much fluff that they don’t answer the question. If their essay has nothing meaningful then we don’t know enough to accept them.)

• As of now we don’t accept transfer or continuing students.

• Didn’t put time into application (not serious about applying, misspelled words, one-word answers, etc. However, don’t mistake a short, direct response or a more informal response for a bad response.)

• Misunderstanding of CS KickStart. (Do they ONLY want to get ahead in CS and learn advanced CS concepts? Did they include a polished portfolio? Not a good fit.)

• Use judge of character. Do they seem unfriendly or did they make some offensive/arrogant comment? Probably not a good fit.

Transcript

Not only does requiring applicants to submit their high school transcripts add a sense of professionalism to the application process, but it also helps us gain a better understanding of their academic level and their potential benefit from CS KickStart. For instance, if a student intends to major in computer science but lacks advanced math experience on their transcript, it is reasonable to assume that they may struggle in courses like CS61A, Math 1A/1B/54, which means they could find CS KickStart valuable. We are not looking for straight As.

Applicant Decisions

Applicants who score 10 or below will likely be waitlisted or rejected, although this is subject to change and heavily relies on the discussions held during application review meetings. During these discussions, we will highlight applicants' names in green for accepted, yellow for waitlist, red for rejected, and orange for undecided. Undecided applicants are typically individuals who have the potential to be role models or those who fall in between two decisions. We will revisit the undecided applicants once all decisions have been made, taking into account our expected program capacity. Prior to sending decision emails, we will double-check that accepted and waitlisted applicants have submitted their Statement of Intent to Register (SIR) to Berkeley.