“Network more” leaves a lot for a student to figure out. Who do you write to? What do you ask? What can you show them when you haven’t had a job yet?
I was a senior software engineer before I became a founder. I’ve had hundreds of conversations over the past two months, including a 45-minute call with a student in Mangalore. These are the things I’d suggest trying if you’re looking for your first technical role.
If you’re in your seventh or eighth semester, you may have little time to find an internship or first job. Maybe you chose engineering because you wanted stable work. That’s a valid reason.
Give someone a small piece of work they can judge. They should be able to see the problem you chose and how you checked your answer.
For the wider problem of internships and hiring, read the internship search. For the next-step part, read mentoring that ends with a next step.
Pick a small problem you can finish
Keep it small enough that someone can understand it in one sitting.
Suppose a college club collects event registrations in a spreadsheet and sorts duplicates by hand. You could build a script or web page that flags duplicate entries and prepares a message list. Show the input beside the result so someone can check whether it works.
Write down four things:
Problem: What was slow, confusing, or error-prone?
Input: What data or action starts the work?
Output: What useful result does it produce?
Check: How did I verify that result?Put the code where people can see it. Add a short README and one screenshot or sample output. Say what you would change with more time.
That gives the person reviewing it something to ask about. They can see what you can do today.
Use AI as a tool you must check
AI can help explain an error or suggest a test you missed. It can also give you code that looks right and fails on the first real input.
Use it. Check the answer.
In the event-registration example, ask an AI tool to suggest matching logic. Test it with different spellings, blank phone numbers, and repeated email addresses. If it flags the wrong people, fix the rule and record why.
If that test catches a false match, write it down. You could explain it like this: “I used it to propose a rule, tested it against five awkward records, and corrected one false match.” Only use those numbers if they’re what happened.
You don’t need a paid stack to learn this habit. Use what you can access, whether that’s a free tier, a college account, an open-source tool, or hackathon credits. Ask a friend to review the result too.
Make a clear ask
“Can you help me get a job?” is a lot to ask someone who doesn’t know your work yet. A short project review gives them a clearer way to help.
Here is a message I would send to an engineer whose work I had actually read:
Hi Priya, I am a seventh-semester computer science student.
I read your post about API reliability and built a small registration-cleanup tool.
Could I ask you two questions on a 15 minute call about what I should improve before applying for internships?
I can send the one-page project note first. Thank you.Read their work before you write. The message should make it clear why you’re asking this person.
If you don’t ask, they have no chance to help. A no or no reply can sting. Try another person after a day or two.
Find rooms where work is visible
Go to hackathons, workshops, meetups, technical groups, and online communities. Go there to learn how people talk about real work.
When you meet someone, ask what they are building or what a junior person can practise. Follow up when you have done the thing they suggested.
When you report back, they have a reason to remember the conversation. You tried what they suggested.
Publish something you can stand behind
Write about the work you are doing and the questions you still have. You can post on LinkedIn, a blog, or another place you can keep up with. A separate account is fine if it is honest. Do not use fake credentials.
I study how people I respect explain a problem. Then I write from my own experience. You can do that too. Credit the person when you directly borrow an idea or format.
Before you post, read it twice. Remove claims you can’t support. Check the links, code, and screenshots so someone reading can follow what you did.
Judge an internship before you accept it
No job is too small when it gives you dignity and pays or teaches something real. That does not mean you should accept an unpaid, vague role because you are anxious.
Get the scope in writing. Find out who will review your work and what you’ll ship or learn in the first two weeks. Check the stipend, tools, schedule, and what happens at the end before you accept.
If a relevant project comes up at GattyWorks, I would offer an internship and access to the tools needed for the work. That depends on there being work that fits.
A suggestion for the next seven days
- Choose one small problem and write the four-line brief.
- Build the smallest useful version and test an awkward input.
- Write a one-page project note with a screenshot or output.
- Send one clear message to someone whose work you have read.
- Join one event or technical group, then record what you learned.
- Publish one short, checked post about the project or the search.
- Review the week with someone who will ask what happened.
This plan can’t promise an interview. A checked project and a note can help with your next request. Start with the four-line brief.