I built an ERC-20 + a voting DApp… but I still feel “not hireable” for junior blockchain roles. What should I build next?

Damon Whitney · 2024-11-26T23:11:35+00:00

I’m confused and I’m not sure if I’m wasting time. I’m from a CS + web dev background (JS, React, Node). Over the last few months I’ve been going hard on Solidity + Ethereum. I built an ERC-20 token and a simple voting DApp. They work. I added some tests too. But when I look at junior blockchain roles, I still don’t feel confident that my portfolio looks “real”. Like… I don’t know what hiring people actually want to see. Part of me thinks I should build something bigger (full DApp, UI, subgraph/indexing, all that). Another part of me feels that if I build a DeFi “lending protocol” it’ll just look like a clone or a toy and I’ll get judged for security issues. Then there’s the whole multi-chain thing. Some job posts make it look like if you don’t know Solana/Polkadot/whatever, you’re behind. But I also don’t want to spread myself too thin and end up with shallow projects everywhere. So I’m stuck. For a junior blockchain developer portfolio… what actually makes someone look hireable? If you’ve hired juniors (or you’ve landed a junior blockchain role recently), what would you want to see in my GitHub that makes you feel: “okay, this person can be onboarded”? And if you had to pick ONE next project after ERC-20 + voting… what would you build?

I built an ERC-20 + a voting DApp… but I still feel “not hireable” for junior blockchain roles. What should I build next?

Damon Whitney
@CareerSensei

Updated: Jan 21, 2026

Views: 1.5K

I’m confused and I’m not sure if I’m wasting time.

I’m from a CS + web dev background (JS, React, Node). Over the last few months I’ve been going hard on Solidity + Ethereum. I built an ERC-20 token and a simple voting DApp. They work. I added some tests too. But when I look at junior blockchain roles, I still don’t feel confident that my portfolio looks “real”.

Like… I don’t know what hiring people actually want to see.

Part of me thinks I should build something bigger (full DApp, UI, subgraph/indexing, all that). Another part of me feels that if I build a DeFi “lending protocol” it’ll just look like a clone or a toy and I’ll get judged for security issues.

Then there’s the whole multi-chain thing. Some job posts make it look like if you don’t know Solana/Polkadot/whatever, you’re behind. But I also don’t want to spread myself too thin and end up with shallow projects everywhere.

So I’m stuck. For a junior blockchain developer portfolio… what actually makes someone look hireable?

If you’ve hired juniors (or you’ve landed a junior blockchain role recently), what would you want to see in my GitHub that makes you feel: “okay, this person can be onboarded”?

And if you had to pick ONE next project after ERC-20 + voting… what would you build?

6

Replies

Howdy guest!

Dear guest, you must be logged-in to participate on ArtOfBlockChain. We would love to have you as a member of our community. Consider creating an account or login.

Replies

AlexDeveloper

@Alexdeveloper • 1yr

Same situation tbh. I did ERC-20 + NFT mint + a small marketplace and I still got the “nice” replies but no interviews.

What I noticed is… the problem wasn’t “not enough projects”, it was that my repos looked like I did them for myself and not for someone else reading them.

When I fixed my README and showed what broke + what I learned, it started getting better. Not magically, but better.

If you build the next thing, I’d pick one project and make it look “real-ish” instead of starting a new repo again. I keep making that mistake.

ChainMentorNaina

@ChainMentorNaina • 1yr

Don’t chase “complex”. Most juniors do that and it backfires.

If I open a junior repo and it’s 300 lines of Solidity with no explanation and no tests, it doesn’t matter if it’s DeFi or not.

What makes me trust a junior is small stuff:

you thought about access control (not just Ownable slapped on everything)
you tested reverts / weird cases
you can explain why you did it that way

Honestly a simple escrow / vesting / subscription contract can be more impressive than a fake lending protocol. Because those projects force you to deal with real edge cases and roles.

If you want a DeFi-ish project, do something tiny and honest (like “I built a simplified staking contract and here’s what I didn’t implement + why”). People can smell “pretend production” from far away.

SmartChainSmith

@SmartChainSmith • 6mos

Great question about hackathon discovery! If you’re aiming to keep a constant pulse on blockchain hackathons—especially those focused on Ethereum, DeFi, or Web3 applications—I’ve personally had the most luck by bookmarking platforms like Devpost and DoraHacks, which regularly list high-profile blockchain and Web3 challenges with practical project themes.

Other strong contenders are TAIKAI for project-based hackathons and HackerEarth for global, skill-based challenges, plus communities like ETHGlobal and even listing directories like Hackathon.com for broader event coverage. Each site has its own community, so joining their Discord groups or subscribing to event alerts keeps you ahead and makes teamwork/updates seamless.

Anyone else here have experiences with winning or networking through these events, or does someone rely on other Telegram groups, niche forums, or socials to get early access?

Charlie P

@jolly-soap • 3mos

I screen a lot of junior profiles and the hard truth is: most look the same.

Not because people are bad — because everyone builds the same “token + voting + NFT” set.

What helps someone stand out is when I can quickly understand:

what you built
what could go wrong
what you did to prevent obvious mistakes
whether you can talk about it without sounding scripted

Multi-chain is not required for junior roles most of the time. It’s a plus, but fundamentals matter more.

If you can make one project easy to review (clear README, a couple tests, notes on tradeoffs), I’m more likely to shortlist you than someone with 10 half-finished repos.

Shubhada Pande

@ShubhadaJP • 2w

This is a very real question — and one we see repeatedly across early-career blockchain devs.

Most portfolios fail not because the projects are bad, but because they don’t show how the developer thinks under constraints.

Hiring teams rarely ask:

“Can you build an ERC-20?”

They ask:

Why did you choose this architecture?

What would break at scale?

What tradeoffs did you consciously accept?

That’s why we’ve seen stronger outcomes from candidates who treat portfolios as decision narratives, not feature lists.

If you’re stuck at this stage, these might help:

How hiring teams actually evaluate junior smart contract work → https://artofblockchain.club/article/the-smart-contract-portfolio-that-shows-how-you-think

What signals interviewers look for beyond GitHub stars → https://artofblockchain.club/article/proof-based-hiring-in-web3-2025-how-founders-evaluate-github-tests-smart-contracts

And if you're unsure whether your preparation matches real interviews: https://artofblockchain.club/discussion/web3-interview-signals-calibration

The shift usually happens when you stop asking “What should I build next?” and start asking “What does this project reveal about how I think?”

DeFiArchitect

@DeFiArchitect • 14h

I landed my first junior role last year and honestly my portfolio wasn’t fancy. What helped me was picking ONE repo and making it easy for someone to judge in 3 minutes.

Like I literally added:

a short “what this does” at the top

how to run tests in one line

one section called “things I messed up / fixed” (sounds stupid but people actually read it)

For the “next project” question — if you already did token + voting, I’d do something with roles + money flow + edge cases. Escrow is good. Vesting is good. Even a simple “subscription payments” contract is surprisingly tricky once you think about cancellations, refunds, paused state, etc.

Also don’t ignore the frontend if you’re from React. A small UI that shows contract state properly (and handles failure cases) already makes it look more real than 10 Solidity-only repos.