The Skills Employers Actually Test For in Early-Career Roles

I have interviewed a few hundred students for internships over five years. The candidates who get offers are rarely the ones with the longest list of technologies. Here is what I am actually assessing, in the order it matters.

Can you describe your own work precisely

The first question is always some version of "tell me about something you built." What I am listening for is whether the answer has edges — a specific problem, a specific decision, a specific outcome.

Vague answers are not usually dishonesty. They are the result of never having been asked to explain the work to someone outside it. Practise this before an interview: explain one project out loud to a friend from another department, and notice where they stop following.

Can you say "I don't know"

I will always ask something past the edge of your knowledge. That is deliberate. The good answer is "I have not worked with that — my guess would be X, but I would want to check." The bad answer is a confident invention.

In an internship, someone confidently wrong is more expensive than someone honestly uncertain, because the team stops double-checking them.

Can you work with existing code and existing decisions

Student projects are usually greenfield. Real work almost never is. You inherit a codebase with strange decisions, or a marketing calendar someone else set, or a dataset with fields nobody can explain.

The trait I look for is curiosity before judgement. Candidates who say "the code was bad" without being able to say what was bad about it worry me. Candidates who say "there was a caching layer I did not understand, so I read the commit history and found out why it existed" are the ones who function in week two.

Can you write

I mean plain written communication: an update, a summary, a bug report. Every remote or hybrid team runs on written communication, and unclear writing gets good work overlooked.

This is the most improvable skill on the list, and the most neglected. Write the update, then delete half the words, then see if it still says everything.

The technical bar, honestly stated

For a frontend internship, I want to see that you understand what the browser is doing — not that you have memorised a framework's API. For a data role, I want to see that you understand why a validation split matters, not that you can name ten models.

Depth in one thing beats familiarity with ten. A candidate who has genuinely built one non-trivial thing is more interesting than one who has completed ten tutorials.

What does not move the needle

• Certificates without an associated project. They demonstrate attendance.
• A list of twenty technologies. It reads as low confidence in all of them.
• Percentages and CGPA past the first screen. They matter for shortlisting at scale, and then stop mattering.

Preparing for the interview

Pick two projects. For each, be able to say in under two minutes: what problem it solved, what you personally did, what you would change now. Then be ready to go deeper on any sentence you said.

That preparation is worth more than a month of general revision, because it is the actual thing being tested.