Some things I saw when hiring interns

Recently at $DAY_JOB I had the bright idea to run an internship programme. Unfortunately, the idea came to me half way through the year; approximately four months after the time we should’ve thought of it. The upshot of this is that we had to design the programme, open applications and review those applications within three weeks, or we would’ve been too late given the constraints of the academic calendar.

I have just finished reviewing just over one thousand applications for three spots, in the space of two weeks. It was hell. I’ve hated everything about my life for fourteen days. I was scheduling rejection emails at two in the morning on a Sunday. I almost cancelled the programme and quit my job to become a LinkedIn influencer. Thankfully things never got that bad.

The only benefit from this torture – which surely must be proscribed by the Geneva Convention – is that it’s given me a new insight into the world of internship applications. I’ve hired plenty of entry-level engineers before, but I had not realised before how different an internship application could be.

Why internship applications are different

We decided early in our blind panic era not to set an upper or lower bound on the experience expected of the candidates. This meant we saw people who were pre-university, and received applications from those with a couple of years’ full-time experience. Nonetheless, a significant majority of candidates were in-between years of university. This is the first major point of difference between hiring interns and hiring entry-level roles: you don’t have the outcome of the university degree as a signal. Entry-level CVs are tautologically sparse; of course they are. Interns’ CVs are even more sparse, they’re full of “(predicted)” caveats, and the obvious signs of creative exaggeration (for what it’s worth, I’m entirely sympathetic when I see someone at university overstate something on their CV).

A quick attempt at justifying leetcode

It was regrettably necessary for us to use a coding platform as part of our assessment process. The internet is full of hate for leetcode style tests; I get it. There were three reasons behind this decision, two of which I’ve already mentioned: the time pressure and the quantity of applicants. The third reason is that we are a deep-tech startup – the internship is going to be challenging and we wanted to make sure the candidates we hired would be able to both adapt and thrive.

Every single submission was manually reviewed, but the use of the platform meant most reviews could be completed in 5-10 minutes; our standard tech test normally takes two reviewers 20-30 minutes.

Health warning

The following sections are highly subjective opinions. They’re based on my previous experience as a hiring manager – for this internship programme and many roles before it. Like all opinions, there will be others who disagree with what I’ve written, and I make no claim to be “right” above them.

What not to do: cheat

Now my admission about using a leetcode test has lost all of your goodwill, I can talk about the first major error we saw many candidates commit in their applications: cheating on the technical test. The platform we used has automatic cheat detection, but we learned early in the process not to trust this; it was riddled with false positives that were easily dismissed when we manually reviewed the test. Nonetheless, it is very, very obvious when someone cheats on a coding assignment. There were candidates who completed a two challenge assessment in less than twenty minutes; the average time to complete was just above two hours. We would’ve believed these were generationally-talented coders, except we could see on the test replay that they had clearly copy-pasted the code wholesale from ChatGPT or similar (n.b. we explicitly asked not to do this at the outset of the test). Amazingly, some candidates even accidentally submitted their GPT prompt with their code.

Attempts at more subtle methods of cheating are still obvious. Wise to the fact that the platform detects pasting into the IDE, some candidates robotically typed in the output from an AI assistant from another window. It’s very clear when someone is writing code manually, and when they are copying something over. The cadence of your typing, and the way coding is a linguistic manifestation of your thought process cannot be faked to someone watching you do it.

Once again, I am sympathetic. I’m sure many of these candidates have applied for multiple internships or jobs. They’ve probably had to do several technical assessments, each one can be time consuming. It is still not worth cheating. Even if you’re not caught, it’s worth saying you probably don’t want an internship in a place where they can’t detect obvious signs of cheating.

What not to do: bury the lede

For current students, or those who have just graduated, it’s likely that your degree is more of the more relevant things about your application. Do not bury the education section at the bottom of your CV. I’ve read many CVs over the past few weeks which first listed typical ‘student jobs’ – those that you do before, or during, university to make ends meet; but these tend not to be that relevant to the application you’re making.

When you’re crafting your CV for an internship role, think strategically about ordering. Put the most relevant content at the top of the CV. Do not go into great detail about projects or work experience that is not relevant.

What to do: differentiate yourself with extra-curricular projects

When I was younger, I was sceptical (probably to give cover to my intrinstic laziness) of side projects, or other extra-curricular activities, as a boost to employability. I thought that employers were unlikely to find that a toy project, one that didn’t achieve anything particularly novel, was that interesting. I was wrong. There are two signals we get from projects: firstly, it demonstrates genuine interest in the field they’re studying. A candidate that can show they’re building projects, writing code, solving problems, outside of what they’re asked to do for their studies is inherently more interesting to me as a hiring manager. Secondly, they’re a non-employment route to gaining more experience. Even the most rudimentary of projects will expose you to the same building blocks that you’ll encounter on the job. Again, this gives me confidence that you’re more likely to succeed if we hire you.

Universities tend to offer great opportunities for this kind of thing – things like research labs and summer programmes provide fantastic opportunities to build a stronger CV and stand out from the crowd. You do not need to rely on your univerisity; you can build something entirely by yourself.

What to do: attention to detail

This is evergreen advice: typos, or other simple mistakes, really negatively affect your chances. The reason this happens is that an internship/job application is important, and so it carries the expectation that you’ve put effort and care into it. Given this, if we see simple mistakes, then it’s a bad signal.

Maybe you didn’t care that much: fair enough, but we’ll give the role to someone who cared more. Or perhaps you’re not that attentive and make simple mistakes, even when you shouldn’t: this makes me worry about the quality of your work if we hired you.

I know these are harsh views to take on such little evidence, but when you’re making hiring decisions for an ultra-competitive role, you have to consider every signal you get.

What to do: seize the opportunity to align yourself

Most internship applications will contain screening questions and/or a cover letter. Yep: they’re annoying. Do not make a mistake here: these actually are important. From one thousand applicants, we had a longlist that progressed to the technical assessment stage of approximately 150. Of these, a fairly small fraction were disqualified for blatant cheating. Of the remaining, a smaller fraction were disqualified for failing the test. So we were left with approximately 80-90 candidates who had great CVs, and great tech tests. Given that we had capacity for at absolute most twenty-five interviews, our application screening questions presented the final chance to differentiate between candidates.

There are several objectives to aim for when you’re answering screening questions, or writing a cover letter.

The most well known one is expressing your motivation for the role: this is a necessary, but not sufficient, distinguisher. Someone who doesn’t leave me with a sense of genuinely wanting the role will likely be disqualified, but this is something with diminishing returns: there were many, many candidates who talked cogently and convicingly about how much they wanted to join us.

We also looked for signs of competency in the application questions as asked. This is very much an exercise in “show, don’t tell”. Some candidates told us how good they are, but neglected to prove that with anything substantial. The strongest candidates found academic or other projects that showed us that they had tackled difficult problems before.

Finally, and certainly the hardest, we looked for relevancy. Candidates that were able to tell us about experiences that spoke to the type of work they would do in the company really stood out. This is simply impractical at scale – you’re not going to be able to build a catalog of relevant experience for everything you apply for, but you will be a stronger candidate for roles where you have done something directly relevant.

Closing thoughts

Applying for internships is hard. There is lots of competition and you’re early in your career, so you have less opportunity to distinguish yourself from the crowd. Nonetheless, there are two key traits that all of the stronger applications had. Firstly, they didn’t make any of the simple mistakes I’ve discussed above. They were high quality, well-written applications. Secondly, they were candidates who had been proactive in their academic careers, maximising the opportunities they had both inside and outside of university.