This doc is personal, subjective advice for high schoolers and early college students going for a first internship in security, IT, or software. It comes from my own path, from questions students ask me, and from sitting on the other side of the table as an interviewer.
The single most important thing to know: nobody expects an intern to know much. When I interview someone for an internship, I am looking for a person who is curious, easy to work with, and will show up every day and try. Everything below is in service of showing that.
Finding openings
Look for postings, but do not stop there. If a company or team you admire has no internship posted, reach out to someone who works there, or their manager, and ask whether they expect an opening around the time you are looking. The worst case is they say no. A common case is they say no but point you to the right person or a different opportunity.
A coworker of mine got her job by emailing the CEO of our small company and asking whether there were openings. We all thought she was crazy. It got her an interview, then the offer.
Network with real people. University clubs, DEFCON, Queen City Con, Meetup groups, online communities, and your own professors are all ways in. Many internships come from someone knowing your name before your application lands.
I largely got my first internship by being an active member in my university’s cybersecurity club.
Before the interview
Get your resume reviewed. Ask friends and family, and ideally someone who already works in the industry. See Building your first resume for how to put one together when you have no professional experience yet.
Work on a project. Do a CTF, write a small program, or set up a homelab. A project gives you something concrete to talk about and is the clearest evidence that you actually enjoy this. A small project you understand deeply beats an ambitious one you cannot explain.
Research the company. Learn what they actually do and how they make money. Read about their interview process. Showing up not knowing what the company does is an easy way to end the conversation early.
Follow the industry. Interviewers often ask what you read to keep up. Find a few podcasts, YouTube channels, newsletters, and blogs that you genuinely follow, so you have an honest answer. A few I actually read: Detection Engineering Weekly, the Reddit engineering blog, and Hacker News.
Expect a basic technical interview. It is usually fundamentals, not tricks. Be ready to talk about the technologies you have used and the ones you want to learn, and to go a little in depth on two or three of them.
A few I like to ask:
- “Pick something on your resume and go as deep as you can.”
- A good answer picks one thing and keeps finding another layer: why it was built that way, what broke, what you would change now.
- A bad answer lists everything on the resume at the same shallow depth.
- “What happens when you enter a URL into a browser and press enter?”
- A cliché question, I know. But, I want to hear if you know about DNS, TCP, TLS, and HTTP in roughly the right order. “I’m not sure” is a valid answer when you run out of detail. I am not grading completeness.
- “Tell me about a time you were stuck and how you got unstuck.”
- Good answers involve trying something first and then asking a specific person a specific question.
- Bad answers include “I googled it” and “I never really get stuck.”
Know your “why.” They will ask why you are interested in this field and what you hope to get out of the role. Decide before you walk in.
Prepare stories with the STAR method. For behavioral questions, structure your answer as Situation, Task, Action, Result. Write out a few stories in advance from school, projects, competitions, or past jobs. See The STAR method for the format.
Practice with an LLM. Give it context about the role and ask it to generate likely interview questions, then write your own answers with real stories. Ask it to review your resume and suggest questions you could ask the employer. Trust but verify: it can be confidently wrong or out of date, so check anything specific.
In the room
Show up in a good state. Sleep well, eat, and look over your notes beforehand. If it is remote, use a decent webcam and microphone, dress the part, and tidy whatever is behind you.
Attitude counts as much as skill. Someone who is cheerful, calm, and clearly passionate is an immediate plus for me.
Show yourself off, because no one else will. Talk about your projects, coursework, competitions, certifications, and homelab. Be specific about what you personally built or did.
It is okay to say “I don’t know.” Follow it with what you would want to learn: “I haven’t used that, but I’ve been meaning to dig into it.” If they ask whether you know a programming language and you don’t, say which one you want to learn and why. Pretending to know something is worse than not knowing it.
Do not use an LLM during the interview itself. You will be caught, and it will not go well. The preparation is where an LLM helps; the conversation has to be you.
Bring a notebook. Take notes on what your interviewer asks about or mentions. It gives you things to follow up on.
Have questions ready for them. Interviewers will ask, and coming empty-handed reads as a lack of interest. Good questions also help you figure out whether you actually want the job. A few to start from:
- “Talk me through a typical work day.”
- “How can I be successful in this role?”
- “What is a problem your team has not fully solved yet?”
The last one is my favorite to hear. As the interviewer describes what the team has not solved yet, you get openings to connect your own experience to it and show that you want to work on real problems.
Thank everyone for their time. Say it at the end, and send a short follow-up note the next day. (old-school I know)
Afterward
A bad interview is still a win. Everyone has bombed one. You come out with experience and a much better sense of what interviewing well takes. Do not let one rough conversation stop you from applying to the next.
I had a live coding interview go badly for me. I was nervous, my mind blanked, and the silence stretched while I stared at the problem. Time ran out before I solved it. I somehow still got the job.
Early on, take the offer that teaches you the most. Early skills compound. A first role that puts you next to strong people and hard problems tends to out-earn the one with the bigger starting number within a few years. That calculus shifts later, but it holds at the start.