Cold Email for a Software Engineering Internship

Most cold emails from Indian engineering students get deleted in under ten seconds. Not because the student is unqualified, but because the email leads with a request instead of proof of work. This guide gives you a four-paragraph structure you can adapt in fifteen minutes, subject line formulas that survive a mobile inbox, and a follow-up cadence that doesn't sound desperate. It also covers the part most templates skip: what to do when nobody replies.

Why do most internship cold emails get ignored?

They ask for something before showing anything. A busy engineering manager opens an email that says "I am a hardworking student looking for an internship opportunity" and has no reason to keep reading. There is no link, no project, no signal that you understand what the company builds. The email is a cost to them, not a candidate.

The fix is mechanical: put a working link in the first two lines. A deployed project, a GitHub repo with a real README, or a merged pull request. One line describing what it does and why it connects to their product. That single change moves you from "student asking for a favour" to "builder showing work."

There is a second reason, specific to the Indian context. Many students email hr@company.com or careers@company.com because that is the only address on the website. Those inboxes are keyword-filtered. An engineer's inbox is not. The engineer can actually create an internship if they see someone useful.

Who should you email for a software engineering internship?

For product startups with fewer than 100 people, email the engineering manager, tech lead, or founder directly. For early-stage companies, the founder is often the only person who can say yes. For larger companies and GCCs, check whether a structured internship portal exists first — if it does, apply there and use email only as a supplement. If no portal exists, email a recruiter or an engineering manager, not a generic HR alias.

Finding the address takes ten minutes if you know where to look. The company website's team page, the GitHub organisation's commit history, LinkedIn profiles, and Twitter/X bios are the four reliable sources. Commit history is underrated: the person who merged the most PRs last quarter is usually the person who feels the pain of a thin team.

• Startup (1–50 people): founder or founding engineer.
• Product company (50–500): engineering manager or tech lead for the specific team.
• GCC or large service company: campus recruiter or the named internship portal owner.
• Avoid: hr@, careers@, info@ unless the job post explicitly says to use them.

If you are still building the profile that makes this email credible, start with building a GitHub portfolio that gets replies before you send anything.

What subject line actually gets opened?

Short, specific, and referencing either the company or the role. "Application for internship" reads like a bulk mail and gets filtered mentally before it is even opened. "Internship — built a rate limiter, can help with your API load" tells the reader there is a person behind the email who looked at their product.

Three formulas that work for Indian product teams:

• Project + role: "Internship — built X, want to help with Y"
• Specific reference: "Loved your [feature] — CS junior, built something similar"
• Direct ask: "Summer intern — one project link, 15-min call?"

Keep it under 60 characters where possible. Mobile inboxes truncate around 40–50 characters on most clients, so the first four words carry the entire decision. Never use all caps, never use exclamation marks, and never write "Urgent" or "Request" — both trigger spam filters and human annoyance.

What should the four paragraphs of the email say?

Paragraph one is two sentences. State your year, branch, and college in one line, then name the specific thing about their company that made you write. Not "I am a big fan." Something like: "I saw your changelog last week added WebSocket support for the dashboard — I built a similar real-time notification layer for my college's mess menu app." That sentence proves you read their work.

Paragraph two is your proof of work. One project, one line, one link. "I built and deployed [project name] — it handles 200 requests per second on a free-tier instance and the code is at [GitHub link]." If you have a merged PR to an open-source project, that is stronger than a personal project. Lead with it.

Paragraph three is what you can do for them. Be concrete about scope: "I can spend 2–3 months on backend work — API endpoints, test coverage, or bug triage — whichever your team needs most." This signals you understand internships are work, not training.

Paragraph four is the ask. "Would you be open to a 15-minute call next week, or a small trial task I can complete in a day?" A trial task is a low-friction yes for an engineer who is not sure about you yet. It converts better than a call request because it costs them nothing to say yes.

Your signature should include GitHub, portfolio, and one line of stack. No attachments unless asked. No resume PDF in the first email — it goes to spam and adds nothing that the links don't already show. For the resume itself, see resume tips for software engineering internships.

How do you personalize without sounding fake?

Skip the flattery. Reference a recent product update, a blog post, a GitHub issue, or a specific tech-stack challenge they have written about. Then connect your project to it in one sentence. "Your engineering blog mentioned you migrated from REST to gRPC for internal services — I did a smaller version of that migration for my college project and wrote up the latency numbers."

This works because it demonstrates three things at once: you read their material, you understand the technical problem, and you have done something adjacent. A generic "I love your company's mission" demonstrates none of them.

If you found the person through LinkedIn, mention it naturally. "Found your profile through the team page on your site" is fine. If you are unsure how to identify the right engineer, using LinkedIn to find the right person to email walks through the search filters.

How many emails should you send, and what reply rate is realistic?

Send 10–15 highly personalized emails per week, not 100 generic ones. A well-researched email with a working project link typically gets one reply for every 10–15 sends. Not every reply becomes an internship. The math is uncomfortable, which is exactly why personalization matters — it is the only lever that moves the reply rate.

Track every send in a simple sheet: company, person, date sent, follow-up date, outcome. After 30 sends you will see which subject lines and which project descriptions get opens and replies. That data is more useful than any template, including this one.

If you are not sure whether your profile is ready to send at all, check your internship readiness before you burn your list. Sending too early wastes the one shot you have with each company.

What does the follow-up look like — and when do you stop?

One follow-up after 5–7 working days. Then stop. A follow-up that says "just bumping this" adds nothing and reads as pressure. A follow-up that carries new information is different: a new project you shipped, a relevant article, a fix to the bug you mentioned in the first email.

Example: "Following up on my note last week. I shipped the rate limiter I mentioned — it now handles 500 requests per second and the write-up is here. Still happy to do a small trial task if that is easier than a call." That is a second email worth reading.

If there is no reply after the follow-up, move on. Do not send a third. Do not email a different person at the same company about the same role in the same week. Reapply after 3–4 months with a materially stronger project, and reference the earlier email briefly.

How do you adapt the same template for startups vs. service companies vs. GCCs?

Product startups respond to direct proof-of-work emails because the engineer reading it can create an internship on the spot. Service companies and large GCCs usually have structured internship portals with fixed timelines — emailing an engineer there rarely bypasses the process. For those, apply through the portal and use email only to ask a recruiter a specific question, like whether the portal is open for your graduation year.

The template below is for the startup and product-team case. For service companies, replace paragraph three with a line about your CGPA and any relevant coursework, because their filters are often academic. For GCCs, replace it with a line about a specific technology they use at scale.

If you are targeting off-campus roles broadly, the sequencing matters as much as the email itself. Off-campus internship strategy for tier-3 students covers how to layer cold email with referrals and portal applications so you are not relying on one channel.

Copy-paste cold email template for a software engineering internship

Subject: Internship — built [project], can help with [specific area]

Hi [Name],

I'm a [year]-year [branch] student at [college]. I saw [specific thing — changelog entry, blog post, GitHub issue] and it connected to something I built recently.

I built [project name], a [one-line description]. It's live at [link] and the code is at [GitHub link]. [One sentence on the hardest technical problem you solved.]

I can spend [2–3] months on [specific work — backend APIs, test coverage, bug triage]. I'm comfortable with [stack].

Would you be open to a 15-minute call, or a small trial task I can finish in a day?

[Name]
GitHub: [link] | Portfolio: [link]

That is roughly 110 words. Do not add a paragraph about your hobbies, your family, or your long-term career goals. The engineer is deciding whether to spend 15 minutes on you, not whether to invest in your future.

What should you never put in a cold email?

No mass BCC. No attachments unless asked. No "I am a hardworking student willing to learn" without evidence. No asking for "any internship" without specifying role or duration — vague asks get vague non-replies. No fake urgency, no "I know you are busy but," and no guilt-tripping about your financial situation.

Also avoid the trap of writing a 300-word email because you think length signals seriousness. It signals that you do not respect the reader's time. A busy engineer on mobile will read the first two lines and decide. Make those two lines carry your best material.