Saltar a contenido

09 - Building in public

What this session is

Why and how to share your work as you learn. The non-obvious part of breaking into AI engineering.

Why this matters more than people admit

The traditional "build resume → apply → get filtered by ATS" funnel is broken in AI specifically because:

  • The market is flooded with applicants for entry roles.
  • Recruiters can't tell from a resume who actually understands LLMs vs who took a Coursera course.
  • Hiring managers increasingly pre-filter by signals outside the resume: GitHub, blog, Twitter, a working demo.

If a hiring manager Googles your name and finds nothing, you're starting at zero. If they find a blog with real technical writing, an active GitHub, a Hugging Face profile with a couple of models, a working demo - you're starting in the "let's interview this person" pile.

This effect is more pronounced in AI than in traditional software engineering.

What "building in public" means

Three behaviors:

  1. Share your work as you do it, not after.
  2. Write honestly about what you tried, what worked, what didn't.
  3. Stay consistent for months, not weeks.

It does not mean: hot takes on Twitter, follower-chasing, motivational posts, AI-generated threads.

The minimum viable public footprint

By month 6 you should have:

  • GitHub profile that looks alive. Not 80 forks. A few real repos with READMEs, commits across several months. Pinned repos representing your best work.
  • Hugging Face profile with at least one model or dataset you uploaded.
  • A personal site or blog with 3-5 honest technical posts.
  • One social account (Twitter/X, Bluesky, or LinkedIn) where you occasionally share what you're building. Not daily. Weekly is fine. Don't overthink it.

That's it. No need for newsletters, podcasts, YouTube. Diminishing returns past the basics.

What to write about

Tutorials are saturated. Don't add another "intro to RAG." Instead:

  • "I built X and here's what surprised me." Specific projects. Honest reactions.
  • "I benchmarked A vs B." Comparison posts age well and get linked.
  • "I tried to reproduce paper X and here's what happened." Honest reproduction work is valuable and uncommon.
  • "Here's what I got wrong about X and learned." Vulnerability posts often resonate.
  • "Here's the bug that took me 4 hours." Future-you and other engineers will Google this.

What to avoid:

  • "Top 10 AI tools" listicles.
  • "Why I think AGI will arrive in 2027." (You don't know.)
  • AI-generated content. Readers notice.
  • "I'm learning AI" posts with nothing to show.

Formats that work

In order of return:

  1. Working demos (HF Space, Modal app, Vercel deploy). One demo > ten blog posts.
  2. Long-form technical write-ups (1500-3000 words). On a personal site or Substack. Cross-post excerpts.
  3. Annotated GitHub repos. README quality matters more than star count.
  4. Short videos (5-15 min walking through code on your screen). Most underused format.
  5. Tweet threads or Bluesky posts linking to the above.

Consistency over volume

Six honest posts over six months beats sixty posts in the first month.

The signal a hiring manager wants: this person showed up consistently to a hard thing. That's only visible across time.

The 10x non-obvious move: publish models

Most aspiring AI engineers build apps; almost none publish models. Even a tiny fine-tuned model on a niche task - pushed to the Hub with a real model card - sets you apart.

Examples that have landed real jobs:

  • A LoRA fine-tune of a small model for a domain-specific task (legal, medical, code).
  • A re-implementation of a paper's method, with benchmarks.
  • A merged model variant.
  • A dataset for an under-served task, with documentation.

Time investment: 1-2 weeks. Signal: enormous.

The other 10x move: contribute to OSS

Already covered in Open source as resume. The short version: an accepted PR to vLLM / transformers / langchain weighs more than a personal repo with 1000 stars.

How to start

Week 1: - Set up a GitHub profile README. - Create a Hugging Face account. - Pick one platform (Twitter/X, Bluesky, LinkedIn). Don't fragment yet. - Buy a domain (yourname.dev or similar). Set up a one-page site.

Week 2-4: - Write your first post. Make it about something you actually built or learned this week. - Push your first working repo with a real README. - Don't worry about audience. Audience comes much later, if at all.

Month 2 onward: - Post once every 1-2 weeks. Schedule it. - Engage genuinely with 5-10 accounts in your specialization. - Don't chase trends. Stay on your specialization.

The grim truth about audience

Most of your posts will get no engagement for the first 6-12 months. That's normal. Audience compounds slowly. The people you need to reach are not the masses - they're the 10-100 hiring managers who'll find your work when they're considering you.

If you check stats more than once a week, you'll quit. Don't.

Optional: newsletters, podcasts, YouTube

If you genuinely enjoy them, do them. They're force multipliers if sustained. They're black holes if you're doing them for the wrong reasons. Default to "no."

What you might wonder

"What if my employer doesn't allow side projects?" Some companies require IP assignment for everything. Check. Negotiate. Most are flexible for non-competing work. Worst case: build on personal time, with personal hardware, on topics unrelated to your day job.

"What if I'm not 'good at writing'?" Doesn't matter. Honest, specific, technical writing wins. Polish less, ship more.

"What if I sound stupid?" You will sometimes. Everyone does in retrospect. Posts from a year ago will embarrass you - that's the proof you've grown.

"Should I use AI to write the posts?" Use it to edit. Don't use it to write. Readers can tell. It's an immediate trust-killer when noticed.

Done

  • Set up the minimum viable footprint.
  • Have a posting cadence target.
  • Picked formats over chasing every channel.

Next: Your portfolio - 3 projects →

Comments