Learn in Public and Build Your Network Before You Need It

Most students start networking the week they need a referral. By then, all they can send is a cold message to a stranger: "Hi sir, please refer me." Some of those work. Most are ignored, because the stranger has no reason to believe anything about the sender.

Now imagine sending the same request to someone who accepted your connection request a month ago, has seen two of your posts about the payment service you were building, and replied to one of them. You are not a stranger any more. That difference costs a few minutes a day for a few weeks, and this article shows how to spend them.

• Whom to connect with first, and how to find them.
• How to write a connection note that gets accepted.
• What "learning in public" means for a fresher, and a three-post pattern to start.
• How to comment in a way that people remember.
• How to ask for, and run, a fifteen-minute conversation with someone ahead of you.
• Where AI helps and where it does damage.

A referral request is a small favour (article 19). People do small favours more readily for someone they recognise. Recognition comes from small, repeated, low-pressure contact: they accepted your request, saw a post, read a comment, exchanged a message. None of this is manipulation. It is how professional relationships normally start, just compressed into weeks.

Start four to six weeks before your application sprint. If you are already mid-search, start now; the next round of referral requests will benefit.

Who to put lower on the list: very senior people with huge followings, who receive far more requests than they can answer, and people with no connection to your goals at all.

On LinkedIn, open your college's page and its Alumni tab. You can filter alumni by where they work, what they do and where they live. Filter by one target company and "engineering", and you have a list of people with a built-in reason to talk to you. Note them in a "People" tab in your tracker with the company and how you are connected.

LinkedIn lets you add a short note to a connection request. The note has one job: make accepting easy. It is not the place to ask for anything.

The pattern: something specific about them · who you are in one line · no ask.

Hi Ananya, I read your post on moving your team's tests to containers. The partabout flaky time-zone tests was exactly what I hit last month. I'm a final-yearECE student building backend projects in Java. Would be glad to connect.

Hi Rahul, I'm a 2025 graduate from [college] too (IT, 2025). I'm building backendprojects in Node.js and noticed you joined [company] last year. Would be gladto connect.

What to avoid in the note:

• An immediate ask ("Can you refer me?"). It comes later, in a message, if at all.
• "Sir" and "madam" with peers a year or two older. A first name is normal on LinkedIn.
• Generic praise ("I'm inspired by your profile"). It reads as copied.

Free accounts can send only a limited number of personalised notes, and LinkedIn limits how many invitations you can send. So spend notes on the people who matter most, and send requests at a steady pace rather than in bursts.

"Learning in public" means sharing what you are building and learning, as you go, in short, specific posts. For a fresher it does three things: it shows that your projects are real, it makes you findable by name, and it gives the people you connected with a reason to remember you.

Specific beats impressive. Good fresher posts look like this:

• The start: "I'm building a payment service that never double-charges, even when the network fails mid-request. Here's the plan and the one part I'm unsure about."
• The problem: "Day 9: two simultaneous requests with the same idempotency key both got processed. Here's how I found it, and the database constraint that fixed it." (A code snippet or diagram helps.)
• The finish: "Shipped. Live demo, code, and three things I'd do differently."

Other good topics: a bug that took a day to find, a measurement (before and after), something you learned from a code review, a short summary of a talk you watched with your own opinion.

Avoid: motivational quotes, "Day 47 of #100DaysOfCode" with nothing in it, reposted tips, and posts about how many applications you have sent.

One good post a week is plenty, and more sustainable than daily posting. Write when you have something specific to say. Scheduling tools exist if you prefer to write several at once.

Draft the post yourself from your notes, then ask for an edit:

Here is my draft LinkedIn post about something I built. Edit it, keeping myvoice and every technical detail. Rules:1. Make the first line specific enough that an engineer would stop scrolling.   Do not use clickbait or "Here's what I learned" style openers.2. Remove generic phrases and hashtags beyond three relevant ones.3. Keep it under 200 words.4. Do not add claims, numbers or results I did not write.Then list what you changed and why.[paste draft]

A thoughtful comment on an engineer's post is often more valuable than a post of your own, because the author reads it. "Great post!" adds nothing. A useful comment adds something: a related experience, a specific question, a respectful counterpoint.

Weak:   Great insights, thanks for sharing!Useful: The point about retry storms matched what I saw in a small project: adding        jitter to back-off made the spikes disappear. Did you find a fixed jitter        range worked, or did you tune it per service?

Two or three useful comments a week, on posts by people in your target companies or domain, are enough.

Once you are connected and have exchanged a message or two, you can ask someone a year or two ahead for a short conversation about their path and their company. This is sometimes called an informational chat. It is not a referral request. It is a way to learn, and often it leads to one.

How to ask:

Hi Priya, thanks for connecting. I'm preparing for backend roles and [company]'swork on [area] is a big reason I'd love to work there. Would you have 15 minutesin the next couple of weeks for me to ask a few questions about how you preparedand what your team works on? Happy to fit around your schedule, and no problemif you're too busy.

How to run it:

• Prepare three or four questions that cannot be answered from the company website: "What surprised you in your first month?", "What did your interviews focus on?", "What do you wish you'd learned before joining?"
• Keep to time. At fifteen minutes, offer to end.
• Do not ask for a referral in the call unless they offer. Ask afterwards, in writing, if it feels right, with your referral package ready (article 20).
• Thank them the same day, mentioning one thing you will act on.
• Update them later when you act on their advice. That is what turns a conversation into a relationship.

Developer communities on Discord, Reddit and elsewhere often have resume-review or project-feedback channels. Posting your resume (contact details removed) or project there brings blunt, useful feedback from people who do not know you, which is exactly the view a recruiter has. Read each community's rules, and say thank you for every useful reply.

Over five weeks, Imran, a 2025 graduate, does the following:

• Week 1: lists 30 alumni at 12 target companies; sends 8 connection requests with notes; 6 accept.
• Week 2: posts about starting his notification-service project; leaves useful comments on three engineers' posts.
• Week 3: posts about a retry bug and its fix; one alumnus comments; Imran replies and asks a question.
• Week 4: asks that alumnus for a fifteen-minute conversation; it happens; he learns the team uses a message queue he has not tried, and adds it to his project.
• Week 5: a role opens on that alumnus's team. Imran sends a short referral request with his package. The alumnus refers him the same day.

Nothing here is a trick. It is visible work and small, genuine contact, started early enough.

• Starting only when you need a referral.
• Asking for a referral in the connection note.
• Sending dozens of identical requests in a day.
• Posting nothing specific, or posting only about job-search stress.
• "Great post!" comments, which nobody remembers.
• Mass-produced AI messages and comments.

Hi [first name], I'm a final-year [branch] student at [college] building backendprojects in Java; my latest is a booking API that handles concurrent requests.I saw you work on [team or area] at [company] and would be glad to connect.

My booking app's "Today" page showed yesterday's events to anyone who opened itbetween midnight and 5:30 am.Two days of debugging later: I stored event dates in Indian time (IST) butworked out "today" from the server's clock, which runs in UTC. IST is 5 hours30 minutes ahead, so from midnight to 5:30 am in India the server stillthought it was yesterday.The fix: store every time in UTC, and convert to the user's time zone only whendisplaying. I added three tests: 11:59 pm IST, 12:01 am IST and 5:31 am IST.Lesson: decide on a time zone for storage on day one.#java #backend #timezones

• Next: Where Fresher Jobs Actually Appear: Channels and Trade-offs maps where the roles you want are posted.
• For a fuller guide to your LinkedIn profile, see A LinkedIn Profile That Gets Recruiter Messages.
• For writing messages with AI that still sound like you, see How to Use AI for Emails and Documents Without Losing Your Voice.