This post shares my notes and reflections on how to find remote jobs, based on what I have learned by observing others, reading, and exploring different approaches.

I am writing this as someone who is still learning and experimenting, not as an expert.

If you are early in your career and trying to understand remote job opportunities, this might be helpful.

Why I Looked Into Remote Jobs

I wanted to understand how people actually get remote jobs, beyond just applying on job portals.

I had heard about networking, building profiles, and open source before, but I wanted clearer direction on how these pieces fit together.

What This Learning Focused On

The main focus was on two ways to find remote jobs:

• Applying to existing opportunities

• Creating opportunities by building credibility

It also highlighted common mistakes people make while searching for remote roles.

Key Learnings

Two Clear Ways to Find Remote Jobs

Remote jobs can be approached in two main ways.

The first is applying directly by checking:

• Company career pages

• Social media

• Platforms like LinkedIn and X

You can also reach out to company employees through LinkedIn messages, X, or cold emails and clearly express your interest.

Why this matters:
Many roles are filled through direct outreach and early visibility, not just job boards.

Creating Opportunities by Building Credibility

The second approach is long-term but powerful.

Instead of only applying, you build a strong online presence through:

• A clear LinkedIn profile

• Regular posts on X

• A portfolio or blog

• Sharing what you learn in public

Why this matters:
When your work is visible, opportunities often come to you.

Learning in Public and Networking

Learning in public means sharing progress, not perfection.

This includes:

• Posting what you are learning

• Sharing small wins and lessons

• Writing simple blogs on platforms like Hashnode

Networking here is about conversations, not asking for jobs.

Why this matters:
People trust and remember consistent learners.

Open Source as a Career Signal

Contributing to open source shows real skills.

It helps others see:

• How you work

• What you know

• How consistent you are

Why this matters:
Open source becomes proof of work without needing explanations.

Common Mistakes to Avoid

Lack of Clarity

Not knowing what role you want slows everything down.
Explore different fields, then choose one direction.

Chasing Numbers Instead of Credibility

Followers do not matter if your profile has no substance.
Skills and consistency matter more.

Giving Up Too Early

Remote jobs take time.
Stopping too soon is a common mistake.

Taking Rejection Personally

Rejections are part of the process.
They help you improve if you stay patient.

Lack of Patience

Remote hiring moves slowly.
Consistency matters more than speed.

Things That Made Me Think

1. Clarity matters more than applying everywhere

2. Visibility builds trust over time

3. Open work speaks louder than resumes

4. Patience is a real skill in remote job search

My Reflections

This learning made me realize that remote jobs are not about shortcuts.

They are about clarity, steady effort, and showing your work openly.

What I’m Taking Forward

1. Be clear about what I want

2. Build credibility step by step

3. Share learning without pressure

4. Stay patient and consistent

Reference

A Conversation on finding remote jobs.

This post shares my notes and reflections after watching a conversation on getting remote jobs through open source and learning in public.

I am writing this as someone who is still learning and exploring these ideas, not as an expert.

If you’re early in your career and curious about remote opportunities and open source, this might be useful.

Why I Watched This Conversation

I wanted to understand how people actually find remote jobs through open source and how learning in public fits into that journey.

I had heard these ideas before, but this conversation helped connect them more clearly through real experiences.

What the Conversation Focused On

The discussion covered open source contributions, consistency, building projects in public, technical writing, and how these efforts can gradually lead to remote opportunities.

Key Learnings from the Conversation

It’s Never Too Late to Start Open Source

A key point was that timing and age do not matter in open source.

What matters is starting and staying consistent.

Why this matters:
Waiting for the “right time” often delays growth more than lack of skills.

Consistency Matters More Than Speed

Regular contributions help people notice your work over time.

This naturally helps in building a network and trust.

Why this matters:
Most meaningful opportunities come from consistent effort, not quick results.

Open Source Projects Act as Proof of Work

Building projects in public and keeping them open makes your work visible.

You don’t need to explain everything repeatedly your work speaks for itself.

Why this matters:

Open work becomes real proof of learning and capability.

Learning in Public Through Technical Writing

Technical writing was discussed as a simple way to learn in public.

Platforms like Hashnode allow you to convert raw notes into clear articles, which can sometimes reach wider developer communities.

Why this matters:

Writing helps you learn better while sharing value with others.

Focus on Sharing, Not Immediate Outcomes

A strong message was to avoid focusing on what you’ll get in return.

Instead, focus on contributing, learning, and sharing honestly.

Why this matters:
When contribution is the goal, outcomes often follow naturally.

Things That Made Me Think

• Age and timing matter less than consistency

• Open source quietly builds strong networks

• Writing is a powerful learning tool

• Growth doesn’t need to be fast or loud

My Reflections

This conversation reinforced the importance of sharing what I’m learning and learning from others’ experiences.

It reminded me that steady contribution and openness matter more than chasing quick results.

What I’m Taking Forward

• Start and stay consistent with open source

• Share learning without pressure

• Focus on community and clarity

• Use writing as a thinking tool

Reference

A conversation on open source, remote jobs, and learning in public featuring Kunal Kushwaha.

While watching the video, I wrote down a few points that stood out to me. This post is simply me organising those notes and sharing my reflections.

Why I Watched This Video

I wanted to understand how people actually find remote jobs and how learning in public plays a role in that journey.

I’ve heard these ideas mentioned before, but this conversation helped me connect them more clearly with real experiences.

Key Learnings from the Video

Remote Work Removes Daily Travel Stress

One of the first things discussed was how remote work eliminates travel time.

If your office is far away, commuting can take up a big part of your day and add unnecessary stress.
With remote work, you start your day fresh, without that mental and physical exhaustion.

That alone changes how you show up at work.

Remote Work Encourages Better Communication

In remote jobs, most communication happens through video calls.

Because of this, you naturally start getting more comfortable being on camera.
Over time, this helps reduce hesitation and awkwardness when speaking online.

This comfort doesn’t stay limited to work it slowly extends to other areas like social media and public communication.

Company Offsites Help Build Real Connections

Even in remote companies, offsites play an important role.

Meeting teammates in person, even occasionally, helps you understand people better beyond screens.
It strengthens relationships and makes collaboration feel more human.

Learning in Public Builds Credibility

A major point from the conversation was about learning in public.

Sharing what you’re learning helps build:

• Credibility

• Proof of work

• Visibility over time

This doesn’t mean pretending to be an expert.
It simply means documenting your learning honestly.

Over time, this can naturally lead to opportunities including job offers.

Ways to Learn in Public

Some ways mentioned in the video:

• Writing posts on Twitter or LinkedIn

• Writing blogs on platforms like Hashnode or Medium

• Sharing small learnings, not polished tutorials

The idea is consistency, not perfection.

For Introverts: Start Small

The conversation also touched on introverts and how they can get started.

You don’t need to force yourself into big meetups or conferences immediately.
It’s okay to take things step by step.

Start small:

• Write a short post

• Share a simple thought

• Slowly build confidence

There’s no need to put too much pressure on yourself.

Things That Made Me Think

• Comfort with the camera is becoming an important skill

• Communication matters as much as technical ability

• Growth doesn’t need to be loud or fast

The video made it clear that improvement happens gradually.

My Reflections

One strong takeaway for me was the importance of being comfortable on camera.

If you are comfortable speaking on camera:

• You can join remote meetings confidently

• You can create video content if you want

• You open yourself up to more future opportunities

It’s not about becoming a content creator overnight.
It’s about reducing fear and being open to showing up.

This video made me realise that many future opportunities come from being visible and comfortable expressing yourself.

What I’m Taking Forward

I don’t feel the need to rush anything.

For now, I want to focus on:

• Improving one step at a time

• Being more comfortable communicating

• Sharing my learning honestly, without pressure

This post itself is part of that process.

Reference

• Conversation between Kunal Kushwaha and Francisco

• Topic: Remote jobs and learning in public

I watched this conversation to understand how resumes actually work in the tech industry. I wasn’t looking for templates or formatting tricks. I wanted clarity on how resumes signal value, especially for someone early in their career.

Instead of focusing on design or keywords, the discussion centred on thinking systems, how to observe your work, document it, and translate it into evidence. That perspective made me revisit how I was building my own resume.

Key Learnings

1. Accomplishments matter more than responsibilities

A resume should highlight outcomes, not task lists. Instead of describing what I did, I should show what changed because of my work and what I learned from it.

2. Comparative analysis helps identify the right work

By listing every meaningful experience and separating what I liked from what I didn’t, patterns emerge. These patterns reveal the intersection between my personality and the type of work I should pursue in the future.

3. Maintaining an accomplishment journal is essential

An accomplishment journal helps track:

• Moments of success

• Situations where I worked hard

• New skills I learned

• Instances where I helped or taught others

This makes resume writing concrete instead of relying on memory.

4. Accomplishment journals improve interview readiness

By documenting experiences clearly, I can frame them as stories during interviews. Specific stories are easier to remember and explain than vague claims.

5. Feedback is evidence, not validation

Recording compliments or positive feedback from teachers, peers, or managers helps identify strengths objectively. These entries act as external proof of impact.

6. The logical model clarifies resume bullet points

Each experience can be structured using:

• Resources available

• Activities performed

• Outputs produced

• Outcomes achieved

This approach forces clarity and removes ambiguity from resume content.

7. Resume structure should prioritise clarity over design

For early-career professionals:

• Keep the resume to one page

• Avoid visuals, colours, or decorative elements

• Use margins between 0.5 and 1 inch

• Fill about 80–85% of the page to allow breathing space

Structure and content matter more than appearance.

8. Removing the summary section improves focus

Early in a career, summaries often repeat claims without evidence. Removing them creates space for concrete accomplishments instead.

9. The 50-hour rule defines what belongs on a resume

Any meaningful work done for at least 50 hours (sometimes even 25) is worth mentioning. This includes projects, features built, code reviews, and quality improvements.

10. Reflection matters more than frequent updates

The hardest part of resume building is not writing, it’s remembering. Spending one hour each week reflecting and updating an accomplishment journal solves this problem.

11. Numbers turn effort into evidence

Adding numbers wherever possible transforms normal statements into measurable impact. Numbers make contributions easier to understand and evaluate.

My Reflection

• This video gave me a new perspective on building a resume beyond formatting and templates.

• I understood the importance of maintaining an accomplishment journal to document meaningful work consistently.

• I learned how to structure a resume with a clear focus on layout, visuals, and content, without depending on design elements.

Behind the Scenes

While watching this video, I wrote all my notes in my physical notebook. Writing by hand helps me slow down and think clearly. Later, I convert those raw notes into a structured blog.

This process helps me:

• understand ideas deeply

• reflect on what I learn

• track my progress over time

This is a core part of my Learn in Public journey.

Final Thoughts

This conversation opened a different way to think about resumes, rooted in observation, evidence, and clarity. Instead of chasing perfection in formatting, I learned to focus on documenting meaningful work consistently.

For me, resume building is no longer a one-time task. It’s a habit.

Recently, I watched a conversation between Matt van Itallie and Kunal Kushwaha about utilising open source for career advancement. Matt shared insights from his experience working at a company that builds code quality tools and actively contributes to open source.

At this stage of my journey, I am actively contributing to open source and trying to understand which tech paths suit me best. This video helped me see how open source can be used not just for learning, but also for skill growth, career exploration, and long term direction.

Key Learnings

About Sema

Sema is a company that builds tools to improve code quality and code releases. They work closely with open source projects, where anyone can read the code, copy it, and raise issues. Maintainers review contributions and guide contributors to keep the project healthy.

This shows how companies rely on open source not only to build products, but also to grow strong communities.

What Is Open Source

Open source means software whose code is publicly available. Anyone can:

• view the code

• report issues

• suggest improvements

• contribute changes

This open model allows people across the world to build software together and learn from real systems.

How Contribution Helps

Contributing to open source helps in many ways:

1. Skilling up
   You improve your skills through real code reviews and practical feedback.

2. Mentorship
   You learn from maintainers and experienced contributors who guide you.

3. Resume building
   Your contributions act as proof of work and show what you can actually do.

4. Networking
   You connect with people working in the same domain and build professional relationships.

5. Self exploration
   You can test whether a tech stack or role suits you before committing to it.

This matters because learning through real work is far more effective than only studying theory.

Roadmap for Beginners

A simple roadmap for beginners is:

• Pick one organisation

• Choose an active community

• observe communication for one week

• start with small issues

• move to bigger contributions slowly

This approach helps beginners avoid confusion and build confidence step by step.

How to Contribute and Reach Out to Companies

Instead of asking directly for jobs:

• contribute consistently

• help solve real problems

• show learning through your work

When your contributions create value, companies notice naturally. Conversations start based on trust, not requests.

Five Rules of a Great Contributor

Some important rules to follow are:

• Focus on a few things and do them well

• be consistent

• respect maintainers’ time

• communicate clearly

• be empathetic and helpful

These habits make collaboration smoother and build long-term trust.

Getting Hired

Open source helps with hiring because:

• Your work is visible

• Your contributions show real skills

• Recruiters can see your growth over time

This matters because proof of work builds more trust than resumes alone.

Best Tech Stack to Contribute

There is no single best tech stack. The right stack is one that:

• genuinely interests you

• has active maintainers

• offers beginner-friendly issues

Enjoyment and consistency matter more than choosing a popular stack.

Learn in Public

Learning in public means:

• asking questions openly

• sharing progress

• discussing challenges

This helps others learn and slowly builds your credibility through consistency.

Which Contributions Look Good

Good contributions are:

• consistent

• useful to the project

• well documented

• respectful in communication

Quality matters more than the number of contributions.

My Reflection

My biggest learning from this video is:

• Safe exploration
  Open source allows me to explore whether a particular tech stack or role suits me without long-term commitment.

• Choosing the right organisation
  Selecting an active and supportive organisation matters for learning and growth.

• Good contribution practices
  Following contribution guidelines and asking questions in public channels helps build trust and visibility.

Behind the Scenes

While watching this video, I wrote all my notes in my physical notebook. Writing by hand helps me slow down and think clearly. Later, I convert those raw notes into a structured blog.

This process helps me:

• understand ideas deeply

• reflect on what I learn

• track my progress over time

This is a core part of my Learn in Public journey.

(This is where I add images of my handwritten notes.)

Final Thoughts

Open source is not just about writing code. It helps with learning, networking, career exploration, and building trust.

This conversation reminded me that consistent and thoughtful contributions can quietly shape a strong career over time.

After contributing to Ghost's open-source codebase and learning the process of distributed collaboration, I wanted to explore a different type of project. Zulip caught my attention because of its unique approach to team communication and its well-documented, beginner-friendly contribution process.

What attracted me to Zulip was its thoughtful architecture – a Django backend with modern frontend tooling, comprehensive testing, and a strong focus on code quality. The project felt mature yet welcoming to newcomers.

I picked issue #36689 because it was labelled as a help-wanted issue and involved email notifications – a feature that directly impacts user experience. The problem was clear: empty topics in digest emails were showing raw HTML instead of the expected "general chat" display.

2. Understanding the Problem

The issue affected users receiving email digest notifications when:

• Messages were posted to topics with empty names

• The digest email would display raw HTML like <span class="empty-topic-display">general chat</span>

• Instead of the clean, localised "general chat" text

This created a poor user experience and made Zulip look unprofessional in email clients. The problem occurred specifically in digest emails, not in the web interface, where empty topics displayed correctly.

Expected behaviour: Clean "general chat" text.

Actual behaviour: Raw HTML markup visible to users

3. Reproducing the Issue Locally

I set up my local Zulip development environment following their excellent documentation:

./tools/provision
./tools/run-dev

To reproduce the issue, I:

• Created messages in topics with empty names

• Navigated to http://localhost:9991/digest/ to preview digest emails

• Confirmed the raw HTML was visible in the email preview

• Checked both HTML and plain text versions of the digest

The issue was clearly visible in the digest preview, making it easy to verify the problem and later test the fix.

4. Visual Evidence: Before and After

Before Fix - Raw HTML Displayed

After Fix - Clean Display

The difference is immediately apparent - users now see professional, clean email formatting instead of confusing HTML markup.

5. Tracing the Root Cause

At first, I thought this was a simple templating issue in the email templates. I spent time looking through the digest email templates, expecting to find incorrect HTML escaping.

After reading through the codebase more carefully, I realised the issue was deeper in the email notification logic. The problem was in zerver/lib/email_notifications.py in the digest_block_header function.

The actual root cause was a type annotation issue. The code was creating Markup objects inconsistently:

• For empty topics: using Markup().format() with proper escaping

• For non-empty topics: directly wrapping in Markup() without escaping

This inconsistency meant the type checker couldn't properly validate the code, and the HTML rendering behaved differently for empty vs non-empty topics.

6. The Fix (What I Changed and Why)

I needed to ensure both empty and non-empty topics were created Markup objects consistently while maintaining proper HTML escaping.

The solution was to:

1. Use escape() to safely handle user input for topic names

2. Create Markup objects consistently for both cases

3. Maintain the special styling for empty topics with the CSS class

I chose this approach because:

• It maintains security by properly escaping user input

• It fixes the type annotation issues

• It keeps the existing functionality for empty topic styling

• It's minimal and doesn't change the overall architecture

The key insight was that Markup().format() auto-escapes parameters, but directly wrapping strings in Markup() bypasses escaping – a potential XSS vulnerability.

7. Testing the Fix

I tested the fix thoroughly:

Manual testing:

• Verified digest preview at http://localhost:9991/digest/ displayed correctly

• Checked both HTML and plain text versions

• Tested with various topic names, including edge cases

Automated testing:

./tools/lint --skip=gitlint zerver/lib/email_notifications.py
./tools/test-backend zerver/tests/test_email_notifications.py
./tools/run-mypy

I also added a specific test case test_empty_topic_display_in_digest_email to ensure this regression wouldn't happen again.

Edge cases verified:

• Empty topic names

• Topics with special characters

• Topics with potential HTML content

8. Submitting the Pull Request

I submitted PR #37059 with a clear description following Zulip's guidelines:

• Explained the problem and solution

• Included testing steps

• Referenced the original issue #36689

The PR went through Zulip's automated checks:

• Linting passed

• Type checking passed

• All tests passed

• Security review flagged an initial XSS concern

I quickly addressed the security feedback with a second commit, properly escaping the user input before wrapping it in Markup().

Pull Request Link: https://github.com/zulip/zulip/pull/37059

9. What I Learned

Technical Learnings:

• How Django's Markup class works and its security implications

• The importance of consistent type annotations in large codebases

• Zulip's comprehensive testing approach and tooling

• The difference between auto-escaping and manual escaping in templates

Non-Technical Learnings:

• How to read and understand large, well-organised codebases

• The value of thorough local testing before submitting

• How security-conscious open source projects operate

• The importance of clear, focused commits and PR descriptions

The most valuable lesson was understanding that good open source contributions aren't just about fixing bugs – they're about maintaining code quality, security, and consistency across the entire project.

10. Final Thoughts

This contribution gave me confidence that I can meaningfully contribute to large, complex projects. The Zulip community's focus on mentoring new contributors and maintaining high standards created an excellent learning environment.

I'm excited to continue contributing to Zulip, potentially tackling more complex issues as I become more familiar with the codebase. The experience reinforced that open source contribution is as much about learning and collaboration as it is about coding.

For anyone considering their first Zulip contribution: the documentation is excellent, the community is welcoming, and the codebase is well-organised. Don't hesitate to dive in!

11. Resources

• Zulip Repository: https://github.com/zulip/zulip

• Original Issue: https://github.com/zulip/zulip/issues/36689

• My Pull Request: https://github.com/zulip/zulip/pull/37059

• Zulip Development Documentation: https://zulip.readthedocs.io/en/latest/development/overview.html

• Zulip Contributing Guide: https://github.com/zulip/zulip/blob/main/CONTRIBUTING.md

Setting up Zulip locally is not a typical Django setup.

After contributing to Ghost, I wanted to challenge myself with a larger backend system, one that reflects real-world complexity. Zulip stood out because of its scale, architecture, and active open-source community.

Zulip is built using:

• Django

• Tornado

• PostgreSQL

• RabbitMQ

While the setup process is well-documented, I still faced some issues, especially around Python virtual environments and WSL configuration.

In this post, I’ll walk through:

• How I set up Zulip locally on WSL2

• The issues I faced during setup

• How I fixed them, including the tricky activate_this.py problem

If you’re setting up Zulip for the first time, this guide should save you time and effort.

Who This Post Is For

This post is helpful if you are:

• Contributing to Zulip for the first time

• Moving from smaller projects to large backend systems

• Using WSL2 on Windows

• Facing Python 3.12 or activate_this.py issues during setup

Prerequisites for Zulip Local Setup

Before starting, make sure your system meets these requirements.

General Requirements

• 2GB or more RAM

• Stable internet connection

• GitHub account

Windows Requirements

• Windows 10 or 11 (64-bit)

• Virtualisation enabled (VT-x / AMD-V)

• Administrator access

Git and GitHub Setup

If Git is already configured, you can skip this step.

Generate an SSH key:

ssh-keygen -t ed25519 -C "your_email@example.com"

Copy the public key:

cat ~/.ssh/id_ed25519.pub

Add it to:
GitHub → Settings → SSH and GPG Keys

This allows you to clone Zulip securely.

Setting Up WSL2 for Zulip Development

If you’re already using native Ubuntu or WSL2, you can skip this section.

Enable Virtualization

Enable VT-x / AMD-V in your BIOS.

Install WSL2

wsl --install

This installs Ubuntu automatically.

Use a Fresh WSL Instance

A clean WSL setup helps avoid conflicts with existing Python or Node installations.

Enable systemd (Important)

Zulip relies on system services like PostgreSQL, Redis, and RabbitMQ.

Edit the config file:

sudo nano /etc/wsl.conf

Add:

[boot]
systemd=true

Restart WSL:

wsl --shutdown

Install Required Services

Update your system:

sudo apt update && sudo apt upgrade

Install required services:

sudo apt install rabbitmq-server memcached redis-server postgresql

Configure RabbitMQ

Edit the config file:

sudo nano /etc/rabbitmq/rabbitmq-env.conf

Add:

NODE_IP_ADDRESS=127.0.0.1
NODE_PORT=5672

Important WSL Tips

Use WSL’s Native Disk

Avoid working inside /mnt/c/....

Always work from:

cd ~

Generate SSH Key Inside WSL

ssh-keygen -t ed25519 -C "your_email@example.com"
cat ~/.ssh/id_ed25519.pub

Add this key to GitHub as well.

Cloning the Zulip Repository

Fork Zulip

Go to:
https://github.com/zulip/zulip
Click Fork.

Clone Your Fork

git clone --config pull.rebase git@github.com:YOURUSERNAME/zulip.git
cd zulip
git remote add -f upstream https://github.com/zulip/zulip.git

Running Zulip Locally

Install Dependencies

This step installs all required dependencies and may take 5–10 minutes.

./tools/provision

Activate the Virtual Environment

source .venv/bin/activate

Start the Development Server

./tools/run-dev

Visit:
http://localhost:9991

Common Zulip Setup Issues (and Fixes)

Issue 1: Missing activate_this.py

Error

FileNotFoundError: No such file or directory ... activate_this.py

Why This Happens

Zulip now uses uv, a modern Python package manager.
Unlike virtualenv, it does not automatically create activate_this.py.

Some scripts still expect this file.

Fix

Manually create it:

cat > .venv/bin/activate_this.py << 'EOF'
import os
import site
import sys

bin_dir = os.path.dirname(os.path.abspath(__file__))
os.environ["PATH"] = os.pathsep.join([bin_dir] + os.environ.get("PATH", "").split(os.pathsep))

base = os.path.dirname(bin_dir)
os.environ["VIRTUAL_ENV"] = base

site_packages = os.path.join(base, 'lib', 'python{}.{}'.format(*sys.version_info[:2]), 'site-packages')

prev = set(sys.path)
site.addsitedir(site_packages)
sys.real_prefix = sys.prefix
sys.prefix = base

new = list(sys.path)
sys.path[:] = [i for i in new if i not in prev] + [i for i in new if i in prev]
EOF

Issue 2: Django Not Found (Python 3.12)

Error

ModuleNotFoundError: No module named 'django'

Root Cause

Older scripts used:

sys.version[:3]

With Python 3.12, this incorrectly returns "3.1".

Fix

Use:

'{}.{}'.format(*sys.version_info[:2])

Then re-run:

./tools/provision

Key Learnings from Setting Up Zulip

Technical Learnings

• Modern tools like UV change long-standing Python assumptions

• Understanding virtual environment internals is useful for debugging

• A proper WSL2 + systemd setup is critical for backend services

Soft Learnings

• Large codebases require patience

• Error messages often point to the real issue

• Zulip’s documentation and community are extremely helpful

Conclusion

Moving from Ghost to Zulip has been a rewarding step in my open-source journey.

Zulip’s development environment is complex but well-architected, making it a great project for anyone who wants to grow in backend engineering.

If you’re stuck on setup, especially around activate_this.py you’re not alone. Once the environment is running, contributing becomes much smoother.

Resources

• Zulip GitHub: https://github.com/zulip/zulip

• Dev Setup Docs: https://zulip.readthedocs.io/en/latest/development/overview.html

• Zulip Community: https://chat.zulip.org

• WSL2 Docs: https://docs.microsoft.com/en-us/windows/wsl

• UV Package Manager: https://github.com/astral-sh/uv

Recently, I watched a conversation between Kunal Kushwaha and Matt van Itallie about learning in public for career growth.

This discussion helped me understand what learning in public really means and why it is important in today’s tech careers.

Earlier, I thought learning was something we should do quietly. This video showed me that sharing learning openly can help not only individuals but also entire communities.

Key Learnings

1. Learning in Public Means Sharing Progress

Learning in public means sharing your questions, progress, and learnings openly.
It is not about showing expertise. It is about showing how you are learning step by step.

2. Public Questions Help More People

When you ask a question publicly, many people benefit from it.
Others who have the same question can learn from the answers and discussions.

3. Psychological Safety Is Important

In remote teams and online communities, people should feel safe to ask questions and admit mistakes.
There should be no fear of embarrassment.

If a community is rude to beginners, it is better to leave.
If a community supports beginners, it is a good place to learn and grow.

4. Giving Feedback the Right Way

Feedback should be clear, calm, and useful.
Instead of saying “Good job,” it is better to explain what was done well and why.

The same applies to negative feedback. It should clearly explain the issue and how to improve.

5. Observe Before Giving Feedback

When joining a new community or team, it is good to observe first.
Watch how seniors and leaders communicate before sharing your own feedback.

6. Choosing the Right Community

Very large communities can feel confusing.
Very small communities may not be active.

Medium-sized communities that welcome new members are often the best places to learn.

7. Imposter Syndrome Is Normal

Many people feel imposter syndrome when they start.
No one begins as an expert. Skills and confidence grow with time and practice.

8. Career Benefits of Learning in Public

Learning in public helps build proof of work over time.
Your questions, posts, and contributions show your growth and help build credibility.

My Reflection

My biggest takeaway from this video is that learning in public builds credibility over time, not by being perfect, but by being consistent.

You do not need to know everything before you start sharing.
Showing up regularly and learning openly matter more than trying to look perfect.

Behind the Scenes

While watching this video, I wrote all my notes in my physical notebook, as I usually do.
Later, I converted those raw notes into this blog.

This process helps me:

• think clearly

• remember concepts better

• reflect on what I learned

• track my progress over time

This is an important part of my Learn in Public journey.

Final Thoughts

Learning in public is not about showing off.
It is about learning, sharing, and growing together with the community.

This conversation reminded me that careers grow faster when we learn openly and support each other.

I recently watched a conversation between Kunal Kushwaha and Andy Jeffries, the CTO of Civo. The discussion focused on an important question many people struggle with:

Does having a degree really determine your success in tech?

As someone who didn’t come from a traditional tech background, this topic felt very relevant. The conversation gave me a clearer understanding of how the tech industry looks at skills, education, and real-world ability.

Key Learnings

1. Degree vs Bootcamp—Both Have Value

Andy explained that both degrees and bootcamps play different roles:

• Bootcamps help people coming from non-tech backgrounds learn programming fundamentals quickly.

• Degrees provide a deeper understanding of computer science concepts, which can be helpful in certain roles.

But the main point was:

A degree is useful, but your skills and real work matter more.

2. What Actually Matters in Tech

Companies care less about your background and more about:

• What you can build

• How do you solve problems

• How you communicate

• Your GitHub activity and open-source involvement

If you can do the job well, your degree (or lack of it) becomes much less important.

3. What Companies Look for in Candidates

Andy shared the qualities he looks for when hiring:

• Self-motivation

• Ability to figure things out when stuck

• Clear and honest communication

• How do you discuss issues and solutions publicly

These qualities show how you think and how you work—both are more important than your degree.

4. What You Should Look for in a Company

A good company should offer:

• Growth opportunities

• Impactful work

• International exposure

Where you choose to work can shape your learning and career direction.

My Reflection

This conversation made me reflect on my own journey.

I understood that:

• If you don’t have a degree, your work must speak for you.

• A strong project portfolio or open-source profile creates more value than a certificate.

• Tech changes quickly, so staying curious, consistent, and self-driven is essential.

• The most important thing is your ability to learn and solve problems, not your educational background.

This gives hope to anyone entering tech from a different field.

Final Thoughts

A degree can help. A boot camp can help. But neither defines your future. Your skills, consistency, and problem-solving ability matter far more.

This conversation reminded me that tech is one of the few fields where your work speaks louder than your background. If you stay focused and keep improving, you can build a successful career, no matter where you started.

I built DocBook – a full-featured clinic management system that streamlines healthcare operations for both patients and administrators. The platform offers real-time appointment booking, live queue management, and a comprehensive admin dashboard with emergency case handling.

Role: Full-Stack Developer (solo)
Timeline: 2 weeks
Tech: React 18, TypeScript, Vite, TailwindCSS, shadcn/ui, TanStack Query
Live Demo: https://docbook.abdultalha.tech/
GitHub Repo: https://github.com/abdultalha0862/docbook

The Problem

Managing clinic appointments is often chaotic:

• Patients wait endlessly without knowing their queue position

• No real-time availability for booking slots

• Administrators juggle multiple systems for appointments, patients, and emergencies

• Emergency cases get lost in the regular queue

• No unified dashboard for clinic metrics

I wanted to build a solution that addresses these real healthcare challenges.

The Solution

A modern clinic management platform with real-time queue tracking, instant booking, and separate portals for patients and administrators.

Key Features

For Patients

• Instant Slot Booking – Real-time availability with immediate confirmation

• Live Queue Tracking – Know your exact position with automatic updates

• Doctor Discovery – Browse specialists with ratings and experience

• Emergency Priority Booking – Special handling for urgent medical cases

• Appointment History – Track past and upcoming visits

For Administrators

• Real-Time Dashboard – Live metrics on appointments, doctors, and emergencies

• Queue Management – Control patient flow with status updates

• Patient Database – Comprehensive patient records

• Emergency Handling – Priority workflows for urgent cases

• Appointment Lifecycle Control – Approve, modify, or cancel appointments

Technical Architecture

Frontend Stack

• React 18 + TypeScript: Type-safe, modular components

• Vite: Lightning-fast development and build

• TailwindCSS: Rapid, responsive UI styling

• shadcn/ui + Radix UI: Accessible, modern component library

• TanStack Query: Efficient server state management

Key Engineering Decisions

• Component-Based Architecture: 13 core components + 40+ reusable UI components

• Custom Hooks Pattern: Separated data logic from UI (useAppointments, useDoctors, useDepartments)

• First-Come-First-Serve Queue System: Global counter ensures fair appointment ordering

• Optimistic Updates: Instant UI feedback with background sync

• Separate Portals: Distinct user experiences for patients and admins

Core Implementations

Queue Management System

• Global queue counter for fair appointment ordering

• Real-time status updates (pending → confirmed → in-progress → completed)

• Emergency flag for priority handling

Appointment Booking Flow

1. Patient authentication (sign in/sign up)

2. Doctor selection with speciality filtering

3. Real-time slot availability check

4. Information collection (symptoms, reason, emergency flag)

5. Queue number assignment with instant confirmation

Admin Dashboard

• Live metrics cards showing today's appointments, pending approvals, active doctors, and emergency cases

• Categorised appointment views (pending, in-progress, completed)

• One-click status updates with toast notifications

State Management

• TanStack Query for data fetching and caching

• Query invalidation for real-time updates

• Mutation hooks for optimistic updates

Testing

Developed a comprehensive test suite with Vitest + React Testing Library:

• Component Tests: DoctorCard, AppointmentCard UI testing

• Hook Tests: useAppointments data logic validation

• Integration Tests: Full booking form workflow

• E2E Tests: Complete booking flow simulation

• Utility Tests: Mock data validation

Challenges & Solutions

🔹 Real-time queue position updates
Fix: Implemented query invalidation with TanStack Query for automatic data refresh on status changes.

🔹 Emergency case prioritisation
Fix: Added isEmergency flag with visual indicators and separate admin view sections.

🔹 Managing complex appointment states
Fix: Created typed status enum (pending, confirmed, in-progress, completed, cancelled) with strict state transitions.

🔹 Responsive admin dashboard
Fix: Used CSS Grid with breakpoint-specific layouts (1-col mobile, 2-col tablet, 4-col desktop).

Results

The platform provides a complete clinic management experience with minimal setup.

What I Learned

• TanStack Query simplifies complex data fetching and cache invalidation

• Separate portals improve UX by tailoring interfaces to user roles

• Emergency handling in healthcare apps requires careful visual hierarchy

• shadcn/ui + Radix accelerates development while maintaining accessibility

• Comprehensive testing is essential for healthcare applications where reliability matters

Future Enhancements

• Backend integration with real database (Supabase/PostgreSQL)

• SMS/Email notifications for appointment reminders

• Multi-doctor scheduling with time slot conflicts

• Patient's medical history and records

• Analytics dashboard with appointment trends

• Payment gateway integration

• Mobile app (React Native)

Call To Action (CTA)

If you want to:

• Build a modern healthcare or booking application like this

• Collaborate on open-source projects

• Hire me to create high-performance React applications

Let's connect!

📧 Email: abdul@abdultalha.tech
🌐 Portfolio: https://abdultalha.tech/
💼 LinkedIn: https://www.linkedin.com/in/abdul-talha/
⭐ GitHub: https://github.com/abdultalha0862

If you found this project interesting,
⭐ Star the repository on GitHub, it genuinely helps!

Recently, I watched a conversation between Kunal Kushwaha and Sanskar Jethi about his journey from open source contributions to securing an off-campus role at Bloomberg London. The discussion was simple, honest, and packed with practical insights for developers like me who are growing through open source.

Key Learnings

1. Open Source Is Collaboration, Not Competition

Sanskar emphasised that open source is about working together.
There is no scoreboard, no race, and no rivalry.
It’s a collaborative space where developers from different backgrounds unite to solve problems and build something meaningful for the community.

2. Impact Comes From Projects Used by Real People

The value of your work increases when it reaches real users.
Sanskar highlighted the importance of contributing to projects that people rely on globally.
Such projects not only sharpen your skills but also give you visible proof of real-world impact.

My Reflection

This conversation helped me understand that open source is more than just code—it’s a mindset.
Focusing on collaboration, community, and meaningful contributions matters far more than competing for visibility.
This shift in perspective motivates me to contribute consistently and work on projects that help real users.

Final Thoughts

Thanks to Kunal and Sanskar for sharing such actionable insights. Their conversation is a reminder that open source can open doors—not just to jobs, but to growth, learning, and impact.

I built a fully client-side GitHub Profile README Generator to make it easy for developers to create beautiful GitHub profiles without manually writing markdown. The tool includes live preview, categorised skills, export options, and an intuitive form-based editor.

Role: Full-Stack Developer (solo)
Timeline: 1 week
Tech: React 18, TypeScript, Vite, TailwindCSS, shadcn/ui
Live Demo: https://readmegen.abdultalha.tech/
Github Repo: https://github.com/abdultalha0862/github-readme-generator

The Problem

Creating a standout GitHub profile is surprisingly tedious:

• Writing and formatting markdown manually

• Finding icons and GitHub stats widgets

• No instant preview

• No structured way to organise skills or projects

I wanted a tool that solves these real frustrations for developers.

The Solution

A visual GitHub Profile README Generator with real-time preview and multi-format export.

Key Features

• 6 Content Sections: Basic info, Work, Skills (200+), Stats, Contact, Projects

• Live Markdown Preview: See changes instantly

• 4 Export Formats: Markdown, HTML, PDF, Text

• Auto-Save: Saves progress every 3 seconds

• Skill Icon Library: 200+ technology icons across 10 categories

Technical Architecture

Frontend Stack

• React + TypeScript: Strong typing and modular components

• Vite: Lightning-fast dev environment

• shadcn/ui + Radix: Accessible, modern UI components

• TailwindCSS: Rapid UI styling

Key Engineering Decisions

• 100% client-side (no backend or server costs)

• LocalStorage persistence

• Memoised preview for smooth performance

• Export pipeline built for Markdown → HTML → PDF

Core Implementations

Real-Time Preview

Optimized with useMemo, useCallback, and controlled components.

Skill Categorisation

200+ skills grouped into 10 categories with Devicons CDN for reliable icons.

Export System

• Markdown generator

• HTML template

• PDF via jsPDF (HTML → PDF)

• Clean TXT export

Auto-Save

Saved every 3 seconds using LocalStorage with error handling.

Testing

Developed a robust test suite with Vitest + React Testing Library:

• Unit tests for generators

• Component tests for forms and preview

• Integration tests for the full edit → preview → export workflow

Challenges & Solutions

🔹 Performance with large content

Fix: Memoisation + debouncing + component splitting.

🔹 PDF formatting issues

Fix: Convert markdown → HTML → jsPDF to maintain structure.

🔹 Icon management for 200+ skills

Fix: Dynamic icon mapping with fallback URLs and caching.

Results

Users reported saving 20–30 minutes compared to manual README creation.

What I Learned

• High-performance React apps require strategic memoisation

• Tailwind + shadcn/ui accelerates UI development without losing control

• File export pipelines require careful formatting

• Tests are essential for confidently adding new features

Future Enhancements

• One-click templates

• Undo/redo

• Import existing README

• Advanced theming

• AI-powered content suggestions

• GitHub API integration for direct publishing

Call To Action (CTA)

If you want to:

• build a modern React application like this,

• collaborate on open-source developer tools,

• or hire me to create high-performance front-end experiences…

Let’s connect!

📧 Email: abdul@abdultalha.tech
🌐 Portfolio: https://abdultalha.tech/
💼 LinkedIn: https://www.linkedin.com/in/abdul-talha/
⭐ GitHub: https://github.com/abdultalha0862

If you found this project interesting,
⭐ Star the repository on GitHub — it genuinely helps!

As I continue exploring the world of open source and tech, I watched another helpful video, this time a discussion between Kunal Kushwaha and Logan Kilpatrick. I have been trying to understand open source more clearly, and this conversation gave me exactly the clarity I needed. They talked about GSoC (Google Summer of Code), how it works, and why it is such a great opportunity for learners and contributors. It felt like listening to two people sharing genuine insights from their own experience because Kunal cracked GSoC three times and Logan has mentored in GSOC.

Key Learnings

1. What is Open Source?

Open source simply means companies publicly share their code on GitHub. Anyone from anywhere in the world can look at the code and contribute to it. One point that really stayed with me is how contributions build your proof of work on GitHub. Everything you do stays on your profile, showing your journey and skills.

2. What is GSoC?

GSoC is a platform where organisations, mentors and students work together. It is not just a program, but a place where beginners get guidance while contributing to real projects. This explanation made GSoC feel more accessible and welcoming.

3. GSoC Timeline

I learned that the GSoC timeline can change each year. Because of this, it is important to keep checking the official website for updated dates and announcements.

4. Tips to Start Contributing

They shared some very practical tips that made the process feel less overwhelming:

• Check if your chosen organisation is participating in GSoC.

• Explore their projects and documentation.

• Go through the codebase to understand how things work.

• Start with good first issues and then move on to more complex issues.

This advice felt simple and realistic, especially for someone just starting.

5. Importance of Collaboration

One thing they highlighted strongly is that GSoC is not a competition. It is a collaborative environment where developers from different parts of the world work together. This idea of learning and contributing as a team is one of the core values of open source.

6. Tips for Proposal

If you have even a few contributions to open source, it already gives you a big advantage.
Your proposal should clearly explain why you are interested in that particular project and why you believe you are a good fit for the organisation.

7. If You Don’t Get Selected

GSoC has limited slots, so not everyone gets selected. But your contributions still stay on your GitHub profile. And if you keep contributing until next year, your chances of getting selected increase a lot. This part was very encouraging and reminded me that the effort itself is valuable.

My Reflection

After watching the video, I felt like I had a clear understanding of the entire GSoC process. I understood what open source really means, why the timeline matters and how contributions can help build a strong profile. The biggest takeaway for me was that collaboration is more important than competition. Even if I don’t get selected, the contributions I make will remain on my GitHub profile and continue to represent my work.

Final Thoughts

This conversation between Kunal Kushwaha and Logan Kilpatrick helped me see GSoC as more than just a program. It is a journey of learning, contributing and collaborating with the community. Watching this video motivated me to explore more, contribute more and continue growing in the open source world.

Recently, I watched a conversation between Kunal Kushwaha and Alex about DevOps, open source, and how people land remote jobs through their contributions. I documented everything in my physical notebook first and later converted it into this blog. This discussion gave me clarity on the role of open source, communities, learning styles, and the structure behind real-world contributions.

Key Learnings

1. How Open Source Helps

Open source isn’t just about sending pull requests; it’s a way to showcase real proof of work.
By maintaining repositories, writing clear READMEs, and contributing consistently, anyone (including a hiring manager) can see:

• your thought process

• the quality of your work

• The impact of your contributions

Open source becomes a living portfolio. Instead of telling people what you know, you show them.

2. How to Learn Anything New

Everyone has their own learning style, videos, blogs, docs, building, or hands-on experimenting.
The important part is:

• start small

• try things on your own

• document what you learn

• avoid getting stuck in endless tutorials

Hands-on practice + project-based learning always works better than passively consuming content.

3. Downsides of Open Source

Open source is powerful, but it also has challenges:

• Maintainers receive huge numbers of PRs and must push hard to review them.

• There is a strict structure behind contributing, reviewing, and merging code.

• Beginners often underestimate the workflow and feel discouraged when PRs are rejected.

But these challenges are part of the learning curve, and they teach how real engineering teams work.

My Reflection

This video reminded me of the importance of communities. As a full-stack developer, I realised I need to find and actively engage with communities related to my field. Participation brings clarity—once you show up, you slowly understand how things work.

I also learned the value of maintaining a proper README or learning file. When I document my learning clearly, it shows my thinking, progress, and structure something that matters to both open-source maintainers and recruiters.

Behind the Scenes: My Raw Notes

Before writing this blog, I captured everything in my physical notebook while watching the video.
Converting raw handwritten thoughts into structured content helps me:

• remember concepts better

• reflect deeply

• write with clarity

• avoid losing ideas

This “raw first, polish later” process makes my learning more intentional and helps me stay consistent.

Final Thoughts

This conversation helped me understand that open source is not only about contributing code, but it is also a pathway to remote work, community building, structured learning, and showcasing your real abilities.

It taught me to stay consistent, document my growth, and be active in communities that align with my goals. The journey is long, but with the right process, it becomes meaningful.

In today's job market, recruiters are drowning in resumes. A recent freelance client was spending 16+ hours every week on a single manual task: sifting through 500+ resumes. The process was slow, error-prone, and a massive bottleneck.

To solve this, I built a high-performance parsing solution that transformed their workflow. By leveraging Python's multiprocessing library, I built a tool that cut a 4-hour task down to 20 seconds.

This post is a technical deep-dive into how I built it, the challenges of real-world file parsing, and the lessons I learned.

The Challenge

The client needed a system that could:

• Process large volumes of resumes in multiple formats (PDF, DOC, DOCX)

• Extract and analyse text content efficiently

• Score resumes based on relevant keywords

• Identify top candidates quickly

• Handle the workload with optimal performance

Technical Architecture

Technology Stack

I chose Python for this project due to its robust ecosystem of libraries:

• PyPDF2: For extracting text from PDF files

• python-docx: For processing Word documents

• Multiprocessing: To leverage multiple CPU cores for parallel processing

Core Components

The solution consists of three main functional components:

1. Text Extraction Engine

The system handles two primary document formats:

Python

# PDF extraction
def extract_text_from_pdf(pdf_path):
    pass

# DOCX extraction  
def extract_text_from_docx(docx_path):
    pass

Each extractor includes comprehensive error handling to ensure the system doesn't crash when encountering corrupted or malformed files.

2. Keyword Matching Algorithm

The scoring system evaluates resumes based on the presence and frequency of required keywords:

• Case-insensitive matching for flexibility

• Frequency counting for better ranking

• Detailed reporting of matched terms

• Configurable keyword lists for different job roles

3. Parallel Processing Pipeline

The most critical performance feature is the parallel processing implementation:

Python

from multiprocessing import Pool


with Pool() as pool:
    results = pool.starmap(process_resume, [(resume_file, keywords) 
                                           for resume_file in resume_files])

This approach distributes resume processing across multiple CPU cores, dramatically reducing processing time.

Key Features

1. Multi-Format Support

The system seamlessly handles PDF, DOC, and DOCX files, ensuring compatibility with the most common resume formats.

2. Intelligent Scoring

Resumes are scored based on both the presence and frequency of keywords, providing a nuanced ranking system.

3. Top Candidate Identification

The system automatically identifies and presents the top 5 candidates, streamlining the initial screening process.

4. Performance Optimisation

By leveraging multiprocessing, the system can process hundreds of resumes in seconds rather than minutes.

5. Detailed Match Reporting

For each top candidate, the system shows exactly which keywords were matched and how many times, providing transparency in the ranking process.

Challenges and Solutions

Challenge 1: Handling Various Document Formats

Problem: Resumes come in different formats with varying structures and encoding.

Solution: Implemented separate extraction functions for each format with robust error handling. Files that can't be processed are skipped gracefully without disrupting the entire workflow.

Challenge 2: Performance with Large Resume Batches

Problem: Sequential processing of hundreds of resumes was too slow for practical use.

Solution: Implemented Python's multiprocessing Pool to distribute workload across CPU cores. This resulted in approximately 3-4x performance improvement on a quad-core system.

Challenge 3: Accurate Keyword Matching

Problem: Keyword matching needed to be flexible enough to catch variations but precise enough to avoid false positives.

Solution: Used case-insensitive matching and counted keyword frequency to provide a more nuanced scoring system.

Performance Metrics

The system demonstrates impressive performance characteristics:

• Processing Speed: Handles 100+ resumes in under 10 seconds (depending on hardware)

• Accuracy: Case-insensitive matching ensures relevant candidates aren't missed

• Scalability: Linear scalability with additional CPU cores

• Reliability: Error handling ensures individual file failures don't crash the system

Lessons Learned

1. Multiprocessing is Powerful but Requires Care

While multiprocessing significantly improved performance, it required careful consideration of:

• Picklable objects (what can be passed between processes)

• Resource management (proper pool cleanup)

• Error propagation between processes

2. Real-World Resume Parsing is Messy

Unlike clean test data, real resumes have:

• Inconsistent formatting

• Various encoding schemes

• Occasional corruption

• Complex layouts with tables and graphics

Robust error handling is essential.

3. Simple Solutions Can Be Effective

While advanced NLP techniques exist, a well-implemented keyword matching system proved sufficient for the client's needs. Don't over-engineer when simpler solutions work.

Potential Enhancements

While the current system meets the client's requirements, here are some potential future improvements:

1. Machine Learning Integration: Implement ML models for semantic matching beyond simple keywords

2. Skills Extraction: Automatically identify and categorise skills, experience levels, and qualifications

3. Web Interface: Add a user-friendly GUI for non-technical users

4. Database Integration: Store results for historical analysis and tracking

5. Custom Weighting: Allow different keywords to have different importance levels

6. Fuzzy Matching: Handle typos and variations in keyword spelling

Conclusion

This project demonstrates how Python's ecosystem and multiprocessing capabilities can create practical, high-performance solutions for real-world business challenges. By focusing on clean code, proper error handling, and performance optimisation, we delivered a tool that significantly improves the resume screening process.

The key takeaway? Sometimes the best solution isn't the most complex one. By leveraging the right tools (PyPDF2, python-docx, multiprocessing) and focusing on the actual requirements, we created an effective system that saves hours of manual work.

Technical Specifications

• Language: Python 3.9

• Dependencies: PyPDF2, python-docx

• Architecture: Parallel processing with multiprocessing Pool

• Supported Formats: PDF, DOC, DOCX

• Performance: O(n/c) where n = number of resumes, c = number of CPU cores

I recently watched a conversation between Kunal Kushwaha and Eddie Jaoude titled “Travel the World While Freelancing.”

It completely changed how I view freelancing and open source. I used to think of open source mainly as a way to learn and collaborate, but now I see it as a gateway to real-world opportunities and proof of work that clients can trust.

Key Learnings

1. Start freelancing through open source.
   It’s the best way to showcase your skills and demonstrate your ability to solve real problems, something clients value highly.

2. Freelancing vs full-time jobs.
   Both have pros and cons. Freelancing offers flexibility, but sometimes you might have no clients, so having a backup option helps.

3. Build in public.
   Sharing what you learn, create, or struggle with attracts visibility and builds trust in your work.

4. Experiment with both paths.
   Try freelancing and full-time work to see which aligns best with your goals and lifestyle.

My Reflection

As an open-source contributor at Ghost, I have seen firsthand how contributing to projects helps build credibility. Clients and companies see open-source work as real proof that you can deliver.

I realised that open source not only opens doors for job opportunities but also for freelancing gigs. By consistently contributing, I am not just learning, I am also building a track record of practical experience that speaks for itself.

Final Thoughts

This conversation reminded me that success doesn’t come from choosing one path; it comes from exploring both. I plan to experiment with freelancing and full-time roles to find what fits me best.

A huge thanks to Kunal Kushwaha and Eddie Jaoude for sharing these valuable insights.

Contributing to Ghost CMS has been a great learning experience for me. I started with small fixes, and now I have a better understanding of how good design and accessibility improve user experiences.

So far, I have solved three issues: #25050, #24608, and #24706. Each one has taught me more about Ghost’s Ember.js frontend, user interface consistency, and working in open-source projects.

In my fourth contribution, #25304, I addressed an important accessibility issue in the email preview. What appeared to be a simple scrollbar bug turned out to be a practical lesson in focus management, keyboard navigation, and inclusive design.

Understanding the Problem

When I first looked at issue #25304, it seemed simple: the email preview in Ghost’s post editor didn’t show a visible scrollbar.
But as I investigated further, I realised this was more than a visual problem; it was an accessibility issue. Without a scrollbar, users who depend on keyboard navigation or two-button mice couldn't scroll through long email previews.

I tested the issue locally and confirmed that:

• The CSS was hiding the scrollbar.

• The iframe couldn’t be focused using the keyboard.

• Arrow keys, Page Up/Down, and Tab navigation didn’t work.

This was a small UX gap but had a big impact, especially for users who depend on accessible navigation.

So, I decided to review the email preview component in the Ember.js admin frontend to find out why this was happening and how to fix it.

My Thought Process

I started by learning how the email preview works. Since Ghost’s admin panel uses Ember.js, I found the component that shows the preview modal.

I searched the code and located the relevant files at:

• ghost/admin/app/components/editor/modals/preview/email.js

• ghost/admin/app/components/editor/modals/preview/email.hbs

Next, I used the browser’s DevTools to check the iframe. I noticed something important: the scrollbar was hidden by CSS:

html::-webkit-scrollbar {
    display: none;
}
html {
    scrollbar-width: none;
}

This explained why the scrollbar was not visible. However, there was more to the problem: even when using a mouse wheel, the iframe could not be focused, which meant keyboard users couldn’t scroll at all.

I had a clear conclusion: The issue was not just about styling; it was also about focus management and accessibility.

I decided to fix the problem in three steps:

1. Allow scrollbars to show again.

2. Make the iframe keyboard-focusable.

3. Manage focus properly when users tab into the preview area.

This plan gave me a clear direction; a small UI change could greatly improve accessibility and usability.

The Fix

I focused on improving the email preview to make it easier to use and accessible. I made three key changes that had a big impact.

1. Make Scrollbars Visible Again

The original code hides the scrollbar completely. I changed it so the scrollbar shows when there is too much content for the screen:

const INJECTED_CSS = `
html,
body {
    overflow-y: auto;
}
`;

Now, users can see the scrollbar whenever needed, making it clear that they can scroll.

2. Make the Iframe Keyboard-Focusable

Next, I ensured users can navigate to the iframe using the keyboard by adding a tabindex:

<iframe
    class="gh-pe-iframe"
    title="Email preview"
    tabindex="0"
    sandbox="allow-same-origin allow-popups allow-popups-to-escape-sandbox"
    {{did-insert this.renderEmailPreview}}
    {{did-update this.renderEmailPreview @memberSegment}}
    {{on "focusin" this.focusPreviewFrame}}
></iframe>

This change allows users to tab into the preview and use the arrow keys or Page Up/Down to scroll.

3. Manage Focus Inside the Iframe

Finally, I ensured the iframe’s body could receive focus, not just the iframe itself. This is where keyboard navigation works best.

@action
focusPreviewFrame(event) {
    const iframe = event?.target;
    try {
        const body = iframe.contentDocument?.body;
        if (body && !body.hasAttribute('tabindex')) {
            body.setAttribute('tabindex', '-1');
        }
        body?.focus({preventScroll: true});
    } catch {
        iframe.contentWindow?.focus();
    }
}

This change allowed keyboard events to be handled correctly and scrolling to work smoothly.

After making these changes, the email preview modal is now fully scrollable, accessible with a keyboard, and easy to see. This small fix made Ghost’s editor more inclusive and enjoyable to use.

Testing and Verification

After making the fix, I wanted to ensure it improved the experience in real use. I ran Ghost in development mode and launched the email preview. This time, I quickly noticed the difference:

✅ The scrollbar appeared when needed.
✅ I could focus on the iframe using the Tab key.
✅ The arrow keys, Page Up/Down, and Space/Shift+Space scrolled smoothly.
✅ The mouse wheel and scrollbar dragging worked perfectly.

To prevent any future issues, I added a test that checks if the iframe has tabindex="0" and that its body gets focus correctly. This way, upcoming updates won’t undo the accessibility fix.

All tests passed, and the UI worked consistently across different browsers.

This testing reminded me how important it is to check real behaviour, not just the code. Accessibility fixes matter when they help someone use the product more comfortably.

Submitting the Pull Request

After confirming that the fix worked and all tests passed, I submitted a pull request to Ghost’s main branch: Pull Request #25334

The pull request included:

• Visible scrollbars in the email preview.

• Added tabindex="0" to the iframe for keyboard access.

• A focus handler to ensure the iframe body receives focus.

• An acceptance test to prevent future issues.

Impact and Lessons Learned

This contribution showed me that even small improvements in accessibility can make a big difference. By fixing the email preview scrollbar and improving keyboard navigation:

• Keyboard-only users can navigate and scroll email previews easily.

• Mouse users can drag scrollbars instead of just using the wheel.

• All users benefit from a clearer and more predictable interface.

Working on this issue also reinforced the importance of patience, attention to detail, and clear communication in open-source projects. Accessibility isn’t just a feature; it’s about making software usable for everyone.

Contributing to Ghost has been a rewarding experience. I look forward to making the platform more inclusive and user-friendly.

After Screenshot

Here’s the updated email preview with the scrollbar and keyboard accessibility:

Resources

• Ghost Contributing Guide

• Ember.js Documentation

• WebAIM: Keyboard Accessibility

• MDN: Focus Management

• WCAG 2.1 Guidelines

I recently watched a YouTube video of Kunal Kushwaha talking with Magali Malkin, a recruiter from Google. This conversation changed how I view the interview and hiring process.

Before this, I thought getting shortlisted for a job depended only on having a great resume or on sharing success stories during interviews. However, I learned that many factors matter, from resume formatting and timing of applications to communication during the hiring process and handling interview failures.

Key Learnings

1. How Resumes Get Shortlisted

• The resume must be well-formatted and include the skills listed in the job description.

• Apply early to increase your chances of being noticed.

• Avoid using too many infographics. Choose a simple format that highlights your relevant skills, making it easier for recruiters to focus on what’s important.

2. What Happens After the Resume Is Shortlisted

• Once a resume is shortlisted, a long process usually follows. This typically includes a DSA round, a technical round, and an HR round.

• Keep in touch with the recruiter and show genuine interest in the role. This reflects professionalism and enthusiasm.

3. How to Frame Answers: The STAR Format

• Use the STAR format to structure your interview answers:

  • S (Situation): Clearly explain the situation.

  • T (Task): Describe the task or challenge you had.

  • A (Action): Explain the action you took.

  • R (Result): Share the result.

• It's okay if the result is not positive. What matters is explaining what you learned from the experience.

4. Importance of Referrals and Networking

• Networking is powerful. Building relationships in the industry can help you get referrals.

• Referred candidates often receive more attention, and their process tends to be quicker. Connect with professionals, build genuine relationships, and don’t hesitate to ask for referrals.

5. Setting Priorities Instead of Aiming for One Company

• Don’t focus on just one company. Instead, determine what matters most to you in a workplace, such as culture, learning opportunities, or job type.

• This focus helps you find the right fit instead of just chasing a big name.

• Remember, fear of failure and rejection are part of the process. Each rejection teaches you something new and helps you grow.

My Reflection

I realised I had some misconceptions about interviews. I thought I should only share success stories, but now I know it’s okay to discuss failures as long as I explain what I learned. I also used to have a dream company in mind, but now I want to focus on what I want from a company and find one that aligns with my goals.

Final Thoughts

The conversation between Kunal Kushwaha and Magali Malkin taught me more than just interview tips. It helped me see the process differently. A good resume doesn’t need to be fancy; it should be clear and relevant. Interview answers don’t always need a positive ending; honesty and learning are more important. Networking is about creating real connections, not just asking for favours. And remember, rejections aren’t failures; they’re lessons that prepare you for the next opportunity.

I will apply these lessons as I move forward, staying genuine, curious, and open to learning from every experience.

If this story resonates with you, share it with others preparing for interviews. A good conversation can change how we view our career journey.

Ghost is an open-source headless CMS built with Node.js, trusted by creators and publishers worldwide.

After resolving two earlier issues (#24608 on dark mode transitions and #24706 on spinner alignment), I felt ready to tackle something more challenging. That’s when I came across Issue #25020:

“Tag disappears from dropdown after removal.”

It sounded simple, but JavaScript had other plans. This post is a breakdown of how I investigated, fixed, and learned from a subtle UI bug that made tags vanish from the editor like magic.

2. Reproducing the Issue

“When you remove a tag while the dropdown is open, it disappears and doesn’t return until the editor is closed.”

To confirm, I set up Ghost locally and followed these steps:

1. Create a new post.

2. Open Post Settings → Tags.

3. Click inside the tags input field to open the dropdown.

4. Select a tag, say News.

5. Without closing the dropdown, remove News.

Just as described, News vanished. It didn’t reappear until I closed and reopened the editor. That’s definitely not expected behaviour.

3. Root Cause

My first thought was that this wasn’t a backend issue since the tags still existed in the database. It had to be a frontend problem, most likely in Ember’s tag management component. A quick search led me to the file:
ghost/admin/app/components/gh-tags-token-input.js

Inside, I found this snippet:

get availableTags() {
    const selectedTags = this.args.selected || [];
    const selectedSet = new Set(selectedTags);
    return this._initialTags.filter(tag => !selectedSet.has(tag));
}

It looked fine at first. Take the selected tags, store them in a Set, and filter them out from the dropdown list. But something was not right.

JavaScript compares objects by reference, not by value. That means:

const tag1 = {id: '5', name: 'News'};
const tag2 = {id: '5', name: 'News'};

tag1 === tag2; // false

They look identical but are stored differently in memory. Ghost was creating new tag objects each time a user interacted with them. So when Set.has(tag) it ran, it compared two different object references even though both represented the same tag.

Result: Ghost thought the tag was still selected and kept it filtered out.

4. The Fix

Once I pinpointed the issue, the fix was simple. Instead of comparing entire objects, I compared tag IDs, which are unique and constant across references.

Before:

const selectedSet = new Set(selectedTags);
return this._initialTags.filter(tag => !selectedSet.has(tag));

After:

const selectedTagIds = new Set(selectedTags.map(tag => tag.id));
return this._initialTags.filter(tag => !selectedTagIds.has(tag.id));

Just two lines changed, and the disappearing tags were gone for good.

5. Testing the Solution

I reloaded Ghost, repeatedly adding and removing tags: “News,” “Tech,” and “Updates.”
This time, every tag reappeared instantly in the dropdown. No more vanishing act.

Then I ran:

yarn lint:js app/components/gh-tags-token-input.js

✅ No errors.

Followed by:

yarn test:unit --grep="tag"

✅ All tests passed.

The fix was stable, isolated, and ready for a pull request.

6. Pull Request

I created PR #25262 with the following commit:

🐛 Fixed tag disappearing from dropdown after removal
fixes https://github.com/TryGhost/Ghost/issues/25020

Description:
When editing a post, removing a tag while the dropdown was open caused it to disappear from available options. This happened because Set was comparing object references instead of tag IDs. Fixed by comparing tag IDs instead.

A clear, minimal, and descriptive PR just the way Ghost prefers.

7. Lessons Learned

1. Reference vs. Value Equality
   I’d read about it before, but seeing it break real code made it stick. Objects are compared by reference, primitives by value.

2. Simple Fixes Can Have Big Impact
   It wasn’t a critical bug, but it noticeably improved the editor’s user experience.

3. Each Contribution Builds Confidence
   My previous Ghost fixes helped me debug and navigate much faster this time.

4. Always Reproduce Before You Fix
   Seeing the bug in action provides context no stack trace can match.

8. Final Thoughts

This was my third contribution to Ghost, the open-source CMS led by John O'Nolan and Hannah Wolfe. Each fix has deepened my understanding of modern web systems:

• #24608 UI transitions

• #24706 State and layout consistency

• #25020 Object identity and equality

Open source is about learning by doing. Every fix teaches something you can’t get from a tutorial. Somewhere, a writer removed a tag and didn’t have to reload their editor, and that tiny moment of smoothness made it worth it.

9. Resources

• Ghost GitHub Repository

• Issue #25020

• Pull Request #25262

• MDN: Set.prototype.has()

• Ghost Contributing Guidelines

• Previous Fixes: #24608 and #24706

Found this helpful? Let’s connect on GitHub or here on LinkedIn. I love sharing what I learn while building real things.

I recently watched a YouTube video by Brian Schuster and Kunal Kushwaha from IBM discussing their tech journey. He demonstrated how he viewed change as an opportunity for learning and growth. His experience teaches us that it’s never too late to start over if you have curiosity and the right mindset.

Key Learnings

1. Brian’s Journey

Brian explained how he transitioned into tech after attending a boot camp. He learned Python and used his family business experience for roles like Business Analyst and Data Analyst. He eventually became a Cloud Engineer (DevOps) at IBM and began mentoring others who wanted to make similar transitions.

2. How to Know if Tech Is for You

The best way to find out is to try it. If you don’t enjoy it, it's okay to switch to another field. Work on hands-on projects, contribute to open-source, or attend hackathons. If it excites you, keep going. If not, you’ll still gain valuable skills.

3. How to Get Your First Role in Tech

Stay open-minded and eager to learn. You don’t need to know everything at the start. Growth comes from real work experience. Be patient.

4. How to Decide if It's Time to Move On

If you stop growing or if the company culture doesn’t match your values, consider exploring new opportunities. Your career should help you grow, both professionally and personally.

5. How to Change Careers if You're Already Experienced

If you have experience in another field, show your skills through evidence:

1. Write blogs

2. Build projects

3. Contribute to open-source communities

These examples say more than your past job titles.

6. How to Approach the Job Market

Focus on one field and create a strong portfolio that includes:

1. Blogs about what you learn

2. Projects you’ve built

3. LinkedIn posts showing your progress

Don’t hesitate to ask for referrals. The tech community is often supportive.

My Reflection

From this talk, I learned it’s never too late to switch if your current path isn’t right for you. Change doesn’t mean failure; it means growth. I also recognised the importance of asking for referrals, building connections, and sharing your progress. The key is to keep learning, experimenting, and adapting.

Final Thoughts

Brian’s story shows that transitioning into tech isn’t just about learning tools or coding languages. It’s about resilience, curiosity, and ongoing learning. No matter where you start, your journey is valid as long as you keep moving forward. Thanks to Brian Schuster for sharing his insights. This talk reminded me that tech welcomes everyone willing to learn.

What are some other lesser-known roles in tech that more people should explore?