What are your chances of acceptance?
Calculate for all schools, your chance of acceptance.
Your chancing factors
Extracurriculars.
How to Write the “Why Computer Science?” Essay
What’s covered:, what is the purpose of the “why computer science” essay, elements of a good computer science essay, computer science essay example, where to get your essay edited.
You will encounter many essay prompts as you start applying to schools, but if you are intent on majoring in computer science or a related field, you will come across the “ Why Computer Science? ” essay archetype. It’s important that you know the importance behind this prompt and what constitutes a good response in order to make your essay stand out.
For more information on writing essays, check out CollegeVine’s extensive essay guides that include everything from general tips, to essay examples, to essay breakdowns that will help you write the essays for over 100 schools.
Colleges ask you to write a “ Why Computer Science? ” essay so you may communicate your passion for computer science, and demonstrate how it aligns with your personal and professional goals. Admissions committees want to see that you have a deep interest and commitment to the field, and that you have a vision for how a degree in computer science will propel your future aspirations.
The essay provides an opportunity to distinguish yourself from other applicants. It’s your chance to showcase your understanding of the discipline, your experiences that sparked or deepened your interest in the field, and your ambitions for future study and career. You can detail how a computer science degree will equip you with the skills and knowledge you need to make a meaningful contribution in this rapidly evolving field.
A well-crafted “ Why Computer Science? ” essay not only convinces the admissions committee of your enthusiasm and commitment to computer science, but also provides a glimpse of your ability to think critically, solve problems, and communicate effectively—essential skills for a computer scientist.
The essay also gives you an opportunity to demonstrate your understanding of the specific computer science program at the college or university you are applying to. You can discuss how the program’s resources, faculty, curriculum, and culture align with your academic interests and career goals. A strong “ Why Computer Science? ” essay shows that you have done your research, and that you are applying to the program not just because you want to study computer science, but because you believe that this particular program is the best fit for you.
Writing an effective “ Why Computer Science ?” essay often requires a blend of two popular college essay archetypes: “ Why This Major? ” and “ Why This College? “.
Explain “Why This Major?”
The “ Why This Major? ” essay is an opportunity for you to dig deep into your motivations and passions for studying Computer Science. It’s about sharing your ‘origin story’ of how your interest in Computer Science took root and blossomed. This part of your essay could recount an early experience with coding, a compelling Computer Science class you took, or a personal project that sparked your fascination.
What was the journey that led you to this major? Was it a particular incident, or did your interest evolve over time? Did you participate in related activities, like coding clubs, online courses, hackathons, or internships?
Importantly, this essay should also shed light on your future aspirations. How does your interest in Computer Science connect to your career goals? What kind of problems do you hope to solve with your degree?
The key for a strong “ Why This Major? ” essay is to make the reader understand your connection to the subject. This is done through explaining your fascination and love for computer science. What emotions do you feel when you are coding? How does it make you feel when you figure out the solution after hours of trying? What aspects of your personality shine when you are coding?
By addressing these questions, you can effectively demonstrate a deep, personal, and genuine connection with the major.
Emphasize “Why This College?”
The “ Why This College? ” component of the essay demonstrates your understanding of the specific university and its Computer Science program. This is where you show that you’ve done your homework about the college, and you know what resources it has to support your academic journey.
What unique opportunities does the university offer for Computer Science students? Are there particular courses, professors, research opportunities, or clubs that align with your interests? Perhaps there’s a study abroad program or an industry partnership that could give you a unique learning experience. Maybe the university has a particular teaching methodology that resonates with you.
Also, think about the larger university community. What aspects of the campus culture, community, location, or extracurricular opportunities enhance your interest in this college? Remember, this is not about general praises but about specific features that align with your goals. How will these resources and opportunities help you explore your interests further and achieve your career goals? How does the university’s vision and mission resonate with your own values and career aspirations?
It’s important when discussing the school’s resources that you always draw a connection between the opportunity and yourself. For example, don’t tell us you want to work with X professor because of their work pioneering regenerative AI. Go a step further and say because of your goal to develop AI surgeons for remote communities, learning how to strengthen AI feedback loops from X professor would bring you one step closer to achieving your dream.
By articulating your thoughts on these aspects, you demonstrate a strong alignment between the college and your academic goals, enhancing your appeal as a prospective student.
Demonstrate a Deep Understanding of Computer Science
As with a traditional “ Why This Major? ” essay, you must exhibit a deep and clear understanding of computer science. Discuss specific areas within the field that pique your interest and why. This could range from artificial intelligence to software development, or from data science to cybersecurity.
What’s important is to not just boast and say “ I have a strong grasp on cybersecurity ”, but instead use your knowledge to show your readers your passion: “ After being bombarded with cyber attack after cyber attack, I explained to my grandparents the concept of end-to-end encryption and how phishing was not the same as a peaceful afternoon on a lake. ”
Make it Fun!
Students make the mistake of thinking their college essays have to be serious and hyper-professional. While you don’t want to be throwing around slang and want to present yourself in a positive light, you shouldn’t feel like you’re not allowed to have fun with your essay. Let your personality shine and crack a few jokes.
You can, and should, also get creative with your essay. A great way to do this in a computer science essay is to incorporate lines of code or write the essay like you are writing out code.
Now we will go over a real “ Why Computer Science? ” essay a student submitted and explore what the essay did well, and where there is room for improvement.
Please note: Looking at examples of real essays students have submitted to colleges can be very beneficial to get inspiration for your essays. You should never copy or plagiarize from these examples when writing your own essays. Colleges can tell when an essay isn’t genuine and will not view students favorably if they plagiarized.
I held my breath and hit RUN. Yes! A plump white cat jumped out and began to catch the falling pizzas. Although my Fat Cat project seems simple now, it was the beginning of an enthusiastic passion for computer science. Four years and thousands of hours of programming later, that passion has grown into an intense desire to explore how computer science can serve society. Every day, surrounded by technology that can recognize my face and recommend scarily-specific ads, I’m reminded of Uncle Ben’s advice to a young Spiderman: “with great power comes great responsibility”. Likewise, the need to ensure digital equality has skyrocketed with AI’s far-reaching presence in society; and I believe that digital fairness starts with equality in education.
The unique use of threads at the College of Computing perfectly matches my interests in AI and its potential use in education; the path of combined threads on Intelligence and People gives me the rare opportunity to delve deep into both areas. I’m particularly intrigued by the rich sets of both knowledge-based and data-driven intelligence courses, as I believe AI should not only show correlation of events, but also provide insight for why they occur.
In my four years as an enthusiastic online English tutor, I’ve worked hard to help students overcome both financial and technological obstacles in hopes of bringing quality education to people from diverse backgrounds. For this reason, I’m extremely excited by the many courses in the People thread that focus on education and human-centered technology. I’d love to explore how to integrate AI technology into the teaching process to make education more available, affordable, and effective for people everywhere. And with the innumerable opportunities that Georgia Tech has to offer, I know that I will be able to go further here than anywhere else.
What the Essay Did Well
This essay perfectly accomplishes the two key parts of a “ Why Computer Science? ” essay: answering “ Why This Major? ” and “ Why This College? ”. Not to mention, we get a lot of insight into this student and what they care about beyond computer science, and a fun hook at the beginning.
Starting with the “ Why This Major? ” aspect of the response, this essay demonstrates what got the student into computer science, why they are passionate about the subject, and what their goals are. They show us their introduction to the world of CS with an engaging hook: “I held my breath and hit RUN. Yes! A plump white cat jumped out and began to catch the falling pizzas. ” We then see this is a core passion because they spent “ Four years and thousands of hours ,” coding.
The student shows us why they care about AI with the sentence, “ Every day, surrounded by technology that can recognize my face and recommend scarily-specific ads ,” which makes the topic personal by demonstrating their fear at AI’s capabilities. But, rather than let panic overwhelm them, the student calls upon Spiderman and tells us their goal of establishing digital equality through education. This provides a great basis for the rest of the essay, as it thoroughly explains the students motivations and goals, and demonstrates their appreciation for interdisciplinary topics.
Then, the essay shifts into answering “ Why This College? ”, which it does very well by honing in on a unique facet of Georgia Tech’s College of Computing: threads. This is a great example of how to provide depth to the school resources you mention. The student describes the two threads and not only why the combination is important to them, but how their previous experiences (i.e. online English tutor) correlate to the values of the thread: “ For this reason, I’m extremely excited by the many courses in the People thread that focus on education and human-centered technology. ”
What Could Be Improved
This essay does a good job covering the basics of the prompt, but it could be elevated with more nuance and detail. The biggest thing missing from this essay is a strong core to tie everything together. What do we mean by that? We want to see a common theme, anecdote, or motivation that is weaved throughout the entire essay to connect everything. Take the Spiderman quote for example. If this was expanded, it could have been the perfect core for this essay.
Underlying this student’s interest in AI is a passion for social justice, so they could have used the quote about power and responsibility to talk about existing injustices with AI and how once they have the power to create AI they will act responsibly and help affected communities. They are clearly passionate about equality of education, but there is a disconnect between education and AI that comes from a lack of detail. To strengthen the core of the essay, this student needs to include real-world examples of how AI is fostering inequities in education. This takes their essay from theoretical to practical.
Whether you’re a seasoned writer or a novice trying your hand at college application essays, the review and editing process is crucial. A fresh set of eyes can provide valuable insights into the clarity, coherence, and impact of your writing. Our free Peer Essay Review tool offers a unique platform to get your essay reviewed by another student. Peer reviews can often uncover gaps, provide new insights or enhance the clarity of your essay, making your arguments more compelling. The best part? You can return the favor by reviewing other students’ essays, which is a great way to hone your own writing and critical thinking skills.
For a more professional touch, consider getting your essay reviewed by a college admissions expert . CollegeVine advisors have years of experience helping students refine their writing and successfully apply to top-tier schools. They can provide specific advice on how to showcase your strengths, address any weaknesses, and generally present yourself in the best possible light.
Related CollegeVine Blog Posts
Essays on programming I think about a lot
Every so often I read an essay that I end up thinking about, and citing in conversation, over and over again.
Here’s my index of all the ones of those I can remember! I’ll try to keep it up to date as I think of more.
There's a lot in here! If you'd like, I can email you one essay per week, so you have more time to digest each one:
Nelson Elhage, Computers can be understood . The attitude embodied in this essay is one of the things that has made the biggest difference to my effectiveness as an engineer:
I approach software with a deep-seated belief that computers and software systems can be understood. … In some ways, this belief feels radical today. Modern software and hardware systems contain almost unimaginable complexity amongst many distinct layers, each building atop each other. … In the face of this complexity, it’s easy to assume that there’s just too much to learn, and to adopt the mental shorthand that the systems we work with are best treated as black boxes, not to be understood in any detail. I argue against that approach. You will never understand every detail of the implementation of every level on that stack; but you can understand all of them to some level of abstraction, and any specific layer to essentially any depth necessary for any purpose.
Dan McKinley, Choose Boring Technology . When people ask me how we make technical decisions at Wave, I send them this essay. It’s probably saved me more heartbreak and regret than any other:
Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps. If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.
Sandy Metz, The Wrong Abstraction . This essay convinced me that “don’t repeat yourself” (DRY) isn’t a good motto. It’s okay advice, but as Metz points out, if you don’t choose the right interface boundaries when DRYing up, the resulting abstraction can quickly become unmaintainable:
Time passes. A new requirement appears for which the current abstraction is almost perfect. Programmer B gets tasked to implement this requirement. Programmer B feels honor-bound to retain the existing abstraction, but since isn’t exactly the same for every case, they alter the code to take a parameter…. … Loop until code becomes incomprehensible. You appear in the story about here, and your life takes a dramatic turn for the worse.
Patrick McKenzie, Falsehoods Programmers Believe About Names . When programming, it’s helpful to think in terms of “invariants,” i.e., properties that we assume will always be true. I think of this essay as the ultimate reminder that reality has no invariants :
People’s names are assigned at birth. OK, maybe not at birth, but at least pretty close to birth. Alright, alright, within a year or so of birth. Five years? You’re kidding me, right?
Thomas Ptacek, The Hiring Post . This essay inspired me to put a lot of effort into Wave’s work-sample interview, and the payoff was huge—we hired a much stronger team, much more quickly, than I expected to be able to. It’s also a good reminder that most things that most people do make no sense:
Nothing in Alex’s background offered a hint that this would happen. He had Walter White’s resume, but Heisenberg’s aptitude. None of us saw it coming. My name is Thomas Ptacek and I endorse this terrible pun. Alex was the one who nonced. A few years ago, Matasano couldn’t have hired Alex, because we relied on interviews and resumes to hire. Then we made some changes, and became a machine that spotted and recruited people like Alex: line of business .NET developers at insurance companies who pulled Rails core CVEs out of their first hour looking at the code. Sysadmins who hardware-reversed assembly firmware for phone chipsets. Epiphany: the talent is out there, but you can’t find it on a resume. Our field selects engineers using a process that is worse than reading chicken entrails. Like interviews, poultry intestine has little to tell you about whether to hire someone. But they’re a more pleasant eating experience than a lunch interview.
Gergely Orosz, The Product-Minded Engineer . I send this essay to coworkers all the time—it describes extremely well what traits will help you succeed as an engineer at a startup:
Proactive with product ideas/opinions • Interest in the business, user behavior and data on this • Curiosity and a keen interest in “why?” • Strong communicators and great relationships with non-engineers • Offering product/engineering tradeoffs upfront • Pragmatic handling of edge cases • Quick product validation cycles • End-to-end product feature ownership • Strong product instincts through repeated cycles of learning
tef, Write code that is easy to delete, not easy to extend . The Wrong Abstraction argues that reusable code, unless carefully designed, becomes unmaintainable. tef takes the logical next step: design for disposability, not maintainability. This essay gave me lots of useful mental models for evaluating software designs.
If we see ‘lines of code’ as ‘lines spent’, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.
Business logic is code characterised by a never ending series of edge cases and quick and dirty hacks. This is fine. I am ok with this. Other styles like ‘game code’, or ‘founder code’ are the same thing: cutting corners to save a considerable amount of time. The reason? Sometimes it’s easier to delete one big mistake than try to delete 18 smaller interleaved mistakes. A lot of programming is exploratory, and it’s quicker to get it wrong a few times and iterate than think to get it right first time.
tef also wrote a follow-up, Repeat yourself, do more than one thing, and rewrite everything , that he thinks makes the same points more clearly—though I prefer the original because “easy to delete” is a unifying principle that made the essay hang together really well.
Joel Spolsky, The Law of Leaky Abstractions . Old, but still extremely influential—“where and how does this abstraction leak” is one of the main lenses I use to evaluate designs:
Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn’t, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can’t do anything about it and your message doesn’t arrive. If you were curt with the system administrators in your company and they punished you by plugging you into an overloaded hub, only some of your IP packets will get through, and TCP will work, but everything will be really slow. This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from. This is but one example of what I’ve dubbed the Law of Leaky Abstractions: All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions. Here are some examples.
Reflections on software performance by Nelson Elhage, the only author of two different essays in this list! Nelson’s ideas helped crystallize my philosophy of tool design, and contributed to my views on impatience .
It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower. What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task. Users almost always have multiple strategies available to pursue a goal — including deciding to work on something else entirely — and they will choose to use faster tools more and more frequently. Fast tools don’t just allow users to accomplish tasks faster; they allow users to accomplish entirely new types of tasks, in entirely new ways. I’ve seen this phenomenon clearly while working on both Sorbet and Livegrep…
Brandur Leach’s series on using databases to ensure correct edge-case behavior: Building Robust Systems with ACID and Constraints , Using Atomic Transactions to Power an Idempotent API , Transactionally Staged Job Drains in Postgres , Implementing Stripe-like Idempotency Keys in Postgres .
Normally, article titles ending with “in [technology]” are a bad sign, but not so for Brandur’s. Even if you’ve never used Postgres, the examples showing how to lean on relational databases to enforce correctness will be revelatory.
I want to convince you that ACID databases are one of the most important tools in existence for ensuring maintainability and data correctness in big production systems. Lets start by digging into each of their namesake guarantees.
There’s a surprising symmetry between an HTTP request and a database’s transaction. Just like the transaction, an HTTP request is a transactional unit of work – it’s got a clear beginning, end, and result. The client generally expects a request to execute atomically and will behave as if it will (although that of course varies based on implementation). Here we’ll look at an example service to see how HTTP requests and transactions apply nicely to one another.
In APIs idempotency is a powerful concept. An idempotent endpoint is one that can be called any number of times while guaranteeing that the side effects will occur only once. In a messy world where clients and servers that may occasionally crash or have their connections drop partway through a request, it’s a huge help in making systems more robust to failure. Clients that are uncertain whether a request succeeded or failed can simply keep retrying it until they get a definitive response.
Jeff Hodges, Notes on Distributed Systems for Young Bloods . An amazing set of guardrails for doing reasonable things with distributed systems (and note that, though you might be able to get away with ignoring it for a while, any app that uses the network is a distributed system). Many points would individually qualify for this list if they were their own article—I reread it periodically and always notice new advice that I should have paid more attention to.
Distributed systems are different because they fail often • Implement backpressure throughout your system • Find ways to be partially available • Use percentiles, not averages • Learn to estimate your capacity • Feature flags are how infrastructure is rolled out • Choose id spaces wisely • Writing cached data back to persistent storage is bad • Extract services.
J.H. Saltzer, D.P. Reed and D.D. Clark, End-to-End Arguments in System Design . Another classic. The end-to-end principle has helped me make a lot of designs much simpler.
This paper presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements.
Bret Victor, Inventing on Principle :
I’ve spent a lot of time over the years making creative tools, using creative tools, thinking about them a lot, and here’s something I’ve come to believe: Creators need an immediate connection to what they’re creating.
I can’t really excerpt any of the actual demos, which are the good part. Instead I’ll just endorse it: this talk dramatically, and productively, raised my bar for what I think programming tools (and tools in general) can be. Watch it and be amazed.
Post the essays you keep returning to in the comments!
Liked this post? Get email for new ones: Also send the best posts from the archives
10x (engineer, context) pairs
What i’ve been doing instead of writing, my favorite essays of life advice.
format comments in markdown .
Quite a few of these are on my list, here’s some others that I keep returning to every so often:
- https://www.stilldrinking.org/programming-sucks
- https://medium.com/@nicolopigna/this-is-not-the-dry-you-are-looking-for-a316ed3f445f
- https://sysadvent.blogspot.com/2019/12/day-21-being-kind-to-3am-you.html
- https://jeffknupp.com/blog/2014/05/30/you-need-to-start-a-whizbang-project-immediately/
Great list! Some essays I end up returning to are:
- https://www.destroyallsoftware.com/compendium/software-structure?share_key=6fb5f711cae5a4e6
- https://caseymuratori.com/blog_0015
These are conference talks on youtube, not blog posts, but here’s a few of the ones I often end up sending to collaborators as addenda to discussions:
Don Reinertsen - Second Generation Lean Product Development Flow
Joshua Bloch
The Language of the System - Rich Hickey
Some posts:
https://speakerdeck.com/vjeux/react-css-in-js - diagnosis of problems with CSS (not because of React)
https://zachholman.com/talk/firing-people
Especially for fault-tolerant systems, “why restart helps” really opened my eyes:
- https://ferd.ca/the-zen-of-erlang.html
Oh, I forgot: http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf
Oldie but a goodie:
https://www.developerdotstar.com/mag/articles/reeves_design_main.html
+1 for that one
This is a great list. If i could make one addition it would have to be Rich Hickey’s “simple made easy”: https://www.youtube.com/watch?v=oytL881p-nQ
I was once working with a newly formed (4 person) team on a large and complex project under a tight deadline. For a while we weren’t seeing eye to eye on many of the key decisions we made. Watching and reflecting on this talk gave us a shared aim and, perhaps even more importantly, a shared language for making choices that would reduce the complexity of our system. It is a gift that keeps on giving.
Another one that belongs on this list: https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/
A couple of my favorites:
- https://nedbatchelder.com/text/deleting-code.html
- https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/
Out of the Tar Pit. https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf
I’d like to nominate another of Nelson Elhage’s posts:
- https://blog.nelhage.com/2016/03/design-for-testability
This has had more direct influence on my day-to-day code writing than anything else. (Also, his other writing on testing is great.)
As another commenter mentioned conference talks, Bryan Cantrill on debugging is important—it meshes well with Nelson’s Computer can be understood . ( https://www.slideshare.net/bcantrill/debugging-microservices-in-production )
A fave of mine: Clojure: Programming with Hand Tools https://www.youtube.com/watch?v=ShEez0JkOFw
Some essays I like:
Science and the compulsive programmer by Joseph Weizenbaum - written in 1976, but the described phenomena of a compulsive programmer still exists and may be relevant to many: https://www.sac.edu/academicprogs/business/computerscience/pages/hester_james/hacker.htm
https://www.mit.edu/~xela/tao.html - Tao of Programming - not sure if you can classify as an essay, but it is classic!
https://norvig.com/21-days.html - Teach Yourself Programming in Ten Years by Peter Novig - a great essay on how to master programming and why reading books like “Learn X in Y days” won’t be of much help. I recommend it to all beginners
Reginald Braithwaite, Golf is a good program spoiled - http://weblog.raganwald.com/2007/12/golf-is-good-program-spoiled.html . Raganwald has more great essays on his weblog, I just like this one the most.
The link of the last one ( https://vimeo.com/36579366 ) is broken. You may want to update it.
Paul Graham, “Maker’s Schedule, Manager’s Schedule " https://paulgraham.com/makersschedule.html
I keep thinking about those too:
https://www.teamten.com/lawrence/programming/write-code-top-down.html
https://rubyonrails.org/doctrine#provide-sharp-knives
IMAGES
VIDEO