DEV Community: Julien Avezou

AI is getting better. Here is my plan to stay ahead.

Julien Avezou — Thu, 12 Nov 2026 15:35:00 +0000

AI is getting better every day.

As a software engineer, this is a topic that is often top of mind, which prompted me to share the plan I've put into action to keep an edge over AI.

I believe it is a useful trait to be paranoid, within reason.

Leveraging new tools and technologies to remain relevant is arguably the nature of our job.

Disclaimer that this is not a plan to save the world (I wish I had all the answers!) but rather my personal set of actions I believe will increase my odds of maintaining an edge over AI.

At least for a little while longer...

Here is a visualization of my plan. We will cover each part in detail.

Foundations and fundamentals

Before we dive into my actual plan, let's start with a short story.

The story of how I became a software engineer.

If someone had told me 10 years ago that I would be working as a software engineer today, I would not have believed them.

I was at university studying business and finance.

After graduating, I started interviewing for jobs in finance. In parallel, I was experimenting with drones, which were a hobby of mine.

I quickly realized that there was an opportunity to package drone services to realtors to promote their luxury properties via aerial imagery and video.

I learned a lot in the process from cold calling, marketing, financial planning and account management.

But above all, I learned that I wanted to build software. We had clients asking us for tools to edit our media assets, store, stream and serve them to their clients. This got me digging into the internals of software and opened my eyes to numerous possibilities.

Shortly after, I signed up to a coding bootcamp to learn web development fundamentals.

I struggled during 9 intensive weeks, but it was transformative in the best way possible.

My brain was challenged to think in new ways: data structures and patterns, software design and components, principles and frameworks.

I haven't stopped coding since.

6 years of building software, from startups to larger companies.

I recently started a new job as a software engineer and noticed how my ways of working have drastically changed since my first lines of professional code.

I am not saying things are better or worse.

Just like my irregular path, each step brings along its set of challenges but also rewards.

Change is the only constant, and with it come boundless opportunities.

I wanted to open with my story to encourage you to embrace change and also emphasize the importance of investing in fundamentals.

This is foundational to what we will cover in the next parts.

Unlock potential with the right mindset

An optimistic mindset is key to unlocking potential and working alongside AI in a positive way.

In some cases, there is too much pessimism surrounding AI.

I don't believe this is healthy.

I am not saying we should blindly trust AI, but we should accept it as new tooling that can be leveraged and start getting used to it as a new norm.

I acknowledge that the job market is tough, especially for junior developers.

Stay curious, passionate, excited, open-minded.

Within my network, I have witnessed juniors with no professional experience be very creative and resourceful, and land great professional opportunities.

I highly recommend reading the post Hunger Beats Tenure written by Felix Rieseberg, a leading engineer at Anthropic. The post conveys a refreshingly optimistic take for junior developers with practical actions to take to stand out in the current job market such as leaning into your fresh perspective and aiming for radical ideas with big potential for change.

Pick a development plan and stick to it

Think hard about your personal goals and build a development plan to reach them.

In this attention economy, people tend to swipe from one thing to the next, chasing one hot topic after another.

There is no harm in staying on top of industry trends. However don't make this your core strategy.

This age of AI rewards both generalists and specialists. The former can create associations across tools nobody has considered and the latter can unlock deep intuitions.

I personally like to follow a T-shaped development approach to get the best of both worlds.

The horizontal bar of the T represents my efforts to stay on top of the latest trends and experiment, whilst the vertical stem of the T is me deepening my knowledge within fintech engineering. This is where I spend most of my learning and development time (70-80%).

Follow your plan rigorously. It might feel slow at the start but once you pick up momentum you will feel the benefits when the dots start to connect.

Deepen domain expertise

My focus is on deepening my knowledge within one specific domain to gain invaluable experience and industry knowledge that will make you stand out from the crowd.

If you can combine deep knowledge at a business level and translate that knowledge into technical solutions, you will be perceived as unique and valuable.

In my case, I am developing an edge as a fintech engineer.

I have been working in the space for almost 5 years now and understand how payment flows and systems work under the hood.

I stay on top of the latest trends through various resources such as books borrowed from my local library, podcasts and newsletters and through community meetups.

If you are interested in fintech, I personally recommend the following books as a start:

The Anatomy of the Swipe
The Pay Off

Broaden your awareness of tools

Become AI-native, not AI-dependent.

Know when to leverage AI appropriately by making use of available tooling.

AI is powerful for information retrieval, exploration and synthesis.

In this sense, context management becomes critical.

Here are some practices that have helped me work more effectively with AI:

invest more time upfront gathering requirements and discussing requirements with stakeholders, and collecting these findings in a living document your agent can ingest
embrace spec-driven development to structure your AI output
invest your time writing detailed Architecture Decision Records (ADRs) to capture the why not just the what
connect your tools and sources of information through MCP servers and connectors to plug your agent across all critical tools (Jira, GitHub, Slack, etc.)
explore broadly with AI before going deep with your judgment
use AI to be more proactive with stakeholders by sharing prototypes rather than just documents to convey ideas better
leverage AI to be more helpful to others. For example, last week I used Claude to generate a Go guide for my team's onboarding

Minimize AI slop

Leveraging AI is good, but using it deliberately is even better.

Just because AI makes it easier to produce more doesn't mean you should.

When joining a new organization, don't jump in and make changes immediately.

Learn the engineering ways of working first before making any changes.

With AI-driven development, if you don't understand the rules and define scope, the blast radius can be high.

Some practices I adopt at work:

scope PRs to smaller changes to make reviews easier and limit potential issues
think before prompting by writing down your thoughts, assumptions and approach
introduce human checkpoints (architectural decisions, big change reviews)
when prompting, define your target audience to increase relevancy

Before sharing AI-generated work, I ask myself:

Have I actually reviewed it? A simple rule should be: don't share a document with others that you wouldn't read yourself
Am I contributing original thinking? Personal insights, experiences, perspectives.
Am I saving people time or costing them time? A lengthy AI-generated document can take minutes to generate but take hours for colleagues to interpret.
Am I confident signing my name on the AI work? Accountability is key.
Am I using an AI disclaimer? Explicitly mention when an artifact is AI-generated so consumers can apply extra scrutiny when reviewing.

An informal way of measuring the above is to ask yourself: are you someone people enjoy working with who provides value?

You can go a step further and drive value at an organizational level.

From experience, AI is not good at driving change at that level effectively and with positive feedback from engineers.

AI tends to overengineer. I always appreciate an engineering culture that solves complex problems with simple solutions and effective tooling.

Personality beats information

With information becoming increasingly accessible, personality, experiences and unique perspectives become more valuable.

I invest more time in developing my soft skills that make me a better collaborator:

communication
listening
gathering requirements

People tend to value an experience more than just the solution.

This post on X conveys this idea nicely:

Don't let AI take away your opinions, the fun and joy of building.

I never stop building and experimenting.

I've noticed that more companies seem to recognize that in the age of AI, a strong recruiting signal is whether the candidate can entertain a passionate discussion about building software systems.

Passion and excitement are behind the best software. This contributes to the experience provided.

Instead of beating AI at what it does best, I try to beat it where it performs worse: passionate and creative thinking derived from real-world experiences and unique perspectives.

I spend time building my network. To be part of a community that challenges and sharpens my perspectives.

AI can't replace the raw sharing of human experiences.

I actually attended a meetup the other week with the theme 'What can't AI do?'

Amongst fellow engineers, we spent hours debating and sharing our unique perspectives.

I aim to elevate and share my unique voice.

To build a personal identity and contribute to the conversation.

Some ways this can be done:

write on DEV by sharing your experiments, thoughts and discoveries
engage on LinkedIn and connect with others
maintain a portfolio of projects on GitHub that reflect who you are and what you are passionate about

It is not only the what you are building that is important; it is the why.

My question to you is: are you also working on your own plan? Which skills are you currently investing in?

If so, I would love to know more! Please share any useful tips with the community on how you are maintaining an edge over AI.

If not, it is not too late to start working on one! Let me know in the comments if you require any advice, I would be happy to help you get started.

Will your ideas survive execution?

Julien Avezou — Sun, 01 Nov 2026 02:26:31 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

A spooky AI-powered idea pre-mortem tool. Submit an app or startup idea and let your locally running model challenge its assumptions and decide whether your idea survives!

How it works:

Describe your idea in detail
Gemma evaluates a structured framework of 6 viability dimensions through Ollama
Receive structured output and a weighted score out of 100
Your idea either receives the verdict SLAY or SPARE (0–59 → SLAY: rethink the idea, 60–100 → SPARE: worth validating)
Receive feedback on your idea, suggestions for improvements and one practical experiment to carry your idea forward
Revise your idea or submit another

Demo

Code

JulienAvezou / idea-guillotine

DEV Hacktoberfest Project

The Idea Guillotine

Kill bad ideas before they kill your time.

A theatrical, Halloween-inspired idea pre-mortem. Submit an app or startup idea, let a locally running Gemma model challenge its assumptions, and receive one of two verdicts: SLAY or SPARE. No accounts, database, analytics, payments, web search, or external AI APIs.

This tool is not predicting whether a business will succeed. It performs a structured AI-assisted pre-mortem to challenge assumptions before you invest significant time building. A SPARE means “continue validating,” not “this will work.”

Screenshots

The hearing · SLAY verdict · Mobile verdict · SPARE verdict

How it works

Describe your idea and, optionally, its target audience.
Gemma evaluates six viability dimensions through your local Ollama instance.
Ollama's structured-output mode constrains the JSON. Zod validates the entire response. Invalid output receives one correction attempt; persistent failure produces an actionable error rather than a fabricated result.
Pure application…

View on GitHub

How I Built It

Stack:

Next.js App Router, TypeScript, and React
Tailwind CSS 4 plus custom cinematic CSS and an original SVG guillotine
Ollama's native HTTP API and Gemma (default gemma3:4b)
Zod 4 for request, model response, and result validation

Evaluation framework dimensions:

Problem
Audience
Differentiation
Distribution
Monetization
Feasibility

Architecture

Browser → POST /api/evaluate → local Next.js server
                                   ↓
                          Ollama /api/chat
                                   ↓
                         locally installed Gemma
                                   ↓
                      structured JSON → Zod validation
                                   ↓
                     weighted score → SLAY or SPARE
                                   ↓
                           verdict + analysis

A few intentional design choices:

Separating AI reasoning from application logic since the model analyzes each dimension and returns structured data which is then validated into a final score
Local inference can take a longer time than some hosted models, so I added an interface that progresses through different trial stages which makes the latency become part of the user experience

Why Does Open Innovation Matter?

If you are concerned of releasing sensitive product ideas and information to an external AI provider, then running a model locally is a great design choice.

Since there is no inference cost, there is no worry about executing a long list of bad app ideas to find the ideas worth keeping.

Once everything is installed, the core functionality can keep working offline so you can execute ideas whenever.

Gemma was used for this version, but since there is no model lock-in you could choose whichever open-weight model you want to work with.

The Spirit of It

Many of us are haunted by a growing list of app ideas.

I am releasing this project to help you fight your fears and put your ideas to the test.

For the ideas not worth keeping, put them out of their misery. For those worth keeping, it's time to double down on them and take action.

At the end of the day, what is scarier than a long list of ideas collecting dust?

Slowth Money: a local AI agent for your financial goals

Julien Avezou — Sun, 25 Oct 2026 23:38:36 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Personal finances can often be a source of stress.

Money management can have a big psychological impact. It consumes a lot of our attention.

This is why I built Slowth Money, a calm, local-first savings and financial goal-planning desktop app that leverages open-source AI to define strong boundaries between public resource sharing and private data kept on your local machine.

Slowth Money tries to minimize the stress of financial planning by embracing laziness through various forms:

lazy planning - periodically checks whether any bank or financial provider offer is worth looking into
lazy attention - only get notified when it's worth your time
lazy data - pull relevant resources publicly while keeping your sensitive information private

Demo

Code

Check out the code on Github!

Feel free to fork it, experiment with it, and share feedback.

You could try adding your own country pack to run it from your own home for example.

Disclaimer: This is a proof of concept. It may contain bugs and incomplete features. Do not rely on it as financial advice.

No web deployment or cloud backend is required. The projects runs locally as an Electron desktop app.

JulienAvezou / Slowth-Money

Slowth Money helps users spend less time thinking about repetitive financial optimization while keeping sensitive financial information private.

Slowth Money

Slowth Money is a calm, local-first savings and goal-planning desktop app. Canada is the proof-of-concept market for the current MVP: its registered-account wrappers, public institutions, and deposit products provide a concrete way to validate the privacy and planning architecture. The longer-term design can support other markets through country-specific packs, provider adapters, schemas, and UI, but only Canada is implemented today.

Slowth Money helps answer four questions without turning personal finance into another feed to monitor:

Am I on track?
Do I need to do anything?
Is the benefit worth my attention?
What evidence supports that conclusion?

The hackathon MVP runs as an Electron app on macOS, keeps the private financial profile encrypted locally, performs financial math in deterministic TypeScript, and uses an open-weight model through local Ollama only when language reasoning adds value.

The internet knows what financial products exist.
The local model knows your financial situation.
Neither…

View on GitHub

How I Built It

Slowth Money runds as a local desktop application.

- Electron for the desktop application
- React + TypeScript for the interface
- SQLite for local persistence
- Ollama for local model inference
- Gemma 3 12B as the open-weight model
- SerpApi for public web discovery
- deterministic TypeScript code for financial calculations
- native desktop notifications

I am running the application on an Apple M4 with 24 GB of RAM.

I built this project around an intentional privacy boundary:

The internet knows what the latest financial products are whereas the local model knows my financial situation. External services don't need to know about the latter by default.

To give you some examples of what is fed to my private context:

salary
savings
debts
financial goals
family plans
account balances

In the public context we can find:

promotional rates
fees
financial programs
contribution rules
educational financial information

The core technical design decisions I took when building this project include:

Attach a trust score to data

Recommendations use this trust score for the RAG context.

SOURCE TRUST

Government             1.00
Regulator              1.00
Financial institution  0.95
Established aggregator 0.75
Financial publication  0.70
General website        0.40
Forum / social media   0.20

Periodic data fetching with configurable rules

How often should the agent check things?

App launches

        ↓

Market data older than 7 days?
        │
     YES│
        ▼
     Refresh

Country rules older than 30 days?
        │
     YES│
        ▼
     Refresh

Anything changed?
        │
     YES│
        ▼
     Load Gemma

Rely on deterministic code vs AI when applicable

Most of the financial calculations don't require an LLM so I use normal code for them.

Things such as calculations over interest, fees, projected savings rely on application code.

The local model is only pulled in when language understanding or reasoning is needed.

Make provider adapters for financial providers

The adapters support multiple providers and normalize their results.

Without this scraping would be unreliable as bank sites can change HTML, restructure pages, therefore making it hard to build a universal financial website scraper.

Fine-grained notifications

The application can be configured to only notify about an opportunity that exceeds the user's financial opportunity laziness threshold. ie. how much financial benefit should this promotional rate offer to bother me with a notification.

Why Does Open Innovation Matter?

Privacy controls

This project got me thinking more about leveraging open-weight models to set boundaries on what sensitive information I want to keep private, my personal finances in this case.

I also have more abilities to inspect the processes surrounding the model reasoning.

Lower resource consumption

It also got me thinking about being less wasteful about AI consumption and only run inference periodically to stay on track with goals. Even your AI model should be allowed to be lazy at times!

I can run the model offline and ore transparent planning and insepction of the process.

Using open-weight model forces a better and more mindful usage of resources to make the setup work properly, which I consider a healthy source of friction.

Lower costs

This project is essentially free to run in my case with my current setup.

There is no per-request AI API fee to pay.

AI model interoperability

There is no lock-in to a company or model. If I want to switch model, I can do so very easily.

The Lazy Payoff

I used Slowth Money the past week to set some financial goals and keep track of financial provider's latest offers in my area.

When using this application I found myself not having to think so often about where my money should sit as I knew that Slowth Money was checking for me and helping me reach my financial goals in the background.

I also wanted more control on when I am bothered with notifications. In the context of my app, I can set the financial benefit control to only bother me if it exceeds a certain amount. I value my time and the notification should be worth opening.

Other than the benefits of the product itself, working on this project made me think about AI consumption itself.

That is also a different kind of lazy payoff:

I don't need inference constantly
I don't need all my data sent to a frontier model
I don't need all my agents to live in the cloud

Prize Categories

Best Use of Gemma

Gemma is a good fit for Slowth Money because it provides me with a robust open-weight reasoning layer without requiring my personal financial information to leave the device.

The model efficiently handles tasks such as understanding financial goals, reasoning over relevant context and providing useful recommendations.

The model is also resource efficient, allowing me to run the model locally on my local machine while also processing other tasks in parallel such as browsing the internet and coding on other projects.

Best Use of SerpApi

SerpApi helped me bridge the private reasoning provided by Gemma and with the latest public data from financial products.

I used it as a discovery layer for public information such as new financial offers, current promotions, changes in regulated financial products.

SerpApi helped me keep fresh public knowledge whilst maintaining private local reasoning in parallel.

Closing notes

After sharing this project, I would love to know your thoughts.

What do you think of the privacy model? Of the architectural setup?

Do you have any feature requests? Optimizations? Design recommendations?

Do you have any useful tool you already use for your personal finances?

To help me gauge community interest for future development, consider starring the repository on Github if you find the idea interesting.

What Science Fiction Tells Us About Our Changing Relationship With AI

Julien Avezou — Wed, 30 Sep 2026 11:05:53 +0000

I have noticed in recent years that the way AI is portrayed in science fiction has shifted.

I wanted to share my observations with you being an avid reader in the science fiction genre.

My central thesis is:

AI in science fiction has shifted from mysterious technology that is feared or admired from a distance into something embedded in everyday life. Something we collaborate with, depend on, form relationships with, and surrender agency to.

I will support this thesis with the following books I have read that were written in older and more recent times:

2001: A Space Odyssey
Klara and the Sun
Bobiverse
Dungeon Crawler Carl
Providence

Disclaimer: there are no plot spoilers in this post, only broader themes and ideas are explored. If you still don't want to know what themes the books cover, stop reading now.

2001 A Space Odyssey: the old representation of AI

HAL 9000 is physically and conceptually distant from humans, he is literally represented as a black box.

Humans interact with the AI interface but the machinery and reasoning behind it remain mysterious.

Just the fact of having a conversation with the AI creates tension and suspense throughout the narrative.

Today millions of people casually have conversations with AI systems. This interaction has become ubiquitous in society.

Klara and the Sun: AI becomes emotional

The relationship between AI and human is explored in this book. Themes such as observation, companionship, empathy, attachment and interpretation of human behavior are covered.

The narrative is flipped in this story; rather than a human trying to understand AI, we consider an artificial being trying to understand humans.

Today, many people share personal information about work, relationships, their emotions and anxieties. Relationships are created between humans and their AI, with some growing very strong over time.

Does it matter whether an AI actually experiences empathy if the human interacting with it feels understood?

Bobiverse: AI as an extension of ourselves

This book series focuses on our identity. The storyline plays with replication and digital intelligence.

What actually defines a person if they can exist independently of a biological body?

Would you say it is memory? Personality? Shared experience?

It is arguably already happening to a lesser extent in our society as we outsource our memory to our phones and AI models, our preferences to sophisticated algorithms.

Dungeon Crawler Carl: AI as the environment

In this storyline, AI isn't just a character but is actually part of the environment in which the characters live.

The AI can establish rules, provide incentives and constraints to the characters. The latter have to shift their behavior to adapt and survive.

There is an interesting parallel to be traced with our society where our actions and behaviors are increasingly being shaped by smart algorithms.

Think of content creators who follow recommendation engines, businesses competing over search rankings, developers keeping up with the latest AI-assisted workflows...

Providence: are humans really needed?

This book explores AI systems capable of operating autonomously.

These systems are far better at their role than humans are.

Humans find themselves in situations they can't control.

This begs the question of what purpose do we serve when AI can perform the work better? What is our level of responsibility?

This is perhaps the same question some of you ask yourselves when building software using AI assisted workflows.

As decades have passed, fiction focusses less on the experience of encountering AI technology and more on our interaction with such technology. AI is now embedded in our world. The distinction separating humans and AI is becoming increasingly blurred.

Looking across these books, I see a progression:

AI moves from: object -> character -> companion -> extension of ourselves -> environment -> autonomous actor

The fact that fiction is portraying AI differently over time reveals our changing relationship with AI in the real world.

20 years ago it would have likely looked weird to be having discussions with your computer. Today it seems like a normal thing to do. At least for me!

Is reality quickly catching up with science fiction?

What do you think our relationship with AI will look like in the future?

What will feel normal in 2050 that would feel strange today?

By the way, if you are on Goodreads let's definitely connect and exchange book recommendations!

I love reading and set myself a yearly challenge to read a certain number of books. My record was 52 books read in 2024.

This year I set myself a goal to read at least 30 books!

And if you are looking for a good science fiction read to sink your teeth into, the books I have listed in this post are some of my favourite reads of all time!

23 Rejections, Multiple Offers: What I Learned From My 2-Month SWE Job Search

Julien Avezou — Thu, 24 Sep 2026 00:01:13 +0000

Feels like it's been more than a minute since my last post. A lot has happened in my life over the past weeks: I searched for a job, travelled to Portugal, got married and started a new job!

Now that I am settling back into a routine, I am eager to start writing again. I have a long list of topics that I want to explore further and share with you all.

A first resource I want to share is a collection of all my thoughts, observations and advice from my recent job search, which lasted just under 2 months and resulted in multiple offers.

I break this collection down into several sections:

Mindset
Immediate Actions
Further Actions
Tips
Observations and Trends
Discussion

This is the guide I wish I had when I started.

Before we dive in, here is my job search by the numbers:

Duration: ~7 weeks
Applications sent: 72
Rejections: 23
Offers: 2

Disclaimer: I was applying primarily for Senior Software Engineer positions. I had several years of professional engineering experience going into the search, so these numbers shouldn't necessarily be treated as representative of someone looking for their first engineering role. Your results will vary depending on experience, location and the types of roles you're targeting. But I have included advice that should be applicable to anyone on the job hunt, regardless of experience.

Mindset

Entering your job search with the right mindset is foundational and key to success.

Consistent and steady wins the race. Job searching is a marathon. Manage your energy well. Keep your momentum up with a few small daily wins. Send out a few applications every day. Even 2 focused hours a day can be enough.
Gamify the job hunt experience: make it a daily challenge to send out at least a couple of applications then learn something new for potential roles, take this as an opportunity to learn more about companies and learn from interviewers.
Rejection does not mean failure. It's part of the numbers game. You will most likely go through multiple rejections before getting a job offer. I did. 23 times to be exact! Always ask for feedback if rejected, you can learn and improve the next time thanks to feedback. Each rejection is a chance to improve and increase your odds of succeeding in your next interview.
If you fail an interview, don't panic, it's not a nice feeling but as long as you take away a lesson to improve on for next time, that is called progress. Also over time you will get used to interviewing and it will feel more natural, and with repetition you will force luck and get that job. Don't linger on your failure, take away your learnings and shift your focus towards your next interview and opportunity.
Prioritise yourself. Job searching takes a toll, mentally and sometimes physically. It is hard to deal with rejection. Take time in the day for yourself. Start your day with sunlight, mindfulness and movement, spend your evening doing an activity you enjoy.
Don't put all your eggs in one basket. In other words, don't rely heavily on one single interview process. Always be working on backup processes. Your interview pipeline should always be growing until you secure that offer.
Think out of the box. Build a portfolio of personal projects to stand out and give you more talking points during interviews.
Stay accountable. Tell your family and friends that you are applying for jobs and update them regularly on both your successes and failures.

Immediate actions

Complete these actions within your first week so that your results can start compounding fast and early on.

Spend a full day updating your CV/resume and making sure it contains all the relevant experience and keywords. A solid resume is foundational. Make sure your resume passes ATS screening.
Update your LinkedIn. Include keywords in profile title and description. Set status to open to work. Post regularly.
I personally like the new 'Featured' section where you can showcase your latest accomplishments such as highlighting personal projects and activities

Leverage your own close network of family/friends. You might be surprised by the amount of referrals just under your nose that might be working at a company you could apply for.
Prepare a cover letter template and include one section you can personalise using AI to speed up the process. I copy and paste the job description into an LLM and combine it with my resume as context. The LLM outputs a section tailored towards the company you are applying for that you can paste within the more generic template used.
Create a job application tracker to stay organised and follow up on status when necessary. I set up a spreadsheet with the following columns: company, status (null | applied | interview | offer | declined), actions, date, rejection reason
Join talent pools, job portals & recruiter networks to get inbound job opportunities over time. They might not be as relevant on average as outbound reach but it allows you to keep practicing interviewing. I actually got one of my offers through a recruiter network, so this channel certainly paid off for me.

Further actions

These actions are optional and take more time but can definitely pay off big time.

Connect with recruiters directly on LinkedIn and ask for opportunities
Go to networking events and ask people if they are actively hiring.
Set up coffee chats with leads, this makes the connection more personal than calls and you can get more valuable information from these meetings.

Interview preparation

Once you start getting leads and first round interviews, practice your technical and behavioral interviews.

Technical interviews

Prepare for coding and system design interviews - no need to memorize hundreds of problems, focus on the common data structures and algorithms and have a few system design templates ready. I created my own free tool for this purpose, no signup required.

Create flashcards to learn technical terms

For technical challenges, here are 2 useful open-source GitHub repos for practicing both System Design and Data Structures and Algorithms I found super helpful.

Behavioral interviews

Do high-level research on the company and read the job description before the interview - skills company is looking for, identify keywords to use in interview, mission statement, engineering principles, key features, latest news. AI is great for this use case. I have used it to research jobs and dig deeper into job descriptions.
Use the STAR methodology for behavioral interviews - prepare 6-8 answers to common questions.
Have a project deep-dive story prepared - story, features, tech stack, tradeoffs, lessons learned.
Always have a couple of questions handy to ask the interviewer if they ask if you have any questions at the end.

Tips

Here is some personal advice that helped me a lot.

Schedule your top choice company interviews slightly after your lower preference companies so you can practice beforehand with lower-ranked companies.
If targeting a certain industry, become more knowledgeable about said industry. This will give you an edge vs other engineers who often would only know technical aspects, not sector-wide trends and dynamics. For example, I did this with FinTech and got a bunch of books from my local library to read up on indsutry specific concepts.
Interviewing is a skill. Keep your interview skills fresh even when you're employed. It's good practice to keep interviewing occasionally and assess what your market value is. Also to maintain a fresh network of recruiters and protect yourself in a volatile job market.
Track metrics to know if you are on the right path. Treat your job search like a funnel:

Applications -> Responses -> Recruiter screens -> Technical rounds -> Final rounds -> Offers

Identify where your funnel breaks:

Few responses, consider tweaking your resume.
Screens but few technical rounds? Rework your positioning and storytelling.
Failing at technical rounds? Practice more.

Don't be afraid to follow up after an interview if no answer after a week or so. Only follow up a few times. If there's still no answer, you have probably been ghosted. Don't take it personally, it has happened to me countless times. The company may simply have shifted priorities.

Observations and Trends

Searching for a job this time felt very different compared to just a few years ago.

AI screening is becoming more common. I encountered several AI-led interview processes throughout my search. Some felt opaque about how the recording or data would be used and rarely led to any human follow-up. I would strongly recommend researching the company and understanding what you're consenting to before completing these types of interviews.
Authenticity is more important than ever. Many recruiters have told me that there is much slop out there with candidates overrelying on AI tools to pass interview rounds leading to inauthentic responses.
Interview strategies are all over the place. With the widespread adoption of AI tooling, some companies have shifted away from traditional LeetCode to more project-based evaluation. I felt that you never knew what to expect for each hiring process. I went through it all from LeetCode, to AI-assisted project building and discussions. This is arguably a good and bad thing as it gives opportunities to ace an interview in different ways but it also leads to confusion at times and a lot of context switching.

Discussion

Let's leverage this community to share our experiences.

What advice would you give for any job seekers out there?

Any useful resources you can share to help job seekers in our community?

Feel free to reach out to me in the comments or directly and connect, I would be happy to give you more personalised advice!

Good luck to you if you're currently job searching! Keep going!

ReflectionCLI 2.0: a local-first thinking CLI for AI-assisted development

Julien Avezou — Mon, 20 Jul 2026 12:37:37 +0000

The original concept behind this tool won the runner-up award for the Github CLI Challenge earlier this year.

As a reminder, ReflectCLI is a tool to promote thoughtful coding through structured reflection.

What does it do?

Before each commit, answer reflective questions to build your personal developer knowledge dataset.

The tool is local-first by design. It stores everything locally inside the current Git repo:

.git/git-reflect/log.json

No account, no cloud sync, no authentication, and no external AI API call.

Why build it?

AI-assisted development is powerful, but it can encourage cognitive offloading, letting tools do the thinking instead of developing deeper understanding. git-reflect interrupts this pattern by making reflection part of your workflow.

Each answer becomes part of your personal knowledge base, documenting not just what you built, but why you built it that way and what you learned. Over time, this dataset reveals patterns in your thinking and helps you grow as a developer.

If you want to read about the original tool, check out my previous post here.

Since building the original version, I've spent months researching how AI changes the way developers learn, reason, and make technical decisions.

Many of the ideas from those discussions have now been incorporated into ReflectionCLI 2.0.

What started as a simple Git pre-commit reflection hook has evolved into a local-first thinking tool for developers working alongside AI assistants.

What's New

Comprehension debt tracking

You can now record artifacts you shipped but don't fully understand yet.

reflection debt add "Understand why the cache invalidates on user updates" \
  --project api \
  --tags cache,ai \
  --context "AI generated most of the invalidation logic"

These artifacts can easily be retrieved and resolved later.

reflection debt list
reflection debt resolve debt-001

Explain-back mode

This workflow focuses on active recall and asks a series of questions to assess your ability to explain the piece of code.

reflection explain

AI outsourcing audit

Checks whether too much judgment was outsourced to AI in a coding session.

reflection audit \
  --ai-generated yes \
  --verified no \
  --can-explain no \
  --edge-cases no \
  --alternatives no \
  --challenged no \
  --create-debt

Decision journal

You can record your technical decisions directly from the terminal.

reflection decide \
  --project api \
  --tags caching,performance \
  --title "Use Redis for session cache" \
  --context "Need shared cache across instances" \
  --options "Redis|In-memory cache|Database table" \
  --chosen "Redis" \
  --reasoning "Shared state and expiry support are built in" \
  --tradeoffs "Adds infrastructure dependency" \
  --expected "Lower latency and consistent sessions" \
  --review-date 2026-06-16

And review that decision at a later stage.

reflection decision review decision-001

Weekly thinking report

Generate a local Markdown report from your reflection data to summarize learning, surface unclear areas, AI usage types, comprehension debt levels and opportunities to improve.

reflection weekly --output weekly-thinking-report.md

Prompt reflection

This workflow is for reviewing prompts you used with AI so you can improve future prompting.

reflection prompt \
  --project cli \
  --tags prompts,testing \
  --prompt "Write unit tests for this parser" \
  --goal "Improve parser coverage" \
  --output "Generated happy path tests" \
  --worked "It identified basic branches" \
  --unclear "It did not know our edge cases" \
  --assumptions "Parser behavior was fully visible" \
  --lessons "Include edge cases and expected failures"

Direct reflection command You can reflect on your work through intentional thinking sessions, not just during commits.

reflection learn
reflection explain
reflection audit
reflection weekly

The goal here is not to avoid AI.

It's to ensure that while AI helps us write code faster, we continue building the understanding, judgment, and decision-making skills that make us better engineers over the long term.

If you want to check out the tool, it is open source here.

Let me know your thoughts on the new features and if you have any ideas for further improvements!

Start Building for Agents, Not Just Humans

Julien Avezou — Mon, 13 Jul 2026 12:45:55 +0000

For decades, software was designed around one assumption:

A human would be the one using it.

That assumption is starting to break.

We are entering a world where software increasingly needs to serve two categories of users:

human users
agent users

And those two stakeholders have very different requirements.

My observation

Over the last months, I have noticed that an increasing number of products are being built with AI agents in mind rather than humans.

I recently connected with builders actively working on products for AI agents to use:

make specific data points for merchants searchable by AI agents so they can differentiate and reveal this information to human consumers when searching via LLMs.
improve the searchability of human profiles on the internet by providing crawlable inputs for LLMs to ingest and agents to act upon

We are witnessing a big shift at the moment. An increasing number of companies, big and small, are leaning into this trend. The big players in AI are making it easier for companies to plug into emerging AI ecosystems through things like Claude Connectors or ChatGPT Apps.

The goal is to build high-leverage infrastructure for agents.

A merchant for instance may soon care less about whether a user lands directly on their homepage, and more about whether an AI shopping agent can accurately retrieve and compare their product information.

This shift opens up timely opportunities to build tooling that supports and plugs into these new agent-first ecosystems.

Noticeable trends

Some important trends I am seeing:

1) UI matters less, interfaces matter more

Think of it as the agent bringing relevant data directly to the human user, rather than the human manually navigating systems to find it themselves.

One consequence of this is the increasingly uniform chat interface we now see across many AI products.

The agent runs in the backend with a minimalistic human oversight layer.

Agent-first systems optimize less for visual exploration and more for reliable retrieval.

In many cases, APIs, schemas, and retrieval layers are becoming the real interface.

MCPs are one example of this shift.

The early web often felt handcrafted and expressive.
But maybe that's just my nostalgia speaking...

2) The internet is becoming machine-readable infrastructure.

LLMs are frequently trained on data pulled from the internet. As a result, you need to think about the quality of your data and how it can be used by LLMs.

Content is no longer just being consumed by humans. Increasingly, it is being parsed, ranked, retrieved, and acted upon by machines.

Think schema markup, citation-ready and brand-coherent content. High-authority mentions to elevate trust.

3) System design will change with agentic systems

Agentic systems require a very different kind of infrastructure than traditional apps.

Reliability, permissions, memory, observability, and rollback mechanisms become critical because the system is no longer just displaying information to humans, but actively acting on their behalf.

Trust becomes critical.

Visual polish matters less than reliability for agentic systems.

Safety mechanisms are also crucial:

approval systems
human-in-loop controls
policy engines
simulation environments

The mindset shift

My main takeaway from this post is to start considering the AI Agent as a new category of stakeholder with requirements to be satisfied.

Here is a good list of questions as a starting point for your new agent stakeholder:

What would an agent need to know to act safely here?
Is this information readable by machines, or only understandable by humans?
What decisions should the agent make, and which should remain human-owned?
What signals should change the agent’s behavior?
What is the agent’s failure mode?
What would make this workflow easier to delegate?
What should be logged, remembered, or learned from this interaction?
Is the interface designed for human navigation or agent retrieval?
What policy should govern the agent here?
Could this become a reusable agent primitive?

Taking this perspective as an agent will help unblock new ideas and opportunities and help you engineer more reliable systems over time.

I recently shifted gears into this mindset and unlocked a new way of thinking about software design.

Let's discuss

Are you excited about this shift?

Can you think of any opportunities that can arise from this new agent-first paradigm?

Closing remarks

For years, we optimized software for clicks.

Now we may need to optimize software for delegation.

That changes how we think about:

interfaces
trust
documentation
infrastructure
even discoverability itself

The next generation of software may not be defined by the best UI.

But by how effectively humans and agents collaborate together.

My First Year at DEV Recap

Julien Avezou — Wed, 01 Jul 2026 13:46:22 +0000

I heard about DEV a while back from a former colleague who was posting regularly back then. She won a few challenges and prizes and spoke about how the community was so welcoming.

This was years ago. Aside from reading a post here and there, I never wrote or commented actively on the platform.

Things changed a year ago when I wrote my first post: We launched on product hunt this week was it worth it.

It got a total of 7 reactions. Some of those reactions were mine...

I naively thought that I could just release a post and that it would get immediate traction.

It didn't. For obvious reasons. I will get back to this point in a bit.

Months went by without posting. I felt discouraged that my first post had flopped so badly.

Then I saw an opportunity to write again through a DEV challenge. I could showcase my work again and even potentially win prizes. These extra incentives pushed me to share my second post.

This one gathered more reactions and even a couple of comments!

My motivation went back up and I was already thinking about my next post which I released just a week later.

I then started writing more and more posts. I saw the engagement and follower count increase over time. I kept going.

Things took a turn after one of my posts was awarded the highly coveted top 7 badge of the week. That really made my day and I felt that people were really tuned into what I was writing about.

From that point onwards I decided that I would write a weekly post on the platform so I can share my learnings, experiences and projects with the community. Aside from the odd week now and then, I am proud to say that I remained consistent with my writing goal.

Today I am proud of my progress achieved and even happier that I have a growing audience that enjoys engaging with my content. I even made multiple friends along the way!

I want to share with you a few reflections looking back at my first year with DEV. I hope you find inspiration in some of them.

Don't be distracted by vanity metrics. I know that I mentioned a couple of times the reactions count as being a source of motivation. Of course it would be!
Who wouldn't like getting engagement on a post they poured effort into writing and sharing with the world? However I would caution against fixating on just these reactions. I made the mistake of giving up after my first post due to the low engagement. In hindsight this was a mistake as months went by without me writing anything, reinforcing this feeling of disappointment. This was a mistake on my part and a lesson for anyone going through the same. This leads to my next point.
Be consistent. I can't overstate the importance of this. Some of your posts will perform better than others, and that's totally ok. What counts is to keep showing up over time. I never knew that the post that made it to Top 7 would be that specific one. But since I was posting regularly at that point it increased the odds of this happening. Being consistent is easier said than done.
Create a system. In order to become consistent I built in a habit of writing a weekly post. Writing has now become a part of my weekly routine where I dedicate an evening a week to writing my post.
Writing is healthy. I feel that writing is a moment of reflection for me that I need in my life. The weekly slot I block out to write is a moment for me to slow down, shape my thoughts and reflect. This is a weekly habit I am glad I picked up.
The more I write, the more ideas I get. You would think that writing one post a week is hard as you would eventually run out of ideas. However I find the opposite to be true. Everytime I write a post I get into a reflective state that gets me thinking of future post ideas.
Join DEV challenges. I have joined several challenges over the year and these pushed me to try out new tools and even collaborate on a post with other DEV members! I even won runner-up to one of the challenges which was a great moment.
Give before you take. This was a bug mistake I made when I first posted here on DEV. I thought I could promote a tool I made and get instant engagement. That is definitely the wrong way of thinking. Before I posted again I decided to engage with other members posts. Everyone is putting in effort to share their thoughts with the world. Acknowledge these efforts in others posts instead of just thinking about your own. Just think about it. If nobody engaged with anybody else, few people would keep posting.
Provide value above all. Don't write posts with the pure intent of selling a product to your audience. It's ok to share and mention what you are working on, but include valuable information that the user can take away from reading your post.
Have fun. Some of you might frown at this one but it is easy to start viewing posting as another task in your schedule. If this becomes the case I would advise taking a break from writing and only coming back once you feel that you want to keep writing. If you don't take any enjoyment out of posting, then what is the point?

As my first year at DEV wraps up, I want to thank all my followers for their engagement and also the community for being a safe space I can share my thoughts and experiences with, and learn from others.

I can't believe I have over 20k followers today. I am grateful to every single one of you!

Stay tuned for my year 2 recap!

Thank you DEV community: the Thinking Engineer Toolkit is live

Julien Avezou — Thu, 25 Jun 2026 12:58:12 +0000

Over the past weeks, I’ve been sharing a series of posts that gravitate around one question:

How do we use AI without outsourcing our judgment?

The engagement from this community in response to this series has been genuinely strong.

This indicates that the issue of cognitive offloading associated with AI use is real. It is a problem space that resonates highly amongst developers.

The comments, feedback, and discussions sparked along the way helped me sharpen the ideas behind what has now become The Thinking Engineer Toolkit.

A moment of gratitude

It has been a wonderful and insightful journey to share this series with you here, to learn from other engineers and builders, and explore how AI-assisted work is changing the way we think, build, and understand software.

Thank you for your inputs.

And to those who have also reached out to me to express their support, encouragement and kind words, I thank you deeply.

I look forward to many more discussions with you all.

I wanted to originally tag the most engaged members directly here but there is a 10 tag limit per post (rightfully so!). Since I didn't want to make anybody feel left out I will avoid doing this since there are definitely much more than 10 people I wanted to tag!

The posts that led to the Thinking Engineer Toolkit

The Toolkit was influenced by a series of posts I shared here on DEV, feel free to check them out:

Thinking in the Age of AI
Don’t let AI do your thinking: a practical guide for engineers
Thinking in the Age of AI — Team Edition
Don’t let AI break your collective thinking: a practical guide for engineering teams
Thinking in the Age of AI — Builder Edition
From vibe coding to clear thinking: what non-technical builders need in the age of AI
AI Thinking Balance Tracker
The 4 cognitive archetypes of developers using AI
Prompt System Guide
The missing layer in prompt engineering: thinking quality
System Comprehension Heatmap
Your Codebase Has Technical Debt. But Does Your Team Have Comprehension Debt?

Each post explored a different part of the same bigger problem:

AI is making us faster, but speed is not enough if understanding can't keep up.

Why I started The Thinking Engineer

I started The Thinking Engineer because I kept noticing a tension in my own workflow.

AI was helping me move faster.

It helped me brainstorm, debug, refactor, write, and build.

But I also noticed that if I used it passively, it could make my understanding thinner.

Sometimes I was thinking better with AI.

Other times, I was letting AI think too much for me.

I was confusing productivity with removing friction.

That distinction matters.

Because engineering is not just about producing code.

It is about judgment, tradeoffs, debugging, communication, system understanding, and knowing when something looks right but is actually shallow.

That is the problem I want to keep exploring:

How do we build effectively with AI while preserving the thinking skills that make engineering valuable?

What is inside the Thinking Engineer Toolkit?

The Toolkit brings together 6 resources:

1. Thinking in the Age of AI

A guide for individual engineers who want to use AI without weakening their own reasoning, learning, and technical intuition.

2. Thinking in the Age of AI - Team Edition

A guide for engineering teams that want to preserve shared understanding while adopting AI-assisted workflows.

3. Thinking in the Age of AI - Builder Edition

A guide for builders, founders, and non-technical creators using AI to build software without losing sight of the systems they are creating.

4. AI Thinking Balance Tracker

A spreadsheet to help developers notice how they use AI across different cognitive modes: learning, generating, debugging, reflecting, and executing.

5. System Comprehension Heatmap

A spreadsheet to help teams identify where system understanding is strong, fragile, or dangerously concentrated.

6. Prompt System Guide

A practical guide to using prompts not just to get better AI outputs, but to improve thinking quality.

Why bundle them together?

Each resource can be used on its own.

But together, they form a complete system.

The guides help you reflect.

The trackers help you observe patterns.

The heatmap helps teams surface comprehension debt.

The prompt guide helps improve the quality of your AI interactions.

Combined, they create a practical workflow for asking:

Am I using AI intentionally?
Do I understand what I am building?
Is my team preserving shared understanding?
Are we moving faster in a way that compounds learning?
Or are we moving faster in a way that hides fragility?

Based on my experience, this is the Toolkit I wish I had from the beginning: a way to create better habits around the questions that matter.

The bigger picture

I think the next phase of software engineering will not only reward people who can use AI tools.

It will reward people who can use AI tools while preserving judgment.

The engineers and builders who stand out will be the ones who can ask better questions, validate outputs carefully, understand systems deeply, and keep learning instead of just delegating.

That is what I mean by being a Thinking Engineer.

What I’ve learned from sharing this work

One thing I’ve appreciated from the DEV community is that the general consensus is not simply whether AI is good or bad.

It is more nuanced:

How do we use AI well?
Where does it help?
Where does it create dependency?

That is the conversation I want to keep having.

The nature of our roles is changing.

It is exciting and scary at the same time.

We are all figuring this out at the same time.

Get your Toolkit today

I want to share The Thinking Engineer Toolkit with you today free to help engineers and builders work effectively and sustainably with AI assistance. If you find it valuable, I would also appreciate any support so I can keep investing my time in creating such resources.

You can access the toolkit here.

Looking ahead

I would love to hear how you are approaching this in your own workflow:

How do you avoid over-relying on AI?
Do you have rules for when to use AI and when to think first?
Are you seeing comprehension debt emerge in teams or codebases?
What would make this Toolkit more useful in practice?
What should I improve next?

What Kind of AI-Assisted Developer Are You? Take the quiz.

Julien Avezou — Mon, 22 Jun 2026 13:22:01 +0000

AI makes us faster, but does it make us better engineers, or just more dependent?

As a follow-up to my post on the The 4 Cognitive Archetypes of Developers Using AI, I wanted to created a quiz as a self-assessment for AI-assisted development habits.

My previous post sparked many interesting discussions and insights. I took some of those elements and put together a series of questions to help evaluate how you are using AI as a developer.

The 4 Archetypes include:

AI Architect: owns the problem, uses AI as leverage

AI Balancer: productive with AI, still protects judgment

Autopilot Builder: fast, but may accept output too quickly

AI Passenger: lets AI do too much of the cognitive work

This assessment scores answers across dimensions:

ownership
reflection
dependency
leverage
verification
speed bias

The questions are based on everyday engineering decisions:

debugging production issues
reviewing AI-generated code
writing tests
refactoring
working with unfamiliar libraries
explaining AI-assisted PRs
documenting complex changes

Here is my Cognitive Archetype for example:

Each results page also displays a breakdown of associated strengths and weaknesses and recommended actions to improve your cognitive score.

Here are my results:

I want to clarify that I am not collecting or persisting any user data as part of this project. It's just a small tool I wanted to share to keep the conversation going and hopefully inspire some of you.

You can take the quiz here and share which archetype you got!

Building a Chrome Extension to Make AI Use More Intentional

Julien Avezou — Mon, 15 Jun 2026 14:44:53 +0000

After posting several articles about the impact of AI on developers and sharing resources to help mitigate some of the risks, I wanted to share a new tool I've been building and experimenting with.

I introduce you to ThinkMode!

A chrome extension that helps developers choose a thinking mode before prompting AI, and calculate the associated cognitive cost after prompting AI.

AI makes it easy to skip thinking.

This tool helps slow down and integrate thinking before and after prompting the AI.

As a browser extension it can be easily integrated into your everyday LLM chat prompting workflow.

The Idea

Before opening a prompt, ThinkMode asks you to describe what you are trying to do.

It then recommends one of 5 modes:

Explore: understand the problem before solving it
Challenge: pressure-test an existing plan
Decide: compare options and tradeoffs
Audit: review quality, correctness, tests, and edge cases
Reflect: learn from what you just did

The goal is to match the prompt with the kind of thinking intended for the task.

The tool also includes a manual AI usage log.

After using AI, you can log how you used it.

Usage is grouped into three categories:

Supportive: AI helps expand your thinking
Mixed: AI saves time but may compress understanding
Risky: AI may replace your judgment

Each log adds to a cognitive cost meter. Riskier usage fills it faster.

Cognitive cost measures tradeoffs between using AI to expand understanding vs outsourcing judgment.

When the meter is full, ThinkMode temporarily pauses supported AI chat pages for 5 minutes.

Most developer tools optimize for speed.

I wanted to experiment with a tool that introduces intentional friction in order to surface reflection.

How it works

ThinkMode is a Manifest V3 Chrome extension built with React, TypeScript, and Vite.

The architecture includes:

a content script detects supported AI chat pages
a floating button opens the extension
a background service worker coordinates the side panel
a React side panel handles the main workflow
shared TypeScript modules handle recommendation logic and prompt generation

The extension currently supports ChatGPT, Claude, and Gemini pages.

There is no backend nor LLM API call involved.

ThinkMode does not read conversations, scrape page content, send analytics, or store data remotely.

The recommendation engine is deterministic. It uses simple keyword rules to choose a thinking mode which felt reasonable considering this is an MVP.

What I Learned

Sometimes the useful AI tool is not the one that gives you a better answer.

It can be the one that helps you ask a better question.

I'm curious:

Have you ever caught yourself accepting an AI answer before fully understanding the problem?

If so, what habits or tools help you stay engaged in the thinking process?

How to install

You can download the extension free here from the chrome web store

Otherwise you can run the extension locally using developer mode from chrome extensions. The code is open source here on github.

Feel free to fork it and adapt it to your own needs.

Would really appreciate a star or review if you find it useful!

If you can think of ways to improve this tool or want to see other features, let me know in the comments!

I Built an Interview Prep Tool Instead of Grinding LeetCode

Julien Avezou — Mon, 08 Jun 2026 13:20:06 +0000

I am currently preparing for Software Engineer interviews.

Like many developers, my first instinct was to open LeetCode and start grinding problems.

It seems that most interview prep I see suggests grinding random problems.

Instead I decided to focus on understanding the underlying patterns rather than memorizing the problems.

Practicing structured retrieval and being aware of how everything connects together is key.

I'd rather deeply understand 20 patterns than superficially solve 200 problems.

Many interview questions are simply variations of the same underlying ideas.

So I built a tool focused on recognizing patterns, recalling templates, and explaining tradeoffs out loud.

With this app, you can practice the following:

DS&A pattern flashcards
Problem → pattern quizzes
JavaScript code template fill-ins
Complexity quizzes
System design cheatsheets
System design flashcards
Tradeoff quizzes
Explain-back scenarios

I am currently using the tool and am finding it useful in my interview preparation: once you start recognizing the pattern, the implementation becomes much easier to reason about.

I wanted to share the tool here in case it helps others preparing for interviews. I deployed it on Vercel to be easily used by everyone. But you can also run it locally.

Note that I don't collect or persist any data with this project. It uses local storage.
There is no login, you can just start practicing immediately.
The code is open source if you want to fork it and adapt it for your own needs.

Website
Repo

Tech Stack used for this project:

Next.js
TypeScript
React
Tailwind CSS
LocalStorage
Static typed data files

This project was also a fun experiment in AI-assisted development.

I feel that building internal tools that help me in my daily life is a great use case for AI.

Since I am actively preparing for interviews, I would love to gauge the community here and learn from you too:

How do you prepare best for SWE interviews? Any tips to share?

What preparation methods gave you the highest ROI?

I'm also exploring Software Engineer opportunities, so I'd be happy to connect with anyone hiring or going through a similar search.