DEV Community: Hemapriya Kanagala

🐾 DEV Pet Corner #2: Show Us Your Pets!

Hemapriya Kanagala — Sun, 18 Oct 2026 13:48:11 +0000

TL;DR

DEV Pet Corner is back for another Sunday! It's a weekly series where we take a little break from tech and share our love for animals.

Share pictures, stories, and memories of your pets, animals you've met, or adorable animals you follow online. Share as many pictures and links as you'd like! You don't need to own a pet to join in. If animals make you smile, you're welcome here ❤️

❤️ Thank you for the love
🐶 Show us your animal friends!
🐾 See you next Sunday!

❤️ Thank you for the love!

Hey everyone 👋 It's Sunday again, and DEV Pet Corner is back for its second edition!

First of all, thank you so much to everyone who joined the first edition ❤️ I got to see so many cuties, and I loved going through your comments and meeting all your pets. Some of you also shared memories of pets you've lost, and it meant a lot that you felt comfortable sharing those memories here.

I started this series as a little Sunday break from our usual tech discussions, and seeing everyone join in made me so happy! Getting to spend some time looking at all these adorable animals before getting back to work made my Sunday a little more special.

Thank you for taking the time to share your pics and a little piece of your lives with us. I honestly didn't expect the first edition to turn out this lovely, and I'm so happy I started this!

If you missed meeting all the cuties from the first edition, you can still check it out here -> DEV Pet Corner #1

Now, let's do this again 😄

🐶 Show us your animal friends!

I'd love to see your pets, whether they're the ones waiting for you at home, the ones you grew up with, or the ones who have a special place in your heart.

And you don't need to have a pet of your own to join in! Maybe you've met a friendly dog on a walk, spotted a cat in your neighborhood, or come across an animal on campus that made you stop for a moment. Perhaps you follow an adorable animal account on Instagram or have a favorite animal video you keep going back to.

If it involves an animal you love or something that makes you smile, I'd love to see it 😃

Share pictures, funny moments, sweet memories, little stories, or links to your favorite animal posts. Share as many pictures as you'd like. There's no limit!

If you're sharing someone else's content, please link to the original post and respect the creator's wishes about sharing their work.

A little note for returning readers: You might notice this section looks familiar 😄 I'll keep it in future editions, too, so new readers can easily see what they can share without going back to previous posts. As always, feel free to join in with anything you'd like or simply enjoy all the cuteness in the comments!

🐾 See you next Sunday!

I'm so happy I finally started this little series, and your response to the first edition made me even happier that I did ❤️

As always, let's keep the comments friendly and welcoming to everyone. I'm looking forward to seeing your animal friends and enjoying all the cuteness with you!

Thank you for being here. See you next Sunday for DEV Pet Corner #3!

Dev Opportunity Radar #21: $500K Y Combinator Funding, Bolt Builders Week, and AI Safety Research Residency

Hemapriya Kanagala — Fri, 16 Oct 2026 17:40:16 +0000

TL;DR

Welcome back to Dev Opportunity Radar!

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features the MATS Residency for AI safety research, Bolt Builders Week, and applications for Y Combinator's Winter 2027 Batch. I'm also sharing roadmap.sh, a resource with interactive roadmaps and learning materials to help developers figure out what to learn next.

If you're new to the series, you can browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

If you've discovered something through the Radar, I'd love to hear about it. Whether you applied to an opportunity, joined a community, completed a program, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section, with your permission.

And if you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature one of your Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan
🔄 Still Open From Previous Editions
📍 This Week's Opportunities
- 📌 MATS Residency: AI Safety Research
- 📌 Bolt Builders Week
- 📌 Y Combinator Winter 2027 Batch
📚 Resources Worth Checking Out
- roadmap.sh: Developer Roadmaps and Learning Resources
🌟 Community Finds
💙 Reader Updates
👋 Until Next Friday
🌐 Dev Opportunity Radar Website

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Location / Format	Deadline
MATS Residency: AI Safety Research	MATS	Research Residency	Hybrid (London, Berkeley, Washington, DC)	October 31, 2026 (AoE)
Bolt Builders Week	Bolt	Build Event & Business Contest	Online	October 20, 2026 (Contest)
Y Combinator Winter 2027 Batch	Y Combinator	Startup Accelerator & Funding	In-person (San Francisco, USA)	November 2, 2026

Resource Highlight

Resource	Why Check It Out
roadmap.sh	Community-driven, interactive roadmaps and learning resources covering developer roles and technologies, along with best practices and questions to test your knowledge.

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

As the Radar has grown, there are now quite a few opportunities spread across the different editions. I used to keep all the still-open opportunities here, but I don't think repeating a long list every week makes the editions easier to read.

So I keep this section to the two most recent editions as a quick reminder of opportunities you may have missed. Older opportunities are still available on the Dev Opportunity Radar website, where you can browse the full collection and use the filters to find something specific.

I've already covered the opportunities below in detail, so I won't repeat everything here. If any of them catch your attention, you can go back to the original edition for the full overview, eligibility details, and application links.

Opportunity	Organization	Type	Format	Deadline	Featured In
Pear Prime 2027	Pear	Early-Career Program	Hybrid	January 4, 2027	Edition #19
Hacktoberfest 2026	MLH × DEV	Open Source Event	Online + In-person	October 2026	Edition #19
PayPal AI Hackathon	PayPal	AI Hackathon	Online (Worldwide)	November 13, 2026	Edition #20
ARC Prize 2026	ARC Prize	AI Competition & Research	Online / Kaggle	November 2, 2026 (Papers: November 8)	Edition #20
Coinbase Strategy, Execution & Analytics Bounty Challenge	Coinbase	Bounty Challenge	Online (US and Canada, excluding Quebec)	October 18, 2026	Edition #20

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 MATS Residency: AI Safety Research

Who it's for: Researchers, academics, engineers, and professionals from AI, machine learning, policy, governance, and related fields who want to work on AI safety research.

What it's about:

The MATS Residency is a full-time research program focused on reducing catastrophic risks from advanced AI systems. Residents pursue their own research agendas over 6 to 24 months, with access to research advisors, computing resources, and the wider MATS research community.

The program has three tracks for different research goals:

Bridge: For experienced researchers transitioning into AI safety who want to develop a body of relevant research and receive career development and placement support.
Anchor: For researchers looking for a longer-term role to pursue an independent AI safety research agenda.
Incubation: For researchers exploring new research directions or developing AI safety research organizations.

Residents receive $155,000 to $285,000 per year (gross), depending on factors such as experience, circumstances, and office location, along with benefits and research computing resources. The program is based in London, Berkeley, and Washington, DC, with a hybrid arrangement requiring residents to work in person at one of the offices for at least a third of their residency.

The program is open to researchers from a range of backgrounds. Applicants are assessed on the quality and seriousness of their proposed work, with track-specific requirements applying. The residency is full-time, although certain academics on sabbatical may be considered for part-time participation.

Format: Full-time, hybrid research residency
Duration: 6–24 months, depending on track
Locations: London, Berkeley, or Washington, DC
Compensation: $155,000–$285,000 per year, gross, plus benefits
Application Window: August 25–October 31, 2026
Intake: Winter 2027

Residency overview | Track details | Apply

📌 Bolt Builders Week

Who it's for: Builders, founders, entrepreneurs, and anyone interested in creating or growing a business using Bolt.

What it's about:

Bolt Builders Week runs from October 17 to 24, 2026, and includes a free building weekend, live sessions, and a business-building contest.

During the building weekend on October 17 and 18, all Bolt users can access GLM 5.3 Flash through the model picker without changing their plan or redeeming a code. Usage is provided in six-hour blocks, with paid plans receiving five times the free allowance per block. Standard rate limits apply, and unused allowance does not carry over.

Live sessions run from October 20 to 23, covering topics such as SEO, customer onboarding and retention, design, and branding. The schedule also includes a Q&A with Bolt co-founders Eric Simons and Albert Pai.

The contest invites participants to build a business idea into a product or use Bolt to develop an existing business. Projects must be built primarily in Bolt, and submissions must include a publicly accessible live link and a Bolt project link. A demo video is optional.

The prizes are $10,000 for first place, $5,000 for second place, and $2,500 for third place. The first-place prize also includes a one-on-one mentoring session with Bolt co-founder and CEO Eric Simons. Entries are judged equally on use of Bolt, the idea, implementation and design, and potential impact.

Format: Online building weekend, live sessions, and contest
Dates: October 17–24, 2026
Deadline: October 20, 2026
Prizes: $10,000, $5,000, and $2,500
Eligibility: Contest entrants must be at least 18 and meet the official rules

Explore Bolt Builders Week

📌 Y Combinator Winter 2027 Batch

Who it's for: Founders who are building a startup or have an idea they want to develop into a business.

What it's about: Y Combinator (YC) is accepting applications for its Winter 2027 startup funding batch. The program runs from January to March 2027 and takes place in person in San Francisco.

YC invests $500,000 in each accepted company. During the three-month program, founders work with a dedicated YC partner, attend group sessions and meetups, and get support with developing their products and raising further investment.

Startups at different stages can apply, including those that are still at the idea stage. Applications are open to startups from anywhere in the world. However, founders should be prepared to work full-time on their company during the batch, which takes place in San Francisco.

If the upcoming batch doesn't fit your timeline, YC also accepts applications for future batches through its Early Decision option.

Format: In-person startup accelerator and funding program
Batch Dates: January to March 2027
Location: San Francisco, California, USA
Investment: $500,000 per accepted company
Application Deadline: November 2, 2026, at 8 PM PT

Decision Date: Applicants who apply by the deadline will receive a decision by December 11, 2026.

Apply to Y Combinator | Learn about Early Decision

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

roadmap.sh: Developer Roadmaps and Learning Resources

Who it's for: Developers who want to learn a new technology, prepare for a role, or figure out what skills to learn next.

What it's about: roadmap.sh is a community-driven platform with roadmaps, study plans, and learning resources for different developer roles and technologies.

The roadmaps are interactive, so you can click on individual topics to explore them and find resources to learn more. There are paths for frontend, backend, DevOps, cybersecurity, AI engineering, data science, cloud, and many other areas.

Beyond roadmaps, the platform also has best practices for topics like API security and code review, along with questions to test your knowledge of technologies such as JavaScript, React, and Node.js.

You can browse the roadmaps and use them to plan your learning. The project also accepts community contributions to its roadmaps.

Format: Online learning resource
Cost: Free to access the roadmaps and resources

Explore roadmap.sh

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

We've had some really wonderful community finds over the last few weeks, and I honestly can't thank everyone enough for taking the time to find these opportunities, look through them, and send them my way. I know that takes time, and I appreciate every person who thinks of the Radar when they come across something they feel others might find useful 💙

This week, we weren't able to include a community find, but that's completely okay. Hopefully we'll have more wonderful finds from the community as we keep going.

So if you come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, please do send it my way. I love seeing what you find, and it helps make this series better for everyone.

If I feature something you shared in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

If you discovered an opportunity through the radar, applied to something, joined a community, attended an event, or simply found a resource you hadn't seen before, I'd genuinely love to hear about it.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

If you'd like to share an update, feel free to leave a comment on this edition. With your permission, I may feature it in a future 💙 Reader Updates section and tag you so other readers can celebrate your journey too.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

Every week, I spend time searching for opportunities, resources, and communities that I think deserve a little more attention. But one of my favorite parts of this series isn't the research. It's seeing what happens after an edition is published.

Seeing someone discover an opportunity, apply to a program, share a resource, suggest a Community Find, or come back to tell us what they learned reminds me why I started Dev Opportunity Radar in the first place.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Whether you've been reading since the very first edition or this is your first time here, thank you for being part of the journey. Every comment, suggestion, and shared opportunity helps make this series better than I could build on my own.

If you ever come across an opportunity, resource, event, community, or anything else you think deserves more attention, I'd love for you to share it in the comments. And if Dev Opportunity Radar helped you discover something exciting, I'd love to hear that too.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

If this is your first time discovering the series, you can explore every edition, browse opportunities by category, discover Community Finds, and catch up on Reader Updates on the Dev Opportunity Radar website.

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

🐾 DEV Pet Corner #1: Show Us Your Pets!

Hemapriya Kanagala — Sun, 11 Oct 2026 13:52:25 +0000

TL;DR

Welcome to DEV Pet Corner, a new weekly series where we take a little break from tech and share our love for animals!

Every Sunday, let's share pictures, stories, and memories of our pets, animals we've met, and even the adorable animals we love following on Instagram or elsewhere online. Share as many pictures and links as you'd like! You don't need to own a pet to join in. If animals make you smile, you're welcome here ❤️

📚 Table of Contents

❤️ Why I'm starting this
🐶 Show us your animal friends!
🐾 See you next Sunday!

❤️ Why I'm starting this

I've wanted to start this series for the longest time, but somehow, I kept putting it off. Today, I'm finally doing it!

If there's one thing you should know about me, it's that I LOVE PETS.

My family had a dog when I was very young, and although we haven't had a pet since, I've always had a soft spot for animals.

When I was doing my master's at the University of Oklahoma, I used to take pictures of dogs I came across on campus. Being away from home, those little encounters often made my day. Sometimes, a quick moment with a dog between classes was enough to brighten an otherwise ordinary day. I still have those pictures, and looking back at them brings back some lovely memories ❤️

If you've read my personal reflection posts, you probably know that I often talk about how our health and well-being come first. We're so busy studying, building careers, and working towards our goals that we sometimes forget to slow down and enjoy life along the way.

That's what inspired this series. We spend so much time talking about tech here on DEV, and I thought it would be lovely to have a little Sunday tradition where we can share something different, get to know each other beyond our work, and enjoy the simple happiness that animals bring us 💛

🐶 Show us your animal friends!

Now, let's get to the fun part!

I'd love to see your pets, whether they're the ones waiting for you at home, the ones you grew up with, or the ones who have a special place in your heart.

If it involves an animal you love or something that makes you smile, I'd love to see it!

Share pictures, funny moments, sweet memories, little stories, or links to your favorite animal posts. Share as many pictures as you'd like. There's no limit!

If you're sharing someone else's content, please link to the original post and respect the creator's wishes about sharing their work.

Don't have anything to share this time? No worries! Just enjoy all the adorable animals in the comments, and join us whenever you'd like.

I'll share a picture of a very cute dog I came across at the University of Oklahoma in the comments. I'm happy to finally share a little memory from my time there!

🐾 See you next Sunday!

DEV Pet Corner will be here every Sunday 😃

I've wanted to start this series for a long time, and I'm so happy I've finally decided to give it a try.

I'm not doing this for views, likes, or comments. I simply love animals, and I thought it would be lovely to have something a little different to look forward to each week.

Even if nobody joins in this first edition, I'll still be back next Sunday, and the Sunday after that. Sometimes, an idea is worth trying simply because it means something to you.

If you have any ideas for future editions, I'd love to hear them!

One little note: I know you all are wonderful and kind, but since this is a little off-topic from our usual tech posts, I just wanted to mention that let's keep the comments friendly, positive, and welcoming to everyone.

I'll be checking the comments, and I'm really looking forward to seeing your animal friends, reading your stories, and enjoying all the cuteness with you!

Thank you for being here for the very first DEV Pet Corner! See you next Sunday!

Dev Opportunity Radar #20: $2M AI Reasoning Challenge, PayPal AI Hackathon, and Coinbase Analytics Challenge

Hemapriya Kanagala — Fri, 09 Oct 2026 14:55:22 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features the PayPal AI Hackathon, ARC Prize 2026, and Coinbase's Strategy, Execution & Analytics Bounty Challenge, along with Build Your Own X as a resource for learning how different technologies work by building them from scratch.

If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

If you've discovered something through the Radar, I'd love to hear about it. Whether you applied to an opportunity, joined a community, completed a program, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission).

And if you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature one of your Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan
🔄 Still Open From Previous Editions
📍 This Week's Opportunities
- 📌 PayPal AI Hackathon
- 📌 ARC Prize 2026
- 📌 Coinbase Strategy, Execution and Analytics Bounty Challenge
📚 Resources Worth Checking Out
- Build Your Own X
🌟 Community Finds
💙 Reader Updates
👋 Until Next Friday
🌐 Dev Opportunity Radar Website

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Location / Format	Deadline
PayPal AI Hackathon	PayPal	AI Hackathon	Online (Worldwide)	November 13, 2026
ARC Prize 2026	ARC Prize	AI Competition & Research	Online / Kaggle	November 2, 2026 (Papers: November 8)
Coinbase Strategy, Execution & Analytics Bounty Challenge	Coinbase	Bounty Challenge	Online (US and Canada, excluding Quebec)	October 18, 2026

Resource Highlight

Resource	Why Check It Out
Build Your Own X	A collection of step-by-step tutorials for recreating technologies from scratch, covering topics such as databases, operating systems, neural networks, AI models, programming languages, and web servers.

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

Opportunity	Organization	Type	Format	Deadline	Featured In
Nebius x NVIDIA Global AI Hackathon	Nebius × NVIDIA	Hackathon	Online	October 30	Edition #18
Pear Prime 2027	Pear	Early-Career Program	Hybrid	January 4, 2027	Edition #19
Graph Hacks: Context for AI Agents	WeMakeDevs × FalkorDB	AI Hackathon	Online	October 18	Edition #19
Hacktoberfest 2026	MLH × DEV	Open Source Event	Online + In-person	October 2026	Edition #19

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 PayPal AI Hackathon

Who it's for: Developers, designers, founders, students, and anyone interested in building with AI and payment technologies.

What it's about:

The PayPal AI Hackathon is a global online hackathon where participants build an application that meaningfully integrates PayPal's developer platform and an AI tool, model, or platform of their choice.

There are no fixed problem statements or required tracks. Projects can include AI agents, payment experiences, business tools, applications, or automations. Participants can work individually or in teams, and they can start a new project or make meaningful progress on an existing one during the hackathon.

A working prototype or proof of concept is required. Submissions must include a public code repository with a license, documentation, a functional demo, details of the AI tools used, and a demo video under three minutes. Static mockups and non-functional demos do not meet the requirements.

The total prize pool is listed as $67,500+, with awards for the overall winners and categories such as creativity, impact, agentic commerce, and the use of PayPal and sponsor tools. Some awards include cash, while others offer credits or subscriptions.

Format: Online, worldwide

Dates: Deadline November 13, 2026, at 1:30 AM IST

Team Size: Individual or team

Prize Pool: $67,500+ in cash and other prizes

Requirement: Meaningful use of both PayPal and AI

Explore the hackathon

📌 ARC Prize 2026

Who it's for: AI researchers, developers, and anyone interested in reasoning systems, AI agents, and open-source AI research.

What it's about:

ARC Prize 2026 is a competition focused on advancing AI reasoning, with $2 million in total prizes across three tracks. Participants can work on static reasoning tasks, interactive AI agents, or research papers exploring approaches to improving performance on the ARC-AGI benchmark.

There are three tracks:

ARC-AGI-2: Build systems that solve static reasoning tasks by predicting the correct outputs for visual grid-based problems.
ARC-AGI-3: Build AI agents that explore unfamiliar environments, learn how they work, set goals, and plan actions without being given explicit instructions.
Paper Prize: Submit a research paper presenting an approach to improving ARC-AGI performance, supported by a corresponding Kaggle code submission.

The prize pools differ by track. ARC-AGI-2 has $700,000 available, ARC-AGI-3 has $850,000, and the Paper Prize has $450,000. Awards include prizes for high-scoring solutions, research contributions, and progress toward specific benchmarks.

One important requirement is that participants must open-source their solutions to be eligible for prizes. Submissions are made through the designated Kaggle competitions, and internet access is unavailable during evaluation, so API-based systems such as GPT or Claude cannot be used during that stage.

Format: Online, through Kaggle

Competition Start: March 25, 2026

Submission Deadline: November 2, 2026

Paper Deadline: November 8, 2026

Results: December 4, 2026

Total Prize Pool: $2 million across three tracks

Requirement: Reproducible, open-source solutions for prize eligibility

Explore the competition

Track details:

📌 Coinbase Strategy, Execution and Analytics Bounty Challenge

Who it's for: People interested in analytics engineering, data modeling, SQL, Python, and data quality.

What it's about:

Coinbase's Strategy, Execution & Analytics team is running a bounty challenge built around a fictional scenario involving an Analytics Engineer intern supporting the Growth team.

Participants must complete four exercises covering data modeling for an onboarding funnel, investigating inconsistencies across signup reports using Python, reviewing an inherited SQL pipeline, and communicating a metric discrepancy to a product manager.

The challenge focuses on technical skills as well as decision-making, data validation, and explaining data issues to stakeholders. No live dataset is provided, so participants are expected to explain their assumptions and describe their solutions using code, schemas, or written responses where appropriate.

Submissions must include a current resume in PDF format, responses to all four exercises within a combined limit of 1,500 words (excluding code blocks), and a brief disclosure explaining how AI tools were used, if applicable.

The top 20 participants are eligible to receive $250 in USDC and an exploratory call with a Coinbase Emerging Talent recruiter. Participation does not count as a job application or guarantee an interview or internship.

Format: Online bounty challenge

Challenge Window: September 25 to October 18, 2026

Deadline: October 18, 2026, at 11:59 PM Pacific Time

Prize: $250 in USDC per selected participant, plus a recruiter call

Number of Recipients: 20

Eligibility: Legal residents of the United States or Canada, excluding Quebec, aged 18 or older, with a verified Coinbase account

Challenge details and submission

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

Build Your Own X

Who it's for: Developers and learners who want to understand how programming concepts, tools, and technologies work by building them from scratch.

What it's about:

Build Your Own X is a GitHub repository maintained by CodeCrafters that collects step-by-step tutorials for recreating different technologies. Topics include databases, neural networks, programming languages, operating systems, web servers, Git, Docker, AI models, and more.

The repository links to tutorials in different programming languages, covering projects ranging from building a simple neural network to implementing a database or creating a programming language. Readers can browse the categories and choose a project based on what they want to learn.

It's a collection of external tutorials rather than a single structured course, so the languages, prerequisites, and difficulty levels vary between projects.

Format: Free, open-source collection of tutorials

Topics: Software Engineering, Systems Programming, AI/ML, Databases, Networking, and more

Languages: Varies by tutorial

Cost: Free

Explore the repository

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

This week, we weren't able to include a community find, but that's completely okay. Hopefully we'll have more wonderful finds from the community as we keep going.

If I feature something you shared in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

The Parts of a Job Search We Don't See

Hemapriya Kanagala — Mon, 05 Oct 2026 15:28:28 +0000

TL;DR

We usually see a job search as applying, interviewing, and hopefully getting an offer. But there is a lot happening around those steps that we rarely get to see.

I recently read Notes on the Industry Job Search by Alisa Liu, a researcher at OpenAI on the pretraining team, where she shares what her own industry search looked like after a six-year NLP PhD. Reading her experience made some parts of the job search much clearer to me, especially the things that are easy to underestimate: timing, interview stamina, preparing differently for every process, getting help from people around you, negotiation, and the emotional side of it all.

These are the things I took away from her experience.

The full article is linked in the References section at the end. Please read it if you want the complete picture, because there is much more detail in her post than I can cover here.

And if you have been through a job search yourself, I’d love to hear about your experience too. What did you learn along the way? What helped you? What do you wish you had known earlier? Feel free to share it in the comments so others can learn from your experience too ❤️

What I took away
- The job search is much bigger than the interview
- Timing your interviews is not as simple as it sounds
- Your first interview may have been prepared for long before you knew you needed it
- Having the experience to get the interview and having the skills to pass it are two different things
- "Technical preparation" is not one giant category
- You can know something and still not be ready to demonstrate it
- The interviewer may be tired too
- Your preparation should change depending on the opportunity
- Interview stamina is a real thing
- Writing down what happened after an interview can become part of your preparation
- The studying can change you beyond the interview
- Behavioral interviews can be harder precisely because they look easy
- Getting an offer can create another kind of uncertainty
- An initial offer isn't necessarily the final conversation
- A lot of career decisions are made without enough information
- The emotional side is not a side note
- There is a difference between preparing for the next chapter and missing the current one
Please take care of yourself
I'd love to hear from you
References
Let's Stay Connected

What I took away

I don't want this to be a summary of Alisa's article. Her original post already does that much better than I could.

Instead, I wanted to share the parts that made me stop and think, especially the things that I don't usually see talked about when people talk about job searching.

Some of these are practical, like how you prepare, how you approach different interviews, and what happens after an offer. Others are much more personal, like dealing with uncertainty, comparison, exhaustion, and remembering to take care of yourself through the process.

So, here are the things I took away from her experience.

1. The job search is much bigger than the interview

When someone says, "I'm job searching," I think we often picture a very small part of what is actually happening.

Apply, hear back, interview, get an offer.

But Alisa's numbers gave me a much better sense of what can actually be behind that process. She interviewed at 11 companies across 57 interviews. On top of that, she had 46 additional recruiter calls, 16 post-offer conversations, and many informal networking conversations.

That is a lot of work that you would never know about if all you saw was the final sentence:

"I interviewed with 11 companies."

There is deciding when to start each process, preparing for each interview, talking to recruiters, keeping track of different companies, recovering between interviews, making decisions with incomplete information, and then potentially doing all of that again after an offer.

The interview is only one visible part of the job search.

And I think seeing that more clearly changes how we look at our own progress too. Sometimes what feels like "nothing is happening" may actually involve a lot of work that simply isn't visible from the outside.

2. Timing your interviews is not as simple as it sounds

This was one of the less obvious things I took from her article. There is common advice that says you should use a few companies as practice and then try to time the companies you care about so that the offers arrive around the same time. That sounds very neat when written as a strategy.

Real life is obviously messier. Alisa points out that companies can have different hiring timelines, different amounts of headcount, different teams hiring at different times, and different levels of urgency.

So sometimes the timing of your process is influenced by things that have nothing to do with how prepared you are. That was a useful reminder for me because job searches can sometimes make us believe every outcome is a direct reflection of our own decisions.

It isn't always. There are things happening on the other side of the table too.

And even offer deadlines can have more flexibility than candidates might assume, while some offers can have much tighter deadlines. Knowing that these things exist can help you ask better questions instead of simply accepting every timeline as fixed.

3. Your first interview may have been prepared for long before you knew you needed it

This was another part I found interesting. Alisa talks about doing good work during the PhD, making friends, collaborating, going to conferences, and building relationships. Then, when the job search started, some of those connections could become helpful in getting that first interview.

That made me think about networking differently. Sometimes we treat networking as something we have to suddenly start doing when we need a job. But a relationship built through a project or collaboration years ago can become useful much later.

She also mentions reconnecting with people she had not spoken to in years. That is something I don't think people talk about enough. You don't necessarily have to know hundreds of people. Sometimes it is simply about not being afraid to reach out to someone you already know, even if it has been a long time.

And there is another part here that I loved. She also says networking does not come easily to everyone and that people should take care of their own energy and comfort levels. So this isn't about forcing yourself to become the most social person in the room.

Build relationships in ways that feel possible for you.

4. Having the experience to get the interview and having the skills to pass it are two different things

This was a very useful thing to notice in her experience. Alisa says that technical skills and knowledge were evaluated much more heavily during her interviews than research experience, while her research background probably helped get her the interviews in the first place.

That is an important difference. Your background can make someone interested enough to talk to you. But once you are in the interview, you still have to demonstrate what you can actually do.

Those are two different stages. And I think that applies beyond research roles too.

A strong resume can open a door.

It doesn't replace being able to walk through it.

5. "Technical preparation" is not one giant category

Alisa's interviews included ML coding, general coding, technical discussions, research discussions, behavioral interviews, math, and a job talk.

What I found useful here is not just the list itself. It is what the list tells us.

Being technically strong does not necessarily mean being prepared for every way someone can ask you to demonstrate that strength.

One interview might ask you to implement something. Another might ask you to explain why a particular approach works. Another might ask you to design an experiment. Another might ask you to discuss your own research.

Another might ask you to solve a math problem on paper. Another might ask you about a situation where you disagreed with someone.

These are very different things.

So preparing for "the interview" is not really enough. You need to prepare for the kind of thinking the interview is actually asking you to demonstrate.

6. You can know something and still not be ready to demonstrate it

This is one of my favorite practical points from the article. Alisa describes taking notes, drawing diagrams, practicing problems, implementing things from scratch, and spending entire days making sure she understood fundamental ML concepts deeply.

But she also specifically recommends practicing coding with AI assistance completely off when preparing for interviews. That feels especially relevant now.

In everyday work, using AI can be completely normal. We can ask for an explanation, check an approach, debug something, or get unstuck. But if the interview doesn't allow those tools, practicing with them every time can give you a very different picture of your readiness.

You might understand a concept very well while still finding it difficult to produce the solution yourself under pressure.

So there is a difference between:

"I understand this when I have help."

and

"I can reason through this myself when someone puts the problem in front of me."

Both are useful skills. But they are not the same skill.

7. The interviewer may be tired too

This is a small point in her article, but I thought it was surprisingly practical. When talking about her research pitch, Alisa mentions tailoring it to the role and making it easier for interviewers to see why her background was relevant.

Part of her reasoning was simply that interviewers are tired. That sounds obvious once you hear it, but it changes how you think about communication.

You may know your work extremely well. You may have spent years on it. But the person listening to you may have a long day of interviews, meetings, and other responsibilities.

Making the relevant part easy to understand isn't about making your work less sophisticated. It is about helping another person understand it.

That is a useful communication skill far beyond interviews.

8. Your preparation should change depending on the opportunity

Alisa describes looking at the interview description, topics the company cares about, information from recruiters, and what she knew about the company to understand what she should focus on.

That sounds simple, but it changes the question you ask yourself.

Instead of:

"What should I study for interviews?"

it can be:

"What is this particular interview actually trying to find out about me?"

That second question is much more useful.

You might need more coding practice for one role. You might need to review fundamentals for another. You might need to prepare your research story. You might need to spend more time on behavioral examples. You might need to brush up on math.

There is value in having strong foundations, but there is also value in not spending your limited preparation time equally on everything.

9. Interview stamina is a real thing

This is something I rarely see discussed when people give interview advice. Alisa talks about using some companies as practice, but also warns that stamina is finite.

That matters when you are interviewing with several companies at once. You are not just solving problems. You are switching between topics, remembering different processes, talking to recruiters, preparing presentations, studying, and making decisions. And then you are expected to show up and think clearly again.

She also shares that she once went into a technical interview after sleeping only 2 hours because she had been cramming. The knowledge she had tried to put into her head at the last minute did not end up helping her.

Instead, she spent time making a simple mistake because she was exhausted.

That made one thing very clear to me.

More preparation is not always better preparation.

Sometimes the most useful thing you can do before an interview is sleep.

10. Writing down what happened after an interview can become part of your preparation

Another small detail from her process that I thought was useful was recording notes after interviews. That makes sense for a reason beyond remembering the questions.

If you are doing several interviews, you can quickly forget what you struggled with, what you explained well, what you wish you had answered differently, or what you learned.

Writing those things down turns one interview into information you can use for the next one.

Instead of every interview being an isolated event, you start building your own feedback loop.

And that is especially useful when the process stretches over weeks or months.

11. The studying can change you beyond the interview

This was probably one of the most meaningful parts of the article for me. Alisa says that studying for interviews gave her a wider breadth of knowledge, improved her confidence in technical conversations, and even helped her become more effective in her research.

That is a much bigger benefit than simply passing an interview.

Sometimes we think of interview preparation as temporary studying. Learn this because they might ask. Practice this because it might come up. Memorize this because it is on the list.

But deep learning does not disappear when the interview ends. Understanding something properly can change the questions you ask, the problems you notice, the conversations you can participate in, and the ideas you can come up with.

That made me think about interview preparation less as studying only for a test and more as a chance to find gaps in my own understanding.

12. Behavioral interviews can be harder precisely because they look easy

Alisa shares that she failed her first behavioral interview because she had not prepared for what she thought would be very simple questions. I can see how easy it is to fall into that trap.

You might think:

"I know myself. Of course I can answer a question about myself."

Then someone asks you for a specific example from your experience, and suddenly you are trying to remember what happened three years ago while also figuring out how to answer the actual question.

Her solution was to think through memorable stories from her PhD and map them to common behavioral questions so that she could retrieve the right example more easily.

That doesn't mean memorizing fake answers. It means knowing your own experiences well enough that you can talk about them clearly.

13. Getting an offer can create another kind of uncertainty

I think this is one of the easiest parts of a job search to overlook. We usually imagine the offer as the finish line.

But in her experience, it opened another stage. There were conversations with future teammates and managers, recruiter calls, visits, more communication, comparing options, and negotiation.

And negotiation was not something she felt naturally prepared for. She says that unlike interviews, it was not something she could simply study her way through.

She was also very honest about the imbalance of experience. Recruiters negotiate these things regularly. Most candidates don't.

That is why she leaned on friends for advice and for more data points.

That was a useful reminder that sometimes preparation means recognizing where you don't have enough information yourself and finding people who do.

14. An initial offer isn't necessarily the final conversation

This is another point that can be easy to miss if you have never been through the process. Alisa says recruiters sometimes explicitly told her that they did not expect candidates to simply accept the first offer.

She also talks about how putting effort into negotiation for a few weeks can have a very meaningful financial impact.

I don't think the takeaway is "always negotiate aggressively." It is more basic than that.

If you receive an offer, you are allowed to ask questions. You are allowed to understand what is flexible. You are allowed to think about what matters to you.

And you don't have to assume that the first number you see is automatically the only possible outcome.

15. A lot of career decisions are made without enough information

This may be one of the hardest things to understand until you experience it yourself. Alisa talks about making decisions with incomplete information and how even small choices, such as who to contact and when, can feel like they have much bigger consequences than they should.

There often isn't a perfect answer. You don't know exactly what a team will be like six months from now. You don't know whether another opportunity will appear. You don't know whether waiting will help or hurt. You don't know why one company moves quickly while another goes quiet.

And sometimes you have to make a decision anyway.

I think that is an important part of a job search to accept. You can prepare carefully without being able to control everything.

16. The emotional side is not a side note

This part of her article is very honest. She talks about comparing herself with peers, dealing with people's opinions about where she should go, managing a huge number of decisions, and feeling stressed and miserable for months.

That is very different from the usual career advice where everything is reduced to a list of things you should optimize.

Real people don't experience a job search like a spreadsheet.

You can prepare properly and still be scared. You can get an interview and still wonder whether you're good enough. You can receive an offer and still not know what you want.

You can watch your friends move ahead and feel like you're falling behind even when you aren't. And sometimes the uncertainty itself is exhausting.

I think there is value in saying that out loud because someone going through it might otherwise assume they are the only person finding it difficult.

17. There is a difference between preparing for the next chapter and missing the current one

I really loved where Alisa takes the article at the end. After writing about the stress of the job search, she talks about how sad she was to leave her PhD and how special that period had been.

There is something very human about that.

We are constantly preparing for whatever comes next. As students, we prepare for jobs. When we start working, we prepare for the next role. Then the next promotion. Then the next move.

There is always another thing waiting.

Preparing for the future is important. But it should not mean that the present becomes something we are only trying to get through.

If you are learning something right now, there can still be joy in learning it. If you are working on a project, there can still be joy in building it. If you are studying, you don't have to turn every minute into career preparation.

You are allowed to enjoy the chapter you are currently living too.

Please take care of yourself

I wanted to make this a separate section because this is something I tell people all the time, and I really mean it.

If you are currently searching for a job, please take care of yourself with the utmost love.

I know the job market is hard. I know how much pressure can come with searching. I know rejection can hurt. I know seeing other people get offers can make you question yourself. I know how easy it is to feel like you should always be doing one more application, one more problem, one more certification, one more interview, one more thing.

But please take care of yourself too.

Your physical health matters. Your mental health matters. Your sleep matters. Your food matters. Your relationships matter. Your time away from the screen matters. Your peace matters.

Because if you are not okay, what are all those other things for?

A job is important. An offer is important. Your career is important. But none of those things are worth losing yourself over.

I don't mean this as a reminder to "balance" everything perfectly. Life does not work that neatly. There will be days when you have more energy and days when you don't. There will be days when you can study for hours and days when even opening your laptop feels difficult.

And that is okay.

You don't have to feel guilty for resting. You don't have to feel guilty for having a life outside your job search. You don't have to feel like every hour that you are not applying or studying is an hour wasted.

You are a person before you are a job seeker.

Please don't be cruel to yourself because the market is difficult. Please don't decide that someone else's timeline is proof that you are behind. Please don't measure your entire worth through responses from companies.

Sometimes things simply take longer than we hoped they would.

And I know it can be very hard to believe that everything will be okay when you are in the middle of it. I know there can be bills to worry about, family expectations, loans, uncertainty about the future, and so many other things that make "just stay positive" feel impossible.

So I am not asking you to pretend everything is fine.

I am just asking you to be a little kinder to yourself while you are going through it.

Do what you can. Keep going when you have the energy. Rest when you don't. Ask for help when you need it. Talk to someone you trust. Take a break when you need one.

And please remember that a rejection is not a measurement of your worth. A delayed offer is not a measurement of your potential. Someone else's success is not proof that you are failing.

Your life is so much bigger than this job search.

There will be things to celebrate that have nothing to do with a job offer. There will be people who love you regardless of what is written on your resume. There will be mornings when you wake up and realize that this difficult chapter did eventually pass.

So please keep going, but please don't forget to live while you are going.

You matter in this process too.

And if you are reading this while going through a difficult job search, I really hope you are being gentle with yourself.

Please eat. Please sleep. Please step away from the screen. Please talk to someone. Please let yourself laugh. Please let yourself have a good day without feeling like you should have been applying instead.

You do not have to earn the right to take care of yourself by getting a job first.

And if today was a difficult day, that's okay.

Try again tomorrow.

With the utmost love, I hope you are okay. I hope you are taking care of yourself. And I truly hope something good finds you soon ❤️

I'd love to hear from you

If you have already been through a job search, or you are currently going through one, I would genuinely love to hear from you.

Maybe you have a preparation method that helped you. Maybe there is something you wish someone had told you earlier. Maybe you learned something from a rejection. Maybe you have a networking tip.

Maybe you learned something about interviews, negotiation, choosing between offers, or simply getting through the difficult parts.

And if you are comfortable sharing, please do.

There are people here at very different stages of their careers. There are students, new graduates, early-career developers, experienced professionals, people changing careers, and people looking for their next opportunity.

I'm early in my own career too, so I would genuinely love to learn from people who have already been through some of this.

Maybe we can make the comments section into something useful for someone who finds this post months or years from now.

Share whatever you feel comfortable sharing.

References

Notes on the Industry Job Search by Alisa Liu

This is the original article I read, and I really recommend giving it a read if you have the time.

I have only written about the parts that I personally took away from her experience, but her original post gives a much fuller view of the journey. She goes into her timeline, the different interview formats, how she prepared, how she approached different interview processes, recruiter conversations, negotiation, the emotional side of the search, and the resources she used to study.

There is much more detail in her post than I can reasonably fit here, and reading the full thing gives you the context behind all of these points.

For me, it is a very good read, especially if you are preparing for an industry job search or simply want to understand what the process can look like from the other side.

🤝 Let's Stay Connected

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

Dev Opportunity Radar #19: Hacktoberfest, $20K AI Agent Hackathon, and Pear Prime 2027

Hemapriya Kanagala — Fri, 02 Oct 2026 15:16:19 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features Pear Prime 2027, Hacktoberfest 2026, and Graph Hacks: Context for AI Agents, along with How to Scale Your Model as a resource worth checking out.

If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

If you've discovered something through the Radar, I'd love to hear about it. Whether you applied to an opportunity, joined a community, completed a program, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission).

And if you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature one of your Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan
🔄 Still Open From Previous Editions
📍 This Week's Opportunities
- 📌 Pear Prime 2027
- 📌 Hacktoberfest 2026
- 📌 Graph Hacks: Context for AI Agents
📚 Resources Worth Checking Out
- How to Scale Your Model
🌟 Community Finds
💙 Reader Updates
👋 Until Next Friday
🌐 Dev Opportunity Radar Website

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Location / Format	Deadline
Pear Prime 2027	Pear	Early-Career Program	Hybrid / Community + Career	January 4, 2027
Hacktoberfest 2026	MLH × DEV	Open Source Event	Online + In-person	October 2026
Graph Hacks: Context for AI Agents	WeMakeDevs × FalkorDB	AI Hackathon	Online (Worldwide)	October 18, 2026

Resource Highlight

Resource	Why Check It Out
How to Scale Your Model	A free online book covering the systems side of scaling language models, including TPUs, GPUs, sharding, parallelism, training, inference, and performance.

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please take a few minutes to visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

Opportunity	Organization	Type	Format	Deadline	Featured In
Nebius x NVIDIA Global AI Hackathon	Nebius × NVIDIA	Hackathon	Online	October 30	Edition #18
Build, Ship, Shape: Amazon Developer Hackathon	Amazon	Hackathon	Online	October 24	Edition #17
Dev3Pack Hackathon	Dev3Pack	Hackathon	Hybrid	October 30	Edition #17

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 Pear Prime 2027

Who it's for: CS students, new graduates, and early-career engineers.

What it's about: Pear Prime is a program from Pear for a small cohort of early-career engineers. The program connects participants with founders and technical leaders from startups and technology companies, along with mentorship and career support from the Pear team.

For the 2027 cohort, Pear lists companies including Cerebras, Etched, Perplexity, HeyGen, Baseten, Forus, Vals, and Andera as teams that Prime Engineers can get exposure to.

The program also includes a community of other Prime Engineers, mentorship and career coaching, access to Pear investors for guidance and feedback on ideas, and priority consideration for PearX if members later decide to start a company.

The application is fairly focused on what you've built and where you want to go next. You'll be asked about your most significant project, internship, or research experience, technologies you're strongest in, notable achievements, the type of engineering work you enjoy, and what you're hoping to build or become over the next few years.

There is also a question about something you built or shipped because you wanted to, rather than because it was required by a class, job, or manager. So having personal projects, open-source work, research, or other examples of self-directed work could be useful to have ready when applying.

Format: Hybrid / Community + career opportunities
Program: Pear Prime 2027
Who can apply: CS students, new graduates, and early-career engineers
Application Deadline: January 4, 2027
Focus: Engineering careers, startups, mentorship, community, and building
Application: Resume + project/research experience + technical interests + career goals + other background information

🔗 Learn More | 🔗 Apply

📌 Hacktoberfest 2026

Who it's for: Anyone interested in open source, open-source AI, or building with open-weight models.

What it's about: Hacktoberfest 2026 is a month-long celebration of open source happening throughout October, with both online and in-person activities.

This year's Hacktoberfest is focused on open-source AI and open-weight models, with Fests happening in cities around the world as well as online activities that anyone can join.

If you're participating online, there are livestreams, Global Hack Week, and DEV Challenges, with a new mini-hackathon launching on DEV each week during October.

You can participate online from anywhere, attend an in-person Fest, or do both. And you don't need to be an experienced open-source contributor to take part.

One thing that's different this year is that pull requests and merge requests no longer count toward Hacktoberfest rewards. The event is instead focusing more on learning, building, and participating in the different activities.

Since I'm here on DEV and Hacktoberfest is powered by MLH and DEV, I wanted to give it a small mention here too. If you're already part of the DEV community, you might want to take a look at the DEV Challenges happening throughout October.

Of course, as always, it's completely up to you whether any of the activities are something you'd like to take part in. I just wanted to make sure people here knew it was happening.

Format: Online + In-person | When: October 2026
Cost: Free
Focus: Open source, open-source AI, and open-weight models
Online Activities: DEV Challenges, livestreams, and Global Hack Week
In-Person: 300+ Fests worldwide

🔗 Explore Hacktoberfest 2026
🔗 See DEV Challenges

📌 Graph Hacks: Context for AI Agents

Who it's for: Developers, AI builders, and anyone interested in building AI agents.

What it's about: Graph Hacks: Context for AI Agents is an online hackathon by WeMakeDevs and FalkorDB running from October 15–18, 2026.

The challenge is to build an AI agent or group of agents that uses FalkorDB as the primary graph database. The project should use the graph as part of what the agent does, such as working with connected data, remembering information between sessions, sharing state between agents, or connecting company knowledge.

There are three tracks:

Agents That Act on Connected Data
Agent Memory and Coordination
Company Brain

You can participate in one, two, or all three tracks. You can join solo or with a team of up to four, and you don't need previous graph database experience.

One thing to keep in mind is that FalkorDB must be a central part of the project, and the main FalkorDB implementation needs to be new work completed during the hackathon. Coding assistants are allowed.

There is a $20,000 prize pool, with prizes for each track, along with prizes for the best project blog posts and the top 50 submissions.

Format: Online | Worldwide | Dates: October 15–18, 2026
Team Size: Solo or up to 4
Cost: Free
Tracks: 3
Graph Experience: Not required
AI Coding Assistants: Allowed
Deadline: October 18, 2026

🔗 Learn More & Register

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

How to Scale Your Model

If you're interested in understanding what happens when language models have to run across large amounts of hardware, How to Scale Your Model is a free online book from researchers at Google DeepMind and other institutions that takes a systems view of scaling LLMs on TPUs and GPUs.

The book looks at how hardware and models interact, including compute, memory, communication, model parallelism, training, inference, and scaling across multiple devices.

It starts with topics like roofline analysis, how TPUs work, and sharded matrix multiplication, then moves into Transformer math, training and inference parallelism, practical LLaMA 3 tutorials, profiling TPU code, JAX, and a bonus section on GPUs.

Some of the topics covered include data, tensor, pipeline, and expert parallelism, along with techniques such as model sharding, rematerialization, host offload, and gradient accumulation.

The resource is fairly technical. It assumes that you already understand the basics of LLMs and the Transformer architecture, and ideally have some familiarity with JAX. So this is probably more useful if you're already comfortable with the fundamentals and want to understand what happens underneath the model when it needs to scale.

The book is organized into 12 chapters, and the authors mention that you don't have to read everything in order. The first few chapters introduce the underlying concepts, while later sections apply them to real models and practical systems.

Format: Free online book
Focus: LLM systems, TPUs, GPUs, Transformers, training, inference, parallelism, and performance
Level: Advanced / technical
Prerequisites: Basic LLM and Transformer knowledge; JAX familiarity is helpful
Topics: Roofline analysis, TPU architecture, sharding, Transformer math, training, inference, profiling, JAX, GPUs
Authors: Researchers and engineers from Google DeepMind, Stanford, and other organizations

🔗 Read How to Scale Your Model

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

This week, we weren't able to include a community find, but that's completely okay. Hopefully we'll have more wonderful finds from the community as we keep going.

If I feature something you shared in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

I Built My First AI Agent With AWS AgentCore, and the Hardest Part Wasn't the AI

Hemapriya Kanagala — Tue, 29 Sep 2026 15:44:51 +0000

TL;DR

I recently completed another project from Udacity's Future AWS Agent Engineer Nanodegree Program, which I was able to take through the AWS AI & ML Scholarship.

This was my second project working with AI agent systems, but it was my first time building one with Amazon Bedrock AgentCore and the Strands SDK. The goal was to build a customer support AI agent that could track orders, process refunds, answer product and policy questions using a Knowledge Base, remember customer information across sessions, calculate loyalty discounts using code, and browse live websites.

On paper, that sounds like six features.

In reality, it meant connecting AgentCore Runtime, AgentCore Gateway, Lambda, API Gateway, Knowledge Base, Memory, Code Interpreter, Browser Tool, IAM, deployment, and CloudWatch into one working system.

When I first saw all of that, it felt like a lot. I knew what I was supposed to build, but I didn't yet understand how all the pieces were supposed to fit together.

This time, I had enough time to work through the project properly instead of rushing through it. And that gave me room to notice something I probably wouldn't have noticed otherwise: I was making the project harder by trying to understand everything at once.

Once I stopped doing that and started asking, “What is the next thing I need to understand?”, the project became much easier to work through.

This isn't a step-by-step guide. There are already many great guides for AWS and AgentCore. This is my experience of building the project, what confused me, what went wrong along the way, how the architecture eventually started making sense, and what I learned from putting all those pieces together.

And somewhere along the way, the word “agent” stopped feeling like just another AI buzzword to me. I could actually see what it meant in a working system.

I Knew What I Had to Build. I Just Didn't Know How Big It Would Feel
So What Was This Agent Actually Supposed to Do?
The Architecture Finally Made Sense When I Stopped Thinking in AWS Names
I Drew the Architecture Because I Needed to See It
The Six Capabilities Were Really Six Different Problems
- 1. Order Tracking: Getting Real Data Back to the Customer
- 2. Refunds: When the Agent Needs to Take an Action
- 3. Knowledge Base: The Model Knowing Isn't the Same as the Application Knowing
- 4. Memory: When a New Conversation Isn't Really Starting From Zero
- 5. Code Interpreter: Let the Model Decide, Let Code Calculate
- 6. Browser Tool: When the Information Isn't Inside Your Application
Having the Right Code Doesn't Mean Having Access to It
Deployment Wasn't the Finish Line
Six Tests Were Easier Than One Giant “Does It Work?”
The Part That Became Clear Only After Everything Worked
There Was Another Layer I Hadn't Thought About Enough: Operating the System
I Also Had to Learn When the Project Was Actually Finished
What This Project Actually Taught Me
A Small Thank You
I Would Love to Hear From You
🤝 Let's Stay Connected

I Knew What I Had to Build. I Just Didn't Know How Big It Would Feel

I want to start here because the finished project looks much simpler than the experience of building it. Once everything was working, I could look at the architecture and understand what each part was doing.

But at the beginning, I saw a long list of unfamiliar names: Amazon Bedrock AgentCore, Strands SDK, Lambda, API Gateway, AgentCore Gateway, Knowledge Base, Memory, Code Interpreter, Browser Tool, IAM, and CloudWatch. And then there was deployment, testing, and permissions.

Individually, none of those things sounded impossible. Together, they felt like a lot.

I think that is one of the hardest parts of learning cloud and AI systems. You can understand each word separately and still have no idea how the words are supposed to connect.

I initially wanted to understand the entire architecture before I started building. That didn't work very well. The more I tried to understand everything at once, the more overwhelming it became.

So I changed the question I was asking myself.

Instead of:

“How am I supposed to understand this entire project?”

I started asking:

“What is the next thing I need to understand?”

That became a much more manageable way to work.

And eventually, the pieces started connecting.

So What Was This Agent Actually Supposed to Do?

The project was a fictional customer support system. A customer could ask something, and the AI agent needed to understand the request and use the appropriate capability.

The six capabilities were:

Order tracking
Refund processing
Product and policy questions
Customer memory across sessions
Loyalty discount calculation
Live website browsing

That meant this wasn't just a chatbot that generated a response. The agent could actually interact with other parts of a system, depending on what the customer needed.

A simplified view of the flow was:

Customer
   ↓
AI Agent
   ↓
What does the customer need?
   ↓
Use the appropriate capability
   ↓
Get the result
   ↓
AI Agent
   ↓
Final response
   ↓
Customer

At first, that flow looks straightforward. But every capability underneath it needed different infrastructure, and that is where the project became interesting.

The Architecture Finally Made Sense When I Stopped Thinking in AWS Names

The biggest change in my thinking came when I stopped looking at the project as a list of AWS services. Instead, I started looking at what job each piece had.

The AI model was responsible for understanding the customer's request and deciding what to do based on the instructions and available tools. For the project, I used Amazon Nova 2 Lite through Amazon Bedrock.

The Strands SDK gave me the framework for building the agent and connecting its behavior with the tools and capabilities it needed.

Then there was the infrastructure that helped the agent actually do things. AgentCore Runtime was where the deployed agent ran, while AgentCore Gateway provided the connection between the agent and backend tools. API Gateway exposed the order-related backend operations through APIs, and AWS Lambda performed those backend operations.

The other capabilities had their own pieces as well. The Knowledge Base provided product and policy information that the agent could retrieve, while AgentCore Memory allowed useful customer information to be retrieved across sessions. Code Interpreter handled calculations using actual code, and the Browser Tool allowed the agent to interact with live webpages. Finally, CloudWatch helped me monitor the deployed runtime.

Once I looked at those services by their jobs, rather than their names, the architecture became much less intimidating.

I wasn't trying to memorize AWS. I was trying to answer:

“What does my application need to do, and what piece is responsible for doing that?”

That question helped me much more.

I Drew the Architecture Because I Needed to See It

I eventually made an architecture diagram in Excalidraw. I wanted it to show the story of a request, rather than just put every AWS service on a page.

The idea was simple: the customer asks something, the agent figures out what the customer needs, the appropriate capability is used, and the result comes back to the agent. The agent then uses that result to respond to the customer. The supporting AWS services sit underneath the capabilities that need them.

This is the architecture I built for the project. Drawing it this way helped me understand the system as a flow instead of a collection of services.

Looking at the finished diagram now, it feels obvious to me. But I think that is because I built the pieces underneath it. The diagram became easier to understand after I understood what each box was solving.

The Six Capabilities Were Really Six Different Problems

Once the overall architecture made sense, I could look at each capability separately. That made the project feel much more manageable because I was no longer trying to understand six different things at the same time.

1. Order Tracking: Getting Real Data Back to the Customer

If a customer asked:

“Where is my order?”

the agent needed more than a generated sentence. It needed actual order information.

I created an order-tracking Lambda and exposed the required operations through API Gateway. AgentCore Gateway then provided the connection between the agent and those backend operations.

So the flow was roughly:

Customer
   ↓
Agent
   ↓
AgentCore Gateway
   ↓
API Gateway
   ↓
Lambda
   ↓
Order information
   ↓
Agent
   ↓
Customer

That was one of the first times the difference between a chatbot and an agent workflow became clearer to me. The model wasn't inventing the order status. It was asking another part of the system for the information.

2. Refunds: When the Agent Needs to Take an Action

Refund processing was similar, but the idea was slightly different. The agent wasn't just retrieving information. It needed to trigger an operation.

I connected the refund functionality through AgentCore Gateway to a Lambda function. This made something important click for me: a model saying that something happened and a system actually performing that action are two different things.

If an agent tells a customer:

“Your refund has been processed.”

there should be an actual operation behind that statement. That operation needs to succeed, the result needs to come back, and the agent should respond based on that result rather than simply assuming the action worked.

That is a very different way of thinking about AI applications compared with a simple question-and-answer chatbot.

3. Knowledge Base: The Model Knowing Isn't the Same as the Application Knowing

For product and policy questions, I used an Amazon Bedrock Knowledge Base. This was where I got a much more practical understanding of RAG.

Imagine a customer asks:

“What is the return policy?”

I don't want the model to generate something that sounds like a return policy. I want it to retrieve the information that belongs to the application.

The basic flow becomes:

Customer question
       ↓
Retrieve relevant information
       ↓
Give the information to the agent
       ↓
Generate the response

That made me realize something important: a model can know many things while still not know my application's information.

The Knowledge Base gives the agent a source of information it can retrieve from. That is much more useful than simply hoping the model happens to know the right answer.

4. Memory: When a New Conversation Isn't Really Starting From Zero

I also added AgentCore Memory. The goal was to allow the agent to remember useful customer information across sessions.

I tested this with a simple example. In one session, I told the agent a customer's name and response preference. Then I started a separate session and asked it to retrieve that information from the previous conversation.

It was able to do that.

This was interesting because the second session wasn't simply continuing the first conversation. The system had to retrieve the stored customer context.

That helped me understand the difference between:

“The model can see the previous messages.”

and:

“The application has a mechanism for retrieving relevant customer context.”

It also made me think about the responsibility that comes with memory. In a real customer support application, you would need to think carefully about what information is stored, how long it is retained, who can access it, and how customer information is protected.

Getting memory to work is only one part of the problem.

5. Code Interpreter: Let the Model Decide, Let Code Calculate

The loyalty discount was one of the more interesting pieces because I actually made a mistake here.

The agent needed to calculate a customer's discount using their loyalty tier, available points, and order total. My first calculation logic was incorrect because I was treating loyalty points and dollar values incorrectly.

The model wasn't the problem. My calculation logic was.

I fixed the calculation and redeployed the agent.

That taught me something I think is easy to forget when working with AI: an AI application still contains normal software engineering problems.

You can still have incorrect formulas, incorrect assumptions, edge cases, configuration problems, and bugs. The fact that a model is involved doesn't remove any of those.

It also helped me understand why Code Interpreter was useful. The model could understand that a calculation was needed, while code could perform the actual calculation. For precise arithmetic, that separation made much more sense to me than asking the model to do everything itself.

6. Browser Tool: When the Information Isn't Inside Your Application

The final capability was live web browsing. I used the AgentCore Browser Tool and tested it by asking the agent to visit the Udacity website and return the page title.

This was different from the Knowledge Base because the information wasn't sitting inside my application. The agent had to interact with a live webpage.

That helped me see another side of tools: a tool isn't necessarily just a function that returns data. It can give the agent a way to interact with something outside the model's immediate context.

Having the Right Code Doesn't Mean Having Access to It

This was probably one of the most practical lessons of the project. There were times when the architecture made sense and the code was there, but something still didn't work. The reason was permissions.

The AgentCore runtime needed the right permissions to access resources such as Memory and the Knowledge Base. The Browser Tool also needed the appropriate permissions before it could start a browser session.

This changed the way I approached debugging. Before this project, I might have immediately looked for a code problem. During this project, I started asking a different set of questions: Does the resource exist? Is it in the correct region? Does the runtime have permission to access it? Is the IAM role correct? Is the specific action allowed? Is the tool configured correctly?

That was a much better debugging mindset because sometimes the problem isn't:

“My code doesn't work.”

It is:

“My code is trying to use something it isn't allowed to use.”

The Browser Tool gave me a good example of this. I had the browser capability configured, but the runtime couldn't start the browser session. It would have been easy to assume that the Browser Tool itself was broken.

The actual issue was that the runtime was missing the required permission. I added the permission and tested it again, and this time, it worked.

It was a small fix, but it taught me something important about cloud applications: there is a lot around the code. The application has identities, permissions, resources, configurations, and service connections. All of those pieces have to agree before a feature can actually work.

Deployment Wasn't the Finish Line

Once the pieces were working, I deployed the agent using the AgentCore deployment workflow. This was another point where I changed how I think about deployment.

A successful deployment doesn't automatically mean a successful application. The runtime can deploy successfully while one of the tools still has a configuration or permission problem.

So I treated deployment as the beginning of testing rather than the end of development. I tested the deployed agent capability by capability, which gave me much more confidence than simply seeing a successful deployment message.

Six Tests Were Easier Than One Giant “Does It Work?”

Instead of asking myself, “Does my AI agent work?”, I broke that question into smaller ones.

Can it track an order? Can it process a refund? Can it answer from the Knowledge Base? Can it remember information across sessions? Can it calculate the loyalty discount correctly? Can it browse a live website?

Each one became its own test.

I captured evidence for each of these tests, which gave me six concrete things to verify instead of one enormous pass/fail question.

And eventually, all six worked.

That was a much less intimidating way to test the project.

The Part That Became Clear Only After Everything Worked

Looking back, I think the biggest shift happened after I had all six capabilities working. Before that, I was thinking about individual services. After that, I could finally see the pattern.

The model understands the request, the agent determines what it needs, and a tool provides the appropriate capability. Another service performs the work, the result comes back, and the agent uses that result to respond. That pattern repeats across the six capabilities.

The actual tools are different, but the underlying idea is similar:

Order tracking
→ retrieve backend information

Refund
→ perform a backend action

Knowledge Base
→ retrieve application information

Memory
→ retrieve customer context

Code Interpreter
→ perform computation

Browser
→ interact with live information

That was when the word agent finally started making sense to me.

It wasn't simply:

“An AI model that talks to you.”

It was:

“A model that can understand what needs to happen and use capabilities to actually do something about it.”

There Was Another Layer I Hadn't Thought About Enough: Operating the System

Once the agent was working, I started thinking about what would happen if this were a real customer support application. A customer doesn't care which service failed. They just know their request didn't work.

For example, an order request could travel through:

Customer
   ↓
AgentCore Runtime
   ↓
Agent
   ↓
AgentCore Gateway
   ↓
API Gateway
   ↓
Lambda
   ↓
Response

If something fails somewhere in that chain, the engineering team needs to know where. That's where monitoring becomes important.

For this project, I used CloudWatch to monitor the AgentCore runtime and created a CPU usage alarm. If I were taking this system further for real production usage, I would want to monitor things such as failed requests, error rates, response times, tool failures, resource usage, service health, and costs.

Cost would also matter because this agent uses multiple managed services. A project that works perfectly with a small number of requests could have a very different cost profile at much larger scale.

That made me realize something:

Building something that works and operating something reliably are different problems.

I Also Had to Learn When the Project Was Actually Finished

After the agent was working and the project was submitted, I went back through the AWS resources I had created and cleaned up the project-specific resources.

This wasn't the exciting part of the project, but I think it is an important part of cloud work. Getting the application to work isn't necessarily the same as being finished with the cloud environment around it.

When you create cloud resources, you should know what you created, what is still running, and what happens when you are done with it. Leaving resources active after a project is over can lead to unnecessary usage and costs, especially when multiple managed services are involved.

For someone learning with a limited cloud budget, that matters even more. I wanted to finish the project knowing that I had cleaned up what I no longer needed.

For me, cleanup became part of what actually finishing the project meant, not something separate from it.

What This Project Actually Taught Me

If I could go back to the beginning, I wouldn't tell myself, “Learn everything first.” I would tell myself:

“You don't need to understand the whole architecture before you start.”

When I first saw the project, I wanted to understand AgentCore, Lambda, API Gateway, IAM, RAG, Memory, Browser Tool, Code Interpreter, deployment, and monitoring all together. That was too much. I could understand what each service was called, but that didn't mean I understood how all of them were supposed to work together.

What helped was breaking the project down into smaller questions: What does this resource do? Why does the agent need it? What does it connect to? What should happen when I test it? What happens if it fails?

Those questions were much easier to answer, and each answer made the next one easier.

I think this is especially useful when you're starting something that looks too big. It is easy to look at a cloud architecture full of services and think:

“I don't know any of this.”

But you don't need to know all of it at once. Start with the application and ask what the user needs to happen. Then ask what the system needs in order to make that happen, and learn the service that solves that particular problem.

If you need to store data, learn the database piece. If you need to execute backend logic, learn the compute piece. If the agent needs to retrieve information, learn the retrieval piece. If it needs to remember customer context, learn the memory piece. If it needs to interact with an external capability, learn the tool or gateway piece.

You also don't have to assume that every problem is an AI problem. A missing permission can look like a broken feature. A configuration problem can look like broken code. A calculation bug can look like a model problem. A deployment can succeed while one capability is still misconfigured.

That was another important lesson for me. Before this project, I might have immediately looked for a code problem. During this project, I became more comfortable asking whether the resource existed, whether it was in the right region, whether the runtime had permission to access it, whether the IAM role was correct, and whether the specific action was allowed.

I started this project thinking I was mainly going to learn Amazon Bedrock AgentCore. I did, but I ended up learning several things around it too. I learned how an AI agent can use tools to interact with backend systems, how a Knowledge Base can give an agent access to application-specific information, how Memory changes what a conversation can mean across sessions, and why precise calculations sometimes belong in code rather than in the model's reasoning.

I also learned that IAM isn't something you set up once and forget about, that a successful deployment doesn't prove every capability works, that monitoring matters even for a relatively small project, and that cloud development includes knowing how to clean up what you create.

I don't think the biggest lesson I am taking into my next project is one specific AWS service. It is a way of approaching projects that initially look too big.

When I see a complicated architecture now, I don't immediately think:

“I need to understand everything.”

I think:

“What is the first piece?”

Then I work from there.

That doesn't mean the project suddenly becomes easy. There are still confusing moments, permissions to figure out, code to debug, and configuration to understand. Sometimes you understand a service after reading about it. Sometimes you understand it after using it. And sometimes you understand it only after something breaks and you have to figure out why.

All three are learning.

So if you're somewhere at the beginning of your own AI or cloud journey and you're looking at a project that feels like too much, start with one thing. Understand what it is supposed to do. Make that part work. Then move to the next.

You don't have to build the entire system in your head before you build it in reality.

And that is probably the thing I value most from this project.

I learned how to make a complicated project feel manageable.

Not by making the project smaller.

By making the next problem smaller.

A Small Thank You

I want to thank Udacity and everyone involved in the Future AWS Agent Engineer Nanodegree Program for giving me the opportunity to work through a project like this. And I'm especially grateful for the AWS AI & ML Scholarship that made the program possible for me.

This project gave me something I don't think I would have understood as clearly by only reading about AgentCore. I had to actually connect the pieces, troubleshoot them, and test them. Eventually, I could look back at the architecture and realize that I understood what I was looking at.

That was probably the most valuable part for me.

I Would Love to Hear From You

If you've built an AI agent, worked with AWS, or are currently learning cloud engineering, I'd genuinely love to hear from you.

What was the first cloud or AI concept that felt completely confusing at first, but eventually started making sense to you? Or, if you're currently building something difficult, what part are you working through right now?

Share it in the comments.

Sometimes the thing that feels obvious to you now is exactly the thing someone else is struggling to understand.

🤝 Let's Stay Connected

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

Dev Opportunity Radar #18: $50K AI Hackathon, SheBuilds, Verci Fellowship, and Stanford CS336

Hemapriya Kanagala — Fri, 25 Sep 2026 17:48:13 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features the Verci Fellowship, Nebius x NVIDIA Global AI Hackathon, and SheBuilds on Lovable, along with Stanford CS336: Language Modeling from Scratch, a course for understanding how language models are built from the ground up.

If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

This week's 🌟 Community Finds section features two opportunities shared by Dhruv Jani (@dj29). Thank you, Dhruv, for sharing the Snapdragon® AI Lab Build & Present Challenge and the SerpApi India Hackathon 2026. I always enjoy seeing readers help others discover opportunities they might otherwise have missed, and I hope this section continues to grow.

If you've discovered something through the Radar, I'd love to hear about it. Whether you applied to an opportunity, attended an event, joined a community, completed a program, built something, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission).

And if you've come across an opportunity, resource, community, program, event, or anything else you think deserves more attention, feel free to share it in the comments.

If I feature one of your 🌟 Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan
🔄 Still Open From Previous Editions
📍 This Week's Opportunities
- 📌 Verci Fellowship
- 📌 Nebius x NVIDIA Global AI Hackathon
- 📌 SheBuilds on Lovable
📚 Resources Worth Checking Out
- Stanford CS336: Language Modeling from Scratch
🌟 Community Finds
- 📌 Snapdragon AI Lab Build & Present Challenge
- 📌 SerpApi India Hackathon 2026
💙 Reader Updates
👋 Until Next Friday
🌐 Dev Opportunity Radar Website

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Format	Deadline
Verci Fellowship	Verci	Fellowship	Hybrid	October 1
Nebius x NVIDIA Global AI Hackathon	Nebius × NVIDIA	Hackathon	Online	October 30
SheBuilds on Lovable	Lovable	Build Event	Virtual	September 27

Resource Highlight

Resource	Why Check It Out
Stanford CS336: Language Modeling from Scratch	An advanced course covering the process of building language models from the ground up, including Transformers, training, GPU optimization, scaling, data, evaluation, and alignment.

Community Finds

Shared By	Find	Type	Format
Dhruv Jani (@dj29)	Snapdragon AI Lab Build & Present Challenge	AI Challenge	Online
Dhruv Jani (@dj29)	SerpApi India Hackathon 2026	Hackathon	Online & Async

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please take a few minutes to visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

Opportunity	Organization	Type	Format	Deadline	Featured In
Code in Place X	Stanford University	Programming Course	Virtual	September 28	Edition #17
Build, Ship, Shape: Amazon Developer Hackathon	Amazon	Hackathon	Online	October 24	Edition #17
Dev3Pack Hackathon	Dev3Pack	Hackathon	Hybrid	October 30	Edition #17
AI for Education Fellowship	Worldwide Studios	Fellowship	Virtual (Global)	Rolling	Edition #16
AWS Student Rewards	AWS Builder Center	Student Rewards Program	Online (Global)	Open	Edition #16

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 Verci Fellowship

Who it's for: Young builders, students, recent graduates, and people building projects or communities.

What it's about: The Verci Fellowship is a one-semester program bringing together 20 people who are building startups, projects, and communities.

The fellowship focuses heavily on community and mentorship. Each fellow is matched with a mentor, joins a small weekly mastermind group, and gets access to office hours and workshops with founders, operators, and investors.

There is also a Catskills retreat in November where the cohort spends a weekend together, along with support for fellows who want to organize things in their own communities such as hackathons, dinners, or demo nights.

Another part I found interesting is the focus on building in public. The program includes workshops and accountability groups to help fellows share what they are working on and actually ship something during the semester.

The fellowship is open to people who are currently in college, on leave, dropped out, or recently graduated, with the program looking for people roughly under 24 who have a strong interest in technology, are creative and curious, and are already building things on campus or in their communities.

Applications are rolling, but the current application form says applications close on October 1, 2026 at midnight PST.

Format: Hybrid / Online + New York and LA opportunities

Cohort: 20 fellows

Program: October – December 2026

Application Deadline: October 1, 2026 at midnight PST

Eligibility: Currently in college, on leave, dropped out, or recently graduated; roughly under 24

What you get: Individual mentorship, weekly mastermind groups, workshops and office hours, Catskills retreat, community/event support, cohort Slack, building-in-public support, and optional opportunity matching

Application: Name and background + social profiles + semester schedule + work/portfolio + short answers + 1–2 minute personal video

🔗 Apply to the Verci Fellowship

📌 Nebius x NVIDIA Global AI Hackathon

Who it's for: AI builders, ML engineers, developers, founders, and anyone interested in building practical AI systems.

What it's about: The Nebius x NVIDIA Global AI Hackathon is a global online hackathon where participants build an AI project using NVIDIA open source models on Nebius Token Factory or Nebius AI Cloud.

There are four main tracks, so you can choose the type of project that fits what you want to build:

Coding and Agentic Engineering: Build coding agents and developer tools.
Best Apps and Agents: Build an application or agent designed to solve a real problem.
Personal AI: Build a private, always-on AI assistant with memory, skills, and access to your chosen tools and information.
Physical AI: Build robotics, IoT, or other systems that can sense and act in the physical world.

The main requirement is that your submission runs on Nebius Token Factory or Nebius AI Cloud and uses at least one NVIDIA open source model.

I wanted to include this one because there is quite a bit of room in what you can build. You can work on an AI agent, developer tool, personal assistant, application, robotics project, or something else that fits one of the tracks.

There are also Builders & Brews events in different cities where participants can join technical onboarding, workshops, team formation, build sessions, and get feedback while working on their projects.

For the submission, you'll need a working project, public code repository, project description, working demo or test build, and a public demo video of three minutes or less. Your repository also needs an open source license and setup instructions.

There is $50,000+ in prizes, including a $20,000 grand prize, $10,000 for second place, $6,000 for third place, track prizes, city awards, and additional prizes.

Format: Online | Global

Deadline: October 30, 2026 at 10:30 PM IST

Tracks: Coding & Agentic Engineering | Best Apps & Agents | Personal AI | Physical AI

Requirement: Use Nebius Token Factory or Nebius AI Cloud + at least one NVIDIA open source model

Submission: Working project + public repository + demo + ≤3-minute demo video

Prize Pool: $50,000+ in prizes

🔗 Join the Hackathon

📌 SheBuilds on Lovable

Who it's for: Women 18+ who have an idea they want to turn into a working product, including students, first-time makers, founders, and experienced developers.

What it's about: SheBuilds on Lovable is a global community of women building with AI through virtual build events, webinars, and community spaces.

Season 04 is a 72-hour virtual build event where participants use Lovable to turn an idea into a working product alongside mentors, community champions, and a few hundred other builders.

You don't need to know how to code to apply. You can come with an idea, sketches, research, or a plan, and the actual building starts when the event kicks off.

You can participate solo or with one co-builder. Around 400 participants are expected to be selected for this season.

There are also live prep sessions from October 6–14 covering things like figuring out what to build, making your product stand out, and getting it in front of people. Accepted participants also get Lovable credits to use during the build.

The build starts on October 15 and submissions close on October 17. The organizers will announce the prizes at kickoff, so the prize details for Season 04 have not been announced yet.

Format: Online | 72-hour build event

Build Dates: October 15–17, 2026

Applications Close: September 27, 2026 at 11:59 PM PT

Decisions: October 5, 2026

Eligibility: Women 18+ with an idea they want to build

Team Size: Solo or 1 co-builder

Cost: Free | Coding Required: No

Expected Cohort: Around 400 participants

Prep Sessions: October 6–14

Prizes: To be announced at kickoff

🔗 Apply for Season 04

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

Stanford CS336: Language Modeling from Scratch

If you want to go beyond using LLMs and actually understand how language models are built, Stanford's CS336: Language Modeling from Scratch is a really interesting resource to explore.

The course walks through the process of building language models from the ground up, including data collection and cleaning, tokenization, Transformer architecture, training, GPU optimization, scaling, evaluation, inference, alignment, and reasoning.

What makes this course different is how implementation-heavy it is. The assignments have students actually build components of a Transformer language model, train a small language model, optimize attention with Triton, work with distributed training, process pretraining data, and apply post-training methods such as supervised fine-tuning and reinforcement learning.

The course provides lecture recordings, assignments, lecture materials, and code, so you can follow along even if you're not enrolled at Stanford.

One important thing to know before jumping in: this is an advanced course. The course expects proficiency in Python, experience with deep learning and systems optimization, familiarity with PyTorch, and a foundation in calculus, linear algebra, probability, statistics, and machine learning.

You will also be writing a lot of code, so this is much more suitable if you already have a solid technical foundation and want to understand the engineering behind language models.

Format: Self-paced online resource

Focus: Language models, Transformers, training, systems optimization, scaling, data, evaluation, alignment, and reasoning

Level: Advanced

Prerequisites: Python + PyTorch/deep learning + systems optimization + calculus + linear algebra + probability/statistics + machine learning

Includes: Lectures + recordings + assignments + code + course materials

🔗 Explore the CS336 Course Website

🎥 Watch the Lecture Recordings

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

This week, Dhruv Jani (@dj29) sent me two opportunities that I thought were worth including:

📌 Snapdragon AI Lab Build & Present Challenge

Shared by Dhruv Jani

The Snapdragon® AI Lab Build & Present Challenge by Qualcomm is an individual online challenge for participants in India to build or propose an AI solution designed, developed, or optimized for Snapdragon-powered HP PCs.

You can submit a new project or significantly modify an existing project by adding AI models from Qualcomm AI Hub or other open-source platforms.

The challenge is open to Indian residents aged 18+ who own a Snapdragon-powered laptop.

Format: Online | Individual

Deadline: September 30, 2026 at 11:59 PM IST

Eligibility: India residents, 18+

Requirement: Snapdragon-powered laptop

Rewards: HP laptops, Qualcomm internship opportunity for the first award subject to eligibility, executive mentorship, and showcase opportunities

🔗 Learn More & Apply

📌 SerpApi India Hackathon 2026

Shared by Dhruv Jani

The SerpApi India Hackathon 2026 is an online and asynchronous hackathon where participants can build an app, AI agent, or open-source integration using live search data from SerpApi.

You can participate solo or in a team of up to five, use any programming language or framework, and work from anywhere in India. Existing projects are also allowed if the submitted version makes meaningful use of SerpApi.

There are six project tracks, and AI-assisted development is allowed.

The total prize value is ₹3 lakh+, including cash awards, SerpApi credits, track awards, community awards, and credits for every valid submission.

Format: Online & asynchronous

Deadline: October 10, 2026 at 11:59 PM IST

Eligibility: India residents, 18+

Team Size: 1–5 members

Requirement: Meaningful use of SerpApi search data

Prize Value: ₹3 lakh+

Submission: Public GitHub repository + project description + demo video under 3 minutes

🔗 Submit Your Project

Thank you to Dhruv Jani (@dj29) for thinking of the Radar and sharing this one with the community. It really means a lot 💙

I'd love for this section to keep growing.

If you've come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, feel free to share it in the comments.

If I feature it in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

What DEV Series Are You Reading or Writing? Let’s Make Them Easier to Find

Hemapriya Kanagala — Wed, 23 Sep 2026 18:37:32 +0000

TL;DR

DEV has so many interesting series, but they can be easy to miss when we don't follow the author or happen to come across a post at the right time.

Until we have a dedicated way to discover series, I thought we could use this thread to share the series we are writing or reading so more people can find them.

If you're writing a series: Share the title, a short introduction, its status (ongoing or completed), and the link.

If you're reading a series: Share the title, what you find interesting about it, and the link.

If you're planning a series but haven't started yet, bookmark this thread and come back when you publish the first part.

You can share as many series as you want. There are no limits here 😄

A Small Problem I Keep Noticing
So, Let’s Share Them Here
Until DEV Has a Dedicated Series Section

A Small Problem I Keep Noticing

There are many great series on DEV. Some are educational, some document a learning journey, some explore a specific technology, and others are simply fun to follow.

But finding these series consistently can be difficult. Unless we follow the author, discover one of their posts, or happen to see it in our feed, we might never know that the series exists.

And by the time we discover it, several parts may already be published. I know I have probably missed some really interesting series simply because I didn't know they were there.

So, Let’s Share Them Here

If you're writing a series, feel free to share it in the comments. You can include the series title, a short introduction about what it covers, whether it is ongoing or completed, and a link to the series or its first article.

If you're reading a series that you think others might enjoy, share that too. Tell us what makes it interesting or what you've learned from it.

If you're planning to start a series, you can bookmark this thread and come back once you've published the first part. That way, people can discover it early and follow along as you continue writing.

You can share as many series as you want. There are no limits here 😄

Until DEV Has a Dedicated Series Section

I remember @dj29 raising an issue in the Forem repo about a possible series discovery feature, so fingers crossed that we get something like that in the future 🤞

I know DEV already has so many great features, and I also understand that building something new takes time and effort. This is not meant as a complaint at all. I'm always grateful to the DEV team for creating and maintaining a space where we can learn, write, and connect with each other.

Until then, maybe we can use this thread as our own little discovery space. There are probably many series worth reading that we simply haven't found yet.

What series are you writing or reading right now? Share them below so we can discover something new together.

Dev Opportunity Radar #17: $138K Amazon Hackathon, Stanford's Code in Place X, and Dev3Pack Hackathon

Hemapriya Kanagala — Fri, 18 Sep 2026 16:44:35 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features Code in Place X, the Build, Ship, Shape: Amazon Developer Hackathon, and the Dev3Pack Hackathon, along with Coding Interview University, a free study plan for software engineering and technical interview preparation.

If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

This week's 🌟 Community Finds section features an opportunity shared by Dhruv Jani (@dj29). Thank you, Dhruv, for sharing the Dogfood | 72-Hour Hackathon. I always enjoy seeing readers help others discover opportunities they might otherwise have missed, and I hope this section continues to grow.

If you've discovered something through the Radar, I'd love to hear about it. Whether you applied to an opportunity, attended an event, joined a community, completed a program, built something, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission).

And if you've come across an opportunity, resource, community, program, event, or anything else you think deserves more attention, feel free to share it in the comments.

If I feature one of your 🌟 Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan
🔄 Still Open From Previous Editions
📍 This Week's Opportunities
- 📌 Code in Place X
- 📌 Build, Ship, Shape: Amazon Developer Hackathon
- 📌 Dev3Pack Hackathon
📚 Resources Worth Checking Out
- Coding Interview University
🌟 Community Finds
- Dogfood: 72-Hour Hackathon
💙 Reader Updates
👋 Until Next Friday
🌐 Dev Opportunity Radar Website

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Format	Deadline
Code in Place X	Stanford University	Programming Course	Virtual	September 28
Build, Ship, Shape: Amazon Developer Hackathon	Amazon	Hackathon	Online	October 24
Dev3Pack Hackathon	Dev3Pack	Hackathon	Hybrid	October 30

Resource Highlight

Resource	Why Check It Out
Coding Interview University	A free, self-paced study plan covering data structures, algorithms, computer science topics, coding practice, and software engineering interview preparation.

Community Finds

Shared By	Find	Type	Format
Dhruv Jani (@dj29)	Dogfood	72-Hour Hackathon	Software Development Hackathon

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please take a few minutes to visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

Opportunity	Organization	Type	Format	Deadline	Featured In
AI for Education Fellowship	Worldwide Studios	Fellowship	Virtual (Global)	Rolling	Edition #16
AWS Student Rewards	AWS Builder Center	Student Rewards Program	Online (Global)	Open	Edition #16
Bharat Builds Tour	WeMakeDevs × AWS Builder Center	Student Hackathon Series	Online (India) / In Person	September 17–20	Edition #15

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 Code in Place X

Who it's for: Anyone 18+ who wants to learn programming, or people who already know Python and want to volunteer as a teacher.

What it's about: Code in Place X is a new free course from Stanford that teaches programming while also helping students practice explaining what they build.

The course is six weeks long and you'll meet every week on Zoom with a small group of students and a volunteer teacher who will guide you through the material. You don't need any previous programming experience, and the course is completely free.

I wanted to include this one because I like that it is not only about writing code. Students also get to practice explaining their thinking and what they built, which is a useful skill whether you're learning programming for the first time or already working with AI coding tools.

The course also has an interesting approach to AI. Students can use AI as part of their learning, but they are expected to come to their weekly section ready to show what they learned and share how they are using AI. So the course is also exploring what it means to learn programming when AI can already write a lot of code for us.

There is also a volunteer teacher option. If you already know how to write a simple Python program and can explain your thinking, you can apply to lead a small group. You don't need to be a professional engineer or have teaching experience. Teachers spend around 4 hours per week and receive lesson plans and section problems to work with.

The course itself takes around 7 hours per week for students and begins on October 12, 2026.

Format: Online | Duration: 6 weeks

Class Begins: October 12, 2026

Orientation: October 7, 2026

Time Commitment: Around 7 hours/week for students | Around 4 hours/week for volunteer teachers

Cost: Free

Eligibility: 18+ | No prior programming experience required for students

Applications Close: September 28, 2026

Language: English

🔗 Learn More & Apply

📌 Build, Ship, Shape: Amazon Developer Hackathon

Who it's for: Developers, students, AI builders, and anyone interested in building applications for Amazon devices and services.

What it's about: The Build, Ship, Shape: Amazon Developer Hackathon brings Fire TV, Alexa+, Bee, and Ring together in one global hackathon. You can choose one of the four tracks and build a working project using the developer tools, APIs, SDKs, or simulators for that track.

I wanted to include this one because there are quite a few different ways to approach the challenge. You can build for Fire TV, Alexa+, Bee, or Ring, depending on what you're interested in. There are also additional AWS Builder and Open Source mini challenges that you can enter alongside your main track.

For example, the Fire TV track lets you build an app using React Native, web technologies, Android, or another framework that runs on Fire OS or Vega OS. The Alexa+ track focuses on building an MCP server or Agent Skill, while Bee projects use data from a Bee device or Apple Watch running Bee software. Ring projects can use Ring APIs, SDKs, simulators, or devices.

You also don't necessarily need to already have experience with Amazon's developer tools. The hackathon provides documentation, sample code, simulators, and live office hours to help participants get started.

The submission needs to include a working project, GitHub repository, and a demo video under three minutes, along with product feedback on the Amazon tools you used.

There is a $138,000 cash prize pool, with prizes across the four main tracks and the AWS Builder and Open Source mini challenges. Track winners also receive a 1:1 meeting with the Amazon Developer team, depending on the track.

One thing to check before choosing your project is the specific requirements for each track. Some tracks require you to actually use the relevant technology in your code or demo, so simply mentioning a particular Amazon service isn't enough.

Format: Online | Global

Deadline: October 24, 2026 at 12:30 AM IST

Team Size: Not specified in the information provided

Main Tracks: Fire TV, Alexa+, Bee, Ring

Mini Challenges: AWS Builder, Open Source

Prize Pool: $138,000 in cash + additional AWS credits and other prizes

Submission: Working demo + GitHub repository + under-3-minute demo video + product feedback

Eligibility: Above the legal age of majority in your country of residence | Global, subject to standard country/territory exclusions

🔗 Learn More & Join the Hackathon

📌 Dev3Pack Hackathon

Who it's for: University students and student builders interested in building on Solana. You can participate solo or in a team of up to four.

What it's about: Dev3Pack Hackathon is a three-day hybrid hackathon where students from around the world can build on Solana, either online or at one of the local build stations.

The hackathon runs from October 30 to November 1, 2026, but there is also a free Solana Rust Bootcamp running from October 6 to 30. So if you're new to Rust or Solana, you can use the weeks before the hackathon to learn and get ready.

I wanted to include this one because it has a little more of a community and learning side than just the three-day hackathon. You can join a local build station if there is one near you, meet other students and mentors, or participate completely online if you prefer.

There are currently 40+ build stations listed around the world, including Mumbai, along with locations across Asia, Africa, Europe, and the Americas.

The project needs to be open source and must use Solana if you want to be eligible for prizes and the accelerator. You can also use AI coding tools while building, as long as the project is yours and you understand and can explain what you built.

After the hackathon, top teams can be invited to the Bridge Accelerator, which runs from November through January. The exact prize tracks and amounts for this edition are still to be announced.

There are also some builder perks available to participants, including Noah AI credits, v0 credits, and Cursor Pro for select countries, along with other perks listed in the participant dashboard.

Format: Hybrid | Online or local build station

Dates: October 30 – November 1, 2026

Preparation: Solana Rust Bootcamp | October 6–30

Duration: 3 days

Team Size: Solo or up to 4 members

Location: Worldwide | 40+ build stations

Cost: Free

Project Requirement: Open source + Solana

AI Tools: Allowed

Prizes: Tracks and prize amounts to be announced

After the Hackathon: Top teams can be invited to the Bridge Accelerator

🔗 Learn More & Apply

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

Coding Interview University

If you're preparing for software engineering interviews and don't know where to start, Coding Interview University is a free study plan that puts a lot of the topics you need to learn in one place.

It covers things like data structures, algorithms, Big-O, trees, graphs, sorting, dynamic programming, networking, and coding interview practice. It also has sections on resumes, finding a job, interview preparation, and other parts of the interview process.

What I like about this resource is that it gives you a path to follow instead of just giving you a list of random topics. You can go through the topics step by step and practice coding problems along the way.

There are also a lot of free resources linked throughout the plan, including videos, books, courses, and coding practice sites.

It is a pretty big study plan though, so you definitely don't need to finish everything. You can pick the parts that make sense for where you are in your interview preparation.

Format: Free, self-paced study plan

Covers: Data structures, algorithms, coding problems, computer science topics, and interview preparation

🔗 Explore Coding Interview University

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

Dogfood: 72-Hour Hackathon

Shared by Dhruv Jani (@dj29).

Dhruv shared the Dogfood | 72-Hour Hackathon by Hackathon Raptors, and I thought this was an interesting one to include because the challenge itself is quite different from a usual hackathon.

Instead of letting everyone build different projects, everyone is working on the same product: an open-source, self-hostable platform for running hackathons, including registration, team formation, submissions, judging, scoring, and results.

What I found interesting is that the goal isn't just to build a working demo. The winning project will be forked, self-hosted, and used for future Hackathon Raptors events. Teams also keep ownership of their work.

The technical requirements are quite specific too. The platform needs to run locally with docker compose up and work without a hosted database, external API, cloud account, or network connection. The challenge also covers things like role isolation, judging, score normalization, voting, APIs, testing, and documentation.

There are four tiers to work through, but you don't have to try to build everything. The organizers mention that a clean and correct lower tier is better than a broken higher tier, which I thought was a good approach for a 72-hour challenge.

Who it's for: Developers, students, engineers, open-source contributors, and anyone interested in software development, backend systems, APIs, DevOps, security, or data and algorithms.

Format: Online

Duration: 72 hours

Event Date: September 25–28, 2026

Team Size: 1 to 4 participants

Prize Pool: ₹2,50,000

🔗 Learn More & Register

Thank you to Dhruv Jani (@dj29) for thinking of the Radar and sharing this one with the community. It really means a lot 💙

I'd love for this section to keep growing.

If you've come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, feel free to share it in the comments.

If I feature it in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

What Happens When AI Outgrows the Tests We Use to Measure It?

Hemapriya Kanagala — Mon, 14 Sep 2026 17:12:10 +0000

TL;DR

GPT-6 Astra has started another familiar AI conversation. The model is more capable, Jensen Huang said on X that "AGI has arrived," and social feeds quickly moved between excitement, curiosity, and fear about what comes next.

I understand why the reactions are strong. AI is changing quickly, and some of the things these models can do now would have sounded surprising not long ago. But I have also noticed how quickly "AI is becoming much more capable" can turn into "developers will not be needed" or "CSE is finished." That feels like a much bigger conclusion.

For me, Astra raises another question that is easier to miss:

How do we actually know an AI model is getting better?

We usually look at benchmarks, and they are useful. But benchmarks can age too. Some become saturated, some use proxies for capabilities that are difficult to measure directly, ground truth can be complicated, and evaluation methods can change. A benchmark score also does not automatically tell us how useful a model will be for our own work.

Astra's system card gives several examples of this, including older evaluations becoming saturated or being considered for retirement, newer evaluations using more realistic or experimental data, and evaluation methods changing over time.

That matters for developers too. If AI makes writing code cheaper and faster, software engineering does not suddenly disappear. Requirements, architecture, system design, security, verification, tradeoffs, maintenance, and deciding what should actually be built still matter.

AI will change the work. I think that part is pretty clear.

The more useful question is what we do with that change, and whether we are measuring AI well enough to understand what is actually happening.

Another AI launch, and the conversation gets loud very quickly
A benchmark gives us a number. What does the number really tell us?
Every benchmark has a lifespan
92% according to what?
The number can change because the test changed
One answer is starting to tell us less
So what should we look at when we see a benchmark?
What does all of this mean for developers?
We can take AI seriously without making every headline the final answer
The models are changing. Our way of looking at them has to change too.
I Would Love to Hear From You
References
🤝 Let's Stay Connected

Another AI launch, and the conversation gets loud very quickly

Whenever a major AI model arrives, there seems to be a familiar sequence. The model launches, people try it, benchmark results appear, comparisons start, and then the bigger questions arrive.

With Astra, NVIDIA CEO Jensen Huang also said on X that "AGI has arrived" while congratulating OpenAI on the launch.

As you would expect, people started interpreting that statement in very different ways. Some saw it as a major milestone, some questioned whether Astra actually meets their definition of AGI, and others immediately started thinking about what this could mean for jobs and software development.

From what I have been seeing in my own feed, there is also a lot of fear around where developers fit into all of this.

I am not saying fear is wrong. There are real risks with increasingly capable AI, and I think those risks deserve serious attention.

But I think there is a big difference between saying "this technology is changing quickly" and saying "developers are no longer needed" or "there is no need for CSE anymore."

That feels like a much bigger conclusion to draw from a capability improvement.

Software development will change. There is very little doubt about that. But when producing code becomes easier, other parts of the work can become more important too.

Understanding the problem, designing the system, making architecture decisions, working through requirements, thinking about security and reliability, verifying what was produced, understanding tradeoffs, and knowing when an AI-generated solution is simply the wrong solution are all still part of building software.

None of those become less important just because writing the code becomes faster.

So while everyone is asking how capable the new model is, I started wondering about something slightly different:

How are we actually measuring that capability?

A benchmark gives us a number. What does the number really tell us?

There is something very convenient about benchmarks. You see Model A at 82% and Model B at 88%, and it suddenly feels like we have a clear answer about which one is better.

And honestly, benchmarks are useful. Without them, comparing AI systems would be much harder. Having a common test gives us a starting point, and that is valuable.

The part that is easy to forget is that a benchmark is a measurement tool. It gives us evidence about a model's capability, but it is not the capability itself.

Think about a thermometer. It tells you the temperature, but the thermometer is not the temperature. In the same way, a benchmark can tell us something about what a model can do, but it cannot capture everything the model is capable of doing in the real world.

And this becomes more important as models improve, because the test itself can eventually become less informative.

A benchmark that once showed a clear difference between models might eventually have almost every strong model scoring near the top. At that point, the number is still a number, but it may not tell us as much as it used to.

Every benchmark has a lifespan

One of the things I found interesting in Astra's system card is how openly it talks about evaluations changing over time. Some earlier evaluations have become relatively saturated, some are being considered for retirement, and newer evaluations are being introduced because the older ones may no longer give enough signal.

That actually makes a lot of sense. Imagine a test where the strongest models are now scoring 97%, 98%, and 98%. Those are obviously impressive results, but if most capable models are already close to the ceiling, how much are we really learning from that one percentage point?

The benchmark may not have become bad. It may have simply reached the point where it is no longer good at showing the differences we care about.

In a way, that means the benchmark did its job. It helped us see progress when the models were still further away from the ceiling, and now the models have moved far enough that we need a different way to separate them.

So when I see an evaluation being retired or replaced, I do not necessarily see that as a failure of the benchmark. Sometimes it is actually a sign that the technology has moved forward.

The models moved, so the test needs to move too.

And I think that idea is going to matter more and more as AI systems keep getting better.

92% according to what?

This is probably my favorite question to ask when I see a benchmark score.

92% according to what?

For some tasks, the answer is easy. A math problem has a known answer. A programming problem can be checked with tests. A factual question can often be compared against a trusted source.

But things get more complicated when we are evaluating scientific reasoning, biological predictions, or longer tasks where there may not be one obvious correct answer.

That is where ground truth comes in. In simple terms, ground truth is the answer or evidence we treat as the correct reference when we evaluate a model. Depending on the problem, it might come from experts, experimental data, a simulation, or some other trusted source.

And sometimes we cannot directly measure the capability we care about, so we use a proxy. A proxy is something we can measure that is expected to tell us something about a harder-to-measure capability.

Astra's system card gives an example from biology. One of its evaluations looks at AAV capsid packaging prediction. AAV stands for adeno-associated virus, and a capsid is the protein shell around a virus. In this evaluation, the model is asked to predict how well different capsids may perform in packaging. The result is being used as a proxy for certain broader biological design capabilities.

Using a proxy is not automatically a problem. In many areas, it is simply a practical way to measure something that would otherwise be very difficult or expensive to test directly.

But there is an important difference between saying "the model got better at this prediction" and saying "the model got better at the real-world capability this prediction represents."

Those two things can be connected without being exactly the same.

The system card also discusses a related issue with BPNet, a model used to make biological predictions. If the predictions from the original system contain errors or assumptions, using those predictions as the test's reference can create a strange situation where a future AI system might become better at reproducing those patterns without necessarily becoming better at the underlying biological task we actually care about.

That is a subtle measurement problem, but it is an important one.

The score can be real, the improvement can be real, and we can still have questions about what that improvement actually represents.

This is also why Astra's newer biological evaluations using unpublished experimental data and wet-lab-validated evidence are interesting. Wet-lab validation basically means the results have been checked through actual laboratory experiments rather than relying only on a computational prediction. That gives the evaluation a closer connection to the real-world behavior it is trying to measure.

So when I see a benchmark saying 92%, I am still interested in the number.

I just want to know what is behind it.

92% according to what?

The number can change because the test changed

There is another part that can easily get lost when we look at benchmark charts: the test itself can change.

A benchmark score does not appear on its own. There is a dataset behind it, instructions for the model, a way of grading the answer, a scoring method, and sometimes specific tools or model settings. If any of those things change, the meaning of the final number can change too.

Astra's system card points this out directly. Policies, graders, datasets, evaluations, and other measurement details can evolve over time, which means older results should generally not be treated as directly comparable to newer ones without looking at what changed.

So when we see something like:

Model A: 90%
Model B: 95%

the five-point difference might be meaningful. But before using it to make a big claim about one model being much better than another, it is worth checking whether both numbers came from the same kind of evaluation setup.

There is even a smaller detail that can affect some results: the length of the answer.

In some open-ended evaluations, a longer answer can have more opportunities to satisfy the different things a grader is looking for. That means a model could potentially score better simply because it said more, even when a shorter answer might have been more useful to a person. Astra's system card discusses this issue and reports length-adjusted scores for some evaluations to account for it.

It may sound like a small technical detail, but these are exactly the kinds of details that matter when we are trying to understand what a benchmark score is really telling us.

The number is important.

But the way we arrived at the number matters too.

One answer is starting to tell us less

There is also a change happening in how we actually use AI. We are not only asking a question and waiting for an answer anymore. AI systems can work through multi-step tasks, use tools, interact with software, deal with incomplete instructions, and adjust when the requirements change.

Astra's launch material talks about this kind of behavior too. It describes the model handling ambiguity better, asking focused questions when an answer could change the outcome, and continuing with other work while waiting for a response. When the decision is more consequential, it can wait for the user's input instead of simply guessing.

That kind of behavior is difficult to capture with one isolated question.

If I am asking an AI system to help with a 30-minute workflow, I probably care about much more than whether it got one answer right. Did it understand what I was actually trying to do? Did it make reasonable decisions along the way? Did it handle a requirement that changed halfway through? If something went wrong, could it recover? And at the end, did the result actually work?

The Astra system card also includes more realistic workplace-style evaluations involving computer and browser tasks, ambiguous instructions, and complex permissions.

That feels closer to how many of us experience AI now.

A model can be excellent at answering individual questions and still struggle when it has to carry a task from beginning to end. The opposite can also happen. A system may not look extraordinary on one isolated benchmark but perform surprisingly well when given the tools and context it needs.

That is why I think the evaluation question is slowly changing too.

Instead of only asking "Did the model get the answer right?", we may also need to ask "How well did it handle the whole task?"

And that is a much harder thing to measure.

So what should we look at when we see a benchmark?

I do not think we need to become experts in evaluation methodology every time a new model launches. But there are a few questions that can make a benchmark score much easier to understand.

1. What is actually being measured?

Is the benchmark measuring the capability we care about, or is it using a proxy, something that is expected to tell us about that capability?

2. Is the benchmark still difficult?

If most strong models are already close to the top score, the benchmark may have become saturated, meaning it is no longer giving us much room to see meaningful differences between models.

3. Where does the ground truth come from?

What are we treating as the correct answer? Is it a fixed answer, expert judgment, another model, a simulation, or real-world evidence?

4. Did the evaluation change?

Did the dataset, grader, scoring method, prompts, tools, or model setup change? Even small changes can affect how we should interpret the final number.

5. Does the result transfer to the work I actually care about?

This one is especially useful if you are a developer. A model can perform extremely well on a general coding benchmark and still not be the best model for your actual codebase, team, or workflow.

For that, your own small evaluation can be surprisingly useful.

Take 20 or 30 real tasks from your workflow and try the models on them. Then look at the things that actually matter to you. Did the code work? Did the model understand the requirements? How did it handle changes? How much did you have to correct? Could it recover when something went wrong? How long did it take, and what did it cost?

You do not need to throw away the big benchmark scores. They can still give you a useful general picture.

Your own tasks simply add another piece of evidence, and sometimes that is the piece that matters most.

What does all of this mean for developers?

This is where the benchmark discussion connects back to something I have been seeing a lot around Astra: "AI will replace developers."

I can understand why people are asking that question. If a model can write code, understand a codebase, use tools, work through a task, and handle changes along the way, it is reasonable to wonder what software development will look like a few years from now.

I do expect the work to change. Some things will become much faster, some tasks may need less human effort, and there will probably be skills that become less important as the tools improve. At the same time, other skills can become more important.

If producing code becomes much easier, for example, the difficult part may move toward understanding what should actually be built and how it should be built.

What are the real requirements? What constraints do we have? How should the system be designed? Will the architecture hold when the system grows? Is the solution secure and reliable? How do we verify what the AI produced? What happens when the requirements change six months from now? And does the whole thing actually solve the user's problem?

These questions do not disappear because an AI can produce hundreds of lines of code quickly.

In some cases, they may become even more important because producing several possible implementations becomes easier. Someone still has to understand the options and decide which one makes sense for the situation.

That is why the idea that "CSE is no longer needed" feels too extreme to me. Computer science and software engineering have always been about more than writing code. Code is one part of building software, not the entire process.

There will definitely be changes, and some of those changes may be significant. But I would rather watch how the work actually evolves than decide too early that the whole field is going away.

Maybe the more useful question for developers is not "Will AI replace me?", but "As AI takes over more of the work, what should I become better at?"

We can take AI seriously without making every headline the final answer

I do not want to dismiss the concerns around AI. There are genuine questions around safety, misuse, security, reliability, employment, and how much autonomy we should give these systems. Those are not small questions, and they deserve serious attention as the technology becomes more capable.

At the same time, I do not think every capability improvement needs to turn into a prediction about the end of a profession. When I see that AI can write code, I see a technology that is changing software development. I do not think the only possible conclusion is that developers are finished.

The same goes for increasingly complex AI systems. Instead of jumping straight to whether humans will be needed, I find it more useful to ask which parts of the work we can trust AI with, where we still need people involved, and what kind of oversight makes sense.

And when I see a benchmark score go up, I want to understand what is behind that number too. What was tested? How was it tested? Is the benchmark still giving us a useful signal? Does that improvement show up in the kind of work people actually do?

For me, that makes the conversation more interesting. We can be excited about what these models are doing and still question the claims around them. We can take the risks seriously without assuming the most extreme outcome, and we can recognize real progress without treating every new headline as the final answer.

There is probably a lot we still do not know about where all of this is going.

And that is okay. We are watching it change in real time.

The models are changing. Our way of looking at them has to change too.

That is probably what I keep coming back to with Astra. The model is becoming more capable, but at the same time, measuring that capability is getting more complicated. Benchmarks can saturate, proxies have limits, ground truth is not always simple, and evaluation methods have to keep evolving too.

Maybe our questions need to evolve along with them.

Instead of only asking "Will AI replace developers?", we can ask "Which parts of development are changing, and what skills are becoming more valuable?"

Instead of "Is CSE dead?", we can ask "What does computer science look like when producing code becomes much easier?"

And instead of only asking "Is AGI here?", we can ask "What capabilities are we actually talking about, how are we measuring them, and what evidence do we have?"

We are going to keep seeing stronger models, impressive demos, and very strong opinions around them. Some predictions will probably turn out to be right, some will go too far, and some things will surprise all of us.

That is part of watching a technology change this quickly.

For me, the useful thing is to stay curious, look at the evidence, take the risks seriously, and also pay attention to what is actually changing in the work we do.

Because after all the benchmarks, headlines, and predictions, maybe the question worth asking is simply:

"What changed, how do we know, and what does that mean for the work we care about?"

And then:

"Okay. This is what the technology can do now. What should we build with it?"

I Would Love to Hear From You

We are all watching the same AI developments, but we do not always see them in the same way.

Maybe you think the current progress is being underestimated. Maybe you think some of the excitement or fear is going too far. Or maybe you are already seeing changes in your own development work that I have not noticed.

I would love to hear your perspective.

What do you think?

If you have a different way of looking at AI benchmarks, model evaluations, or where software development is heading, share it in the comments. We all come from different experiences, and I think that is where these conversations become much more interesting.

References

These are the main references behind the benchmark, evaluation, and capability points discussed in the article.

🤝 Let's Stay Connected

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

Dev Opportunity Radar #16: $15K AI Agent Hackathon, AI Education Fellowship, and AWS Student Rewards

Hemapriya Kanagala — Fri, 11 Sep 2026 13:59:00 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features the AI for Education Fellowship, AWS Student Rewards, and the Multi-App AI Agent Hackathon, along with the Tech Interview Handbook as a resource worth checking out.

If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

If you've discovered something through the radar, I'd love to hear about it. Whether you applied to an opportunity, joined a community, completed a program, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission).

And if you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature one of your Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan
🔄 Still Open From Previous Editions
📍 This Week's Opportunities
- 📌 AI for Education Fellowship
- 📌 AWS Student Rewards
- 📌 Multi-App AI Agent Hackathon
📚 Resources Worth Checking Out
- Tech Interview Handbook
🌟 Community Finds
💙 Reader Updates
👋 Until Next Friday
🌐 Dev Opportunity Radar Website

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Location / Format	Deadline
AI for Education Fellowship	Worldwide Studios	Fellowship	Virtual (Global)	Applications reviewed on a rolling basis
AWS Student Rewards	AWS Builder Center	Student Rewards Program	Online (Global)	Open
Multi-App AI Agent Hackathon	Lemma × Comma Capital	AI Hackathon	Virtual (Global)	September 13

Resource Highlight

Resource	Why Check It Out
Tech Interview Handbook	A free collection of software engineering interview preparation material covering resumes, coding and algorithms, system design, behavioral interviews, interview best practices, and offer negotiation.

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please take a few minutes to visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from the two most recent editions that are still accepting applications.

Opportunity	Organization	Type	Format	Deadline	Featured In
Agents for Humans Hackathon	AWS	Hackathon	Online (Mostly Global*)	September 15	Edition #14
MLH Global Hack Week: Data	Major League Hacking (MLH)	Hackathon	Online (Global)	September 17	Edition #14
HackerRank Orchestrate	HackerRank	AI Hackathon	Online (Global)	September 12	Edition #15
Claude Campus Ambassador Program	Anthropic	Campus Ambassador Program	Campus-based (Global)	September 12	Edition #15
Bharat Builds Tour	WeMakeDevs × AWS Builder Center	Student Hackathon Series	Online (India) / In Person	September 17–20	Edition #15

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 AI for Education Fellowship

Who it's for: Builders, engineers, educators, researchers, and anyone interested in building something at the intersection of AI and education. No coding experience or other prerequisites are required.

What stands out: The AI for Education Fellowship from Worldwide Studios is a 100-day virtual fellowship where you pick projects to work on, build and test them, and share what you're working on through demos every two weeks.

I wanted to include this because I like that it is focused on actually building something, rather than just learning about AI or education. You can explore an idea, build a first version, test it, and keep improving it throughout the fellowship.

The fellowship is fully virtual and you can join from anywhere in the world. Fellows can also work in teams if they want, and the community includes people from different backgrounds, including engineers, researchers, educators, and school owners.

Another thing worth knowing is the time commitment. The fellowship expects around 8–10 hours a week, with weekly squad syncs and bi-weekly demos. So this is something to think about if you're considering applying alongside work or school.

There are also examples of past fellows building and testing real projects during the fellowship, including AI tutoring and education-focused products.

Format: Virtual | Duration: 100 days

Dates: September 15 – December 15, 2026

Time Commitment: 8–10 hours per week

Cost: Free for accepted fellows

Eligibility: Anyone interested in building solutions in AI and education | No prerequisites

Application: Applications are reviewed as they come in

🔗 Learn More & Apply

📌 AWS Student Rewards

Who it's for: University students who want to learn cloud and AI, build projects, and earn AWS learning and certification benefits along the way.

What stands out: AWS Student Rewards on AWS Builder Center gives verified higher education students 12 months of AWS Skill Builder Premium, along with opportunities to earn AWS Credits and an AWS Foundational Certification exam voucher.

I wanted to include this because 12 months of premium learning access is a pretty significant amount of time. The Skill Builder access includes 900+ courses, hands-on labs, certification preparation, and other learning resources, so students can actually use it throughout the year rather than having access for only a short period.

There is also a reward system built around participating in the AWS Builder Center community. After verifying your student status and completing your profile, you get the Skill Builder reward. You can then earn badges through things like publishing articles, commenting, and maintaining engagement.

At 7 badges, you unlock $10 in AWS Credits, at 14 badges you get another $20, and at 21 badges you can unlock an AWS Foundational Certification exam voucher worth $100.

Another thing I liked is that AWS also has Student Builder Groups at universities in 60+ countries, so there is a community side to this as well if there is a group at your university.

One thing to check before signing up is the eligibility. You need to be 18 or older and enrolled at an accredited higher education institution, and your student status needs to be verified.

Benefits: 12 months of Skill Builder Premium + up to $30 in AWS Credits + AWS Foundational Certification exam voucher

Eligibility: Students 18+ enrolled at accredited higher education institutions worldwide

Cost: Free

🔗 Learn More & Get Student Rewards

📌 Multi-App AI Agent Hackathon

Who it's for: Developers, AI builders, and anyone who wants to build an AI agent that can actually take actions across different applications. You can participate solo or in a team of up to four.

What it's about: The Multi-App AI Agent Hackathon, hosted by Lemma and Comma Capital, is a one-day virtual hackathon where you build a multi-step AI agent connected to at least three external apps.

I wanted to include this one because the challenge is pretty clear: you're not just building a chatbot or showing what an AI agent could do. The idea is to build something that can actually take actions across multiple apps, and then show that it works.

The hackathon takes place on September 13, 2026, from 9 AM to 5 PM Pacific Time. You'll have most of the day to build, with judging and awards happening toward the end.

For the submission, you'll need a working project or repository, a two-minute demo, and a short system and reliability brief. The project is judged on technical execution, reliability and evaluation, usefulness, originality, and how clearly you can explain what you built.

There is also $15,000 in cash prizes, with $10,000 for first place, $4,000 for second, and $1,000 for third.

And probably the part many developers will care about: all three winning teams get a guaranteed interview with either Arga Labs or Lemma AI. Of course, that is an interview opportunity and not a job offer, but I think it makes the hackathon a little more interesting if you're also looking for opportunities to get your work in front of companies.

One thing to keep in mind is that this is a single-day hackathon, so you'll need to be comfortable building and making decisions fairly quickly. The challenge also has a specific requirement of connecting your agent to at least three external apps, so it's worth thinking about what you could build before the event starts.

Prize Pool: $15,000

Format: Virtual | Duration: 1 day

Date: September 13, 2026 | Time: 9:00 AM – 5:00 PM Pacific Time

Team Size: Solo or 2–4 people

What you need to build: A useful, multi-step AI agent connected to at least 3 external apps

Submission: Working project/repository + 2-minute demo + system and reliability brief

Judging: Technical execution, reliability & evaluation, usefulness, originality, and demo clarity

Hiring: Top 3 teams receive guaranteed interviews with Arga Labs or Lemma AI

🔗 Learn More & Register

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

Tech Interview Handbook

If you're preparing for a software engineering interview and not sure what you should actually focus on, the Tech Interview Handbook is a free resource that puts a lot of the preparation material in one place.

It covers the whole interview process, starting from resume preparation and applying for jobs, then moving into coding and algorithms, system design, behavioral interviews, and finally offer negotiation.

I think the useful part here is that you don't have to use it only for coding practice. There are sections on things like how to prepare for coding interviews, common algorithm patterns, system design, behavioral questions, interview best practices, and questions you can ask the interviewer.

It also includes curated coding questions through the Blind 75 and Grind 75, along with explanations and tips for different algorithm topics. So if you don't want to randomly pick hundreds of problems to practice, you can use those lists as a starting point.

There are also sections on company interview formats, engineering levels, compensation, and choosing between offers, which can be useful once you get further into the process.

I wouldn't say you need to go through every section. Depending on where you are in your interview preparation, you can just pick the parts that are relevant to you. For example, if your coding preparation is already good, you could spend more time on system design or behavioral interviews.

So if you're preparing for interviews and looking for one place to get an idea of what to prepare and in what order, this is a resource I think is worth going through.

Format: Free online resource

Covers: Resume preparation, coding & algorithms, system design, behavioral interviews, interview best practices, offer negotiation, and more.

Also includes: Blind 75, Grind 75, curated practice questions, interview cheatsheets, and company interview information.

🔗 Explore the Tech Interview Handbook

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

This week, we weren't able to include a community find, but that's completely okay. Hopefully we'll have more wonderful finds from the community as we keep going.

If I feature something you shared in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post