A long list of technologies rarely wins an internship. The candidates we choose can show one finished project, explain it clearly, and tell us honestly what they got wrong.
Each time we open internship applications, we read a lot of very similar résumés. Most list the same handful of languages, a course or two, and a paragraph about being hardworking and eager to learn. Almost none of that helps us choose, because almost everyone claims it. Here is what does help, in case you are preparing to apply, here or anywhere else.
We start with the work you can show. A single finished project tells us more than a page of skills. It does not need to be clever or original. A working attendance system, a small shop with a cart and a checkout, a tool that generates invoices: any of these shows that you can take an idea from an empty folder to something a person can use. Put it on GitHub, write a short description of what it does and how to run it, and include a couple of screenshots. If it is live on the internet, even better.
Then we ask you about it, and this is where most of the sorting happens. We are not trying to catch you out. We want to hear how you think. Why did you structure the database that way? What was the hardest bug and how did you find it? What would you change if you started again? People who built their project themselves answer these questions easily, and often with enthusiasm. People who followed a tutorial line by line, or copied a repository, find them very hard. Neither group is bad, but only one has learned to do the job.
We value honesty about limits. An intern who says I have not used that before, but here is how I would find out is far more useful than one who claims to know everything and then freezes on the first real problem. Nobody arrives knowing our codebase. What we need is someone who asks good questions, reads the error message, tries something, and comes back with what they found.
Fundamentals count more than frameworks. Someone who understands how HTTP requests work, how a database query is structured, how to use version control and how to read documentation can pick up any framework in a few weeks. Someone who has memorised one framework without the basics underneath struggles the moment something behaves unexpectedly. That is why we ask small, simple questions about the ground beneath the tools.
Communication is part of the technical skill. Can you explain a problem in a message so that someone else can help without a call? Do you tell us early when you are stuck, rather than three days later? Do you respond when someone leaves a comment on your work? Working with a team is mostly this, and it is learnable, but we notice it right away.
A few things do not weigh as heavily as candidates fear. Marks matter less than what you have built. A degree from a particular college is not a filter. A long list of certificates does not move us much, although finishing a good course, and being able to say what you took from it, does show commitment.
If you want to improve your chances, do a small number of things properly. Build one project to completion. Learn to explain it in two minutes. Write a short and specific application, mentioning the programme you are applying to and what you hope to learn there. And be ready to talk about a mistake you made and what it taught you. That last one, more than any other, tells us who will grow quickly once they are here.