DEV Community: Konark Sharma

I Know It’s AI, But It Still Feels Real

Konark Sharma — Mon, 06 Apr 2026 19:30:49 +0000

Lately, I’ve been thinking about how we talk to AI.

Not just for code or answers, but for understanding, for comfort, for something that feels a little more human.

And that thought led me here.

Can LLMs finally understand emotions?

I recently came across Anthropic’s latest research about LLMs understanding emotions, and I was surprised by it. It feels like this could change how LLMs respond to us. But does that mean the job of psychiatrists and therapists is done? Yes and no.

LLMs still don’t understand emotions like humans.

If someone scolds me for losing my favorite thing, I’ll feel angry and sad. That doesn’t happen with LLMs. They are still machines.

What has changed is their ability to understand patterns of emotions.

Because they are trained on a vast amount of human-written text like fiction, conversations, news, and forums, they start picking up how emotions are expressed.

This doesn’t mean they truly feel emotions.

But they are getting better at recognizing and responding to them, step by step.

What does this look like in practice?

If I tell an LLM: “I failed my exam.”

With an emotional pattern active, it might respond: “I’m sorry, that must feel really hard.”

Without that pattern, it might simply say: “You failed your exam.”

This creates a new kind of interaction. Responses that feel emotionally aware.

Not because the model feels something, but because it has learned what that kind of response should look like.

What’s actually happening?

The LLM is not feeling emotions. It is predicting them. During generation, it leans toward responses that match emotional patterns it has learned.

So instead of just predicting correct words, it predicts words that also fit the emotional context.

That small shift changes everything.

What does the future hold for us?

I feel LLMs are becoming more and more advanced. But in some ways, this might also make us more dependent. We already rely on people in our lives to share emotions, to feel understood, to be comforted.

If LLMs become really good at this, we might start replacing those human connections.

We all have someone we talk to. Someone who listens, understands, and comforts us. Now imagine an AI that can do this perfectly every time.

Since these models keep improving, they will get better at predicting exactly what to say to make someone feel better. With voice interactions, it could feel even more real.

Like talking to someone who always understands you.

What’s happening behind the scenes?

The more emotional data LLMs learn from, the better they become at recognizing patterns. They don’t feel. But they get better at predicting emotional responses.

Because they already have context about what we say and how we say it, their responses can feel very personal.

Over time, it might become harder to distinguish whether you’re talking to a human or an AI.

Should we fear it?

Maybe yes. Maybe no.

But one thing is clear. LLMs are becoming more advanced and more comparable to human-like behavior.

First, it was intelligence. Now it’s emotions.

What’s next?

Maybe the real question is not whether AI understands emotions.

But whether we start treating it like it does. Because the moment something responds in a way that feels right, we start trusting it.

We start sharing more. We start depending on it. Not because it feels. But because it responds like it does.

And that might be enough.

Should AI be able to simulate emotions this well? Or should there always be a clear line between human and machine?

You’re Not Stuck. You’re Just Growing Roots

Konark Sharma — Wed, 01 Apr 2026 09:45:34 +0000

The other day, I was walking in a park, just looking around, not thinking about anything in particular.

And then this thought hit me. A plant’s life feels very similar to a developer’s life. At first, it sounded strange. But the more I thought about it, the more it started making sense.

Both need time, care, patience, and the right environment to grow.

It Starts Small

Plants grow from seeds, and a developer also starts from a seed.

A plant’s life begins with a seed. We take a seed, place it in fresh soil, water it, give it sunlight, and take care of it until it finally starts to grow.

The moment it starts growing, that small happiness kicks in. We start taking even more care of it. Watering it daily, making sure the soil is good, giving it proper sunlight and nutrients.

This is everything the plant needs to grow.

The same goes for a developer.

We choose a seed, maybe Web Development, Mobile Development, DevOps, or anything else. We plant it in our mind and start growing it.

We learn languages like Python, C++, or Golang. We fail, but we keep watering it daily with practice. We give it sunlight by building small projects.

And one day, when we stop just watching tutorials and actually write our own code, that is when we grow out of the seed and begin a new journey.

Growing, But Still Fragile

With continuous care, a plant becomes a sapling. Then we move it into a bigger pot so it can grow into a strong tree.

New soil is added. More nutrients. More water. Now the plant needs more effort to grow further.

The same happens with a developer.

We start building projects, reading other people’s code, solving problems, and sometimes copying projects from tutorials. This gives us confidence.

We take on bigger projects, face more errors, and start solving them. Using our basics with new challenges helps us grow.

Every error becomes a way to grow bigger.

Growing Roots (The Hardest Phase)

This is the phase where most people think they are stuck.

The plant is growing, getting water, sunlight, and nutrients. But one day, the weather changes. Heavy winds and rain test its strength.

If the roots are strong, the plant survives. If not, it gets uprooted.

The same happens with developers.

Sometimes we skip basics and jump directly to projects. We copy code, build projects, and add them to our resume.

But when interviews come, reality checks everything. If we truly understand what we built, we can answer confidently. If not, it becomes obvious. That is why basics matter.

Even when learning from tutorials, always ask why. Why this line? Why this approach?

That is what makes your roots strong.

When Things Start Making Sense

With strong roots, the plant becomes a tree. It grows bigger, stronger, and more stable. It starts giving back.

People sit under its shade. Its soil helps other plants grow.

The same happens with a developer.

Now the developer works on real projects, helps others, and uses their knowledge effectively.

People start coming to them for help. They guide juniors, train interns, and contribute more.

They start earning well and moving closer to their goals.

When Everything Falls Apart

Then comes a difficult phase.

The tree starts shedding leaves. It looks empty. Dry. People avoid it. Some even complain about it.

The same phase comes in a developer’s life.

Sometimes, they lose their job.

After putting in so much effort, suddenly they are no longer needed. People who once reached out for help slowly disappear.

It feels empty.

Starting Again, Stronger

But this is not the end.

If the tree is given water and nutrients again, it grows back. Stronger. Fuller. Better.

The same is true for developers.

If we keep learning, keep applying, and stay positive, things change. A new opportunity comes. A better path appears.

And life moves forward again.

Keep Going

Growth is not always visible.

Where things are quiet. Where results are not visible. Where it feels like nothing is working.

But that is where roots grow.

Roots don’t show on the surface. But they decide how strong you will stand when things get better.

Every developer goes through this phase.

Some quit here. Some stay, keep learning, keep trying, and slowly grow stronger.

If you feel lost right now, maybe you are not falling behind. Maybe you are just growing roots.

And when the time comes, you will grow in ways you cannot see yet.

What phase do you think you are in right now?

I Almost Didn’t Go to My First Tech Event

Konark Sharma — Mon, 30 Mar 2026 18:03:01 +0000

I almost didn’t go to my first tech event.

I kept thinking I wouldn’t fit in. Everyone there would know more than me. I wouldn’t know what to say or how to even start a conversation.

For a moment, I even thought of skipping it. But somehow, I still showed up.

After quitting my job, one thing I did was I started attending tech events. Once I started attending more events, it felt really good.

Every tech event comes with its own perks. Some are good, some are exceptionally well organized. Some provide practical knowledge about tools, while others give deep insights into tech.

What I Thought Tech Events Were

These are mostly community events, either paid or free, where you attend as a participant or a speaker. So far, I have only attended as an attendee. Maybe someday I will attend as a speaker.

What fascinates me the most is seeing speakers with immense knowledge explain complex things in simple ways while keeping the audience engaged.

Most companies organize these events to either share knowledge or promote their products through talks and demos.

I personally feel that smaller, more closed events are more interesting because you get more time to talk to speakers. In larger events, everyone wants to talk to them, so the interaction becomes limited.

Most of the events I attended were offline, which helped me meet new people and learn a lot more. I have also worked as a volunteer in a few events, so I have seen both sides.

Why I Still Decided to Go

1. What I Learned Just by Showing Up

I attend every event with one goal, to learn something new.

This mindset has made every event valuable for me. Every speaker comes with something to share, and picking even one useful idea makes the event worth it.

I always check the agenda beforehand and get excited about topics I want to learn. I keep my notes ready to capture ideas, project thoughts, or anything interesting.

One of the most memorable events for me was an OpenAI event. I got to see and hear Sam Altman. Many startups were built on top of ChatGPT, and founders were discussing real problems with the team.

That was the first time I heard terms like Context Window, RAG, Embeddings, Hallucinations, Model Weights, Temperature, Max Tokens, Vector Databases, and Context Length.

I was completely amazed. That same evening, I came back home and started exploring AI seriously.

2. Talking to People Was the Hardest Part

If you are a student, tech events can open many doors.

You meet people from different universities, exchange ideas, and sometimes even build things together. You can prepare together, practice interviews, or even work on projects that may turn into something bigger.

For working professionals, these events help in finding better opportunities, referrals, or even hiring.

For me, I have not deeply connected with many people yet, but I have had great conversations, learned a lot, and enjoyed interacting with others.

Since I was somewhere in between, having a degree but not working, I sometimes felt I did not fully belong to either side.

3. Learning by Doing Changed Everything

I always look forward to hands-on sessions more than talks.

Learning by doing and breaking things teaches more than just listening. I try to reach early whenever there is limited seating.

Through these sessions, I have learned things like re-ranking, built small MCP servers, explored AI Studio, and even got introduced to tools like Antigravity.

I also got to see demos of tools like Stitch before release, just by attending events.

4. The Unexpected Small Wins

My first event was special because I did not return empty handed. I got stickers and a pin, and it felt amazing.

Since then, every event gives something different. Some I use, some I keep. I have collected a lot of swags, though I don’t put stickers on my laptop, otherwise it would be completely filled.

And yes, almost every event had good food.

5. Seeing the Effort Behind the Scenes

Since I worked as a volunteer in some events, I got to see how things work behind the scenes.

Handling people, organizing sessions, managing chaos so that everything runs smoothly. Most volunteers were developers too, and everyone was helpful and humble.

It gave me a different perspective of how much effort goes into organizing a good event.

6. Why I Kept Going Back

Every event I attend leaves me with motivation. I always come back wanting to build something better, learn more, and improve.

These events give me the push to keep going.

I also have a goal now, someday I want to be on that stage and share my own experiences.

Many of the events I attended required shortlisting. Being unemployed made me feel like I might not get selected. But surprisingly, I got selected for many, and yes, I got rejected from some too.

It feels like luck sometimes, but being there and showing up made a difference.

7. What Changed in Me After Attending Events

I am an introvert. But I challenged myself to talk to people at events. Even when I felt less qualified, I still tried. Talking to people gave me confidence.

I started listening more, observing more, and slowly getting comfortable. I go to events with the intention to learn more and speak less.

I keep my expectations low and stay open to unexpected experiences. And many times, I ended up meeting amazing people who shared valuable insights.

Sometimes Just Showing Up Is Enough

Being at the right place at the right time matters.

I read the article from @maame-codes about getting an internship just by attending a tech event.

That is the kind of unexpected outcome these events can create.

If You Are Thinking About Going, Just Go

If you have never attended a tech event, try attending one. You might not get everything from the first event.

But you will definitely take something back.

Have you attended any tech events? How was your experience?

Small Prompt Tweaks That Saved Me Hours

Konark Sharma — Wed, 25 Mar 2026 17:43:11 +0000

I have been experimenting with AI these days and what I found from watching tutorials and prompting myself is that prompting isn’t really a skill. It is about thinking clearly.

If your thinking is vague, your output will be vague. If your thinking is structured, your output becomes structured. Being vague won’t get you results. Being specific and knowing exactly what you want will.

I’ll share some observations that helped me move from generic AI outputs to something more controlled and intentional. The gap between an average AI website and the ones you see on X isn’t the tool. It is the process.

Start With a Breakdown, Not a Prompt

We all build websites these days. Even non-coders are building cool websites using AI. But there is one problem. Most of them look the same.

Generic. Repetitive. Forgettable.

I tried building multiple websites using simple prompts and most of the outputs looked plain and basic.

To make them feel more refined and intentional, I realized two things matter:

The breakdown
The master prompt

Before writing any code, I now start with inspiration.

Instead of saying: 'Build me a modern website'

I prompt like this:
'Generate a complete design spec sheet including layout system, spacing, typography, color palette, animations and components for Figma.'

This gives me structure. Then I refine it. Then I convert it into a master prompt. Then I build.

The key rule: Fix one thing at a time

Always say: Fix only these items

This reduces hallucination and keeps the system focused.

Constraints Make AI Better

AI performs better with constraints.

Instead of saying: 'The layout feels off'

I prompt like this: 'Hero section max-width 1200px, centered, with proper padding and spacing'

Instead of: 'Fix design'

I prompt like this: 'Fix only spacing between sections and alignment of navbar'

Constraints reduce randomness.

Prompting Is Iteration, Not Perfection

Most people try to write one perfect prompt. That rarely works.

The real process looks like this:

Prompt → Output → Fix → Refine → Repeat

The faster you iterate, the better your results.

Let AI Write Better Prompts for You

Instead of trying to write perfect prompts yourself, use AI to generate better prompts.

I prompt like this: 'Convert this idea into a high-quality diffusion model prompt.'

LLMs understand structure better than us in many cases. Let them help you think.

Ask AI What You’re Missing

One of the most underrated uses of AI.

I prompt like this: 'Whatever you know about me based on that what am I missing in this? or What gaps exist in my knowledge?'

This shifts AI from answering questions to improving your thinking.

Add Constraints to Reduce Hallucination

When conversations get long, hallucinations increase. Instead of blindly trusting outputs, guide it.

I prompt like this: 'If you are not sure, say I don’t know. Provide a confidence score for your answer'

This makes responses more grounded.

Control the Way AI Writes

AI has a very predictable writing pattern. To avoid that, guide it.

I prompt like this: 'Avoid sentence structures like “not just X but Y”. Use direct and clear sentences. Be creative but avoid generic phrasing'

This improves output quality instantly.

What I Realized

Prompting is not about writing better sentences. It is about thinking better.

Most bad outputs come from unclear thinking. Not bad models.

The better you think:

the better you structure
the better you guide
the better you iterate

The better your results.

The difference is not in tools. It is in how you use them. AI doesn’t replace thinking. It amplifies it.

What is one prompting technique that actually worked for you?

How I Got Out of the “Why Not Me?” Loop

Konark Sharma — Wed, 18 Mar 2026 18:24:39 +0000

I opened LinkedIn. Someone got into Google.

And for a moment, I felt like I was doing everything wrong.

Jealousy is the thief of joy.

One of the hardest lessons I’ve learned is to stop comparing myself to other developers. Every developer has their own journey, and everyone follows a different path.

I usually don’t compare myself to others. But there are moments when you feel stuck, and suddenly everyone else seems to be moving forward.

You start asking yourself:

"Am I doing it wrong?"

"Why am I not getting shortlisted?"

"What is the reason for my failures?"

And then comes the worst one:

"Am I even worth it?"

When It Started

This started when I began my journey as a developer.

I learned HTML, CSS, JavaScript, and then moved to React. I wanted to get better. But instead, I got stuck in tutorial hell.

Watching one video after another. Every creator had a different opinion about careers. And I felt like once someone becomes successful, they start believing their path is the only way.

I saw people leaving jobs at big tech companies and starting YouTube channels or selling courses. Every thumbnail said:

“Why I left Google”, “Why I quit Microsoft”.

And here I was, just trying to figure out how to get into the industry.

One night, I refreshed my inbox.

Rejection. Again.

That was the moment I realized something was wrong not with my effort, but with how I was thinking. Leaving my job and getting rejected pushed me into a loop.

Applying at night. Rejection emails in the morning. Then opening LinkedIn and seeing someone else succeed. Again and again.

I didn’t have mentors to talk to. I stopped reaching out to college mentors. Most of my guidance came from ChatGPT helping me with resumes and projects.

I was really interested in frontend. I discovered Awwards and was completely amazed. Every website felt unreal. The design, the creativity, the interactions. I watched people build them. But I didn’t just want the code. I wanted to understand how they think.

What Changed

Does this story have a perfect ending where I completely stopped comparing? No

Comparison is natural. But what changed is how I react to it.

The intensity is much lower now. Because I started focusing on what I can control.

Reading, Writing, Building, Learning

The more I built, the less I compared. Because progress gives clarity, and clarity kills doubt.

Comparison will always exist. But instead of letting it break me, I started using it as a signal. A signal that I need to improve not a reason to doubt myself.

What Actually Helped Me

I stopped measuring my progress with other people’s timelines
I reduced LinkedIn scrolling and increased building time
I started writing what I learn instead of consuming endlessly
I focused on small wins instead of big expectations
I treated comparison as feedback, not failure
I built projects even when they felt imperfect
I asked questions instead of staying stuck
I tracked my own progress weekly
I learned from others without trying to become them
I reminded myself why I started

Comparison doesn’t slow your progress. It makes you forget that you’re already making some.

I still compare sometimes. But now, I don’t let it define me. I use it to adjust, not to doubt. Because the goal is not to be better than others. The goal is to be better than who I was yesterday.

What is the one thing that helped you stop comparing yourself to others?

Are You Really a Developer? The Mindset That Matters More Than Code

Konark Sharma — Sun, 15 Mar 2026 19:14:11 +0000

Many people learn to code, but not everyone develops a developer mindset. The difference often comes down to a few simple traits that shape how we learn, debug, collaborate, and grow. These days everyone wants to be called a developer, but many do not truly have a developer’s mindset. You might ask what I mean by that.

A developer’s mindset is a mix of personality traits that helps someone grow from being a coder to an experience level developer. Of course experience matters. Senior developers have spent years working in their field. But there are certain traits that, when combined together, help someone become a better developer.

With the rise of vibe coding, everyone wants to be called a developer. The moment someone learns HTML, CSS, and JavaScript they start thinking they have become a developer. But the real question is, are you really a developer?

Let us look at a few traits.

Curiosity Drives Learning

Being curious is one of the most important traits that can help you become a better developer. Curiosity can take you in unexpected directions.

For example, my curiosity led me to this platform where I started learning from amazing writers who share great content. I read articles with the curiosity of learning something new every time.

Through that curiosity I have learned about BiFrost, LLMs, key takeaways from 1 Million dev.to Articles, and many other topics. I attend tech events with the curiosity to learn and meet new developers. Everyone has their own stories and learning experiences, and it feels amazing to listen and learn from them.

I am an introvert, but I still comment, read, share, and participate because curiosity keeps pushing me forward. Curiosity helped me learn React, Golang, Kubernetes, and even experiment with vibe coding.

Staying curious has helped me learn a lot. I write mostly to share my experiences and learn from others as well.

Debugging Is Where Real Learning Happens

One thing that is common in every developer’s life, other than successful deployments, is errors. Debugging and learning from errors can make you a better developer.

Most of us copy an error and immediately paste it into an LLM to find the answer. But before doing that, it is important to read the code and understand where the error is coming from.

Sometimes the error is very small, maybe just a missing semicolon. But by immediately using an LLM we end up going in a completely different direction.

When we debug our code ourselves, we learn how the system actually works. That knowledge helps us solve similar problems in the future.

If we always rely on copying errors and pasting them into LLMs, we never really understand what went wrong. Senior developers often say that debugging is one of the best ways to improve as a developer.

Great Developers Ask for Help

None of us know everything. Some people are better in DevOps, some in writing articles, some in debugging, some in frontend, and some in backend.

If I get stuck somewhere, I prefer asking for help. Someone else's experience can often solve a problem much faster.

For example, asking Hadil about BiFrost, asking Sylwia about web development, asking Francis about GitHub PRs. They are all amazing creators who share their knowledge.

At first there is always hesitation when asking for help. But the developer community is usually very supportive. Most developers are willing to help if you ask.

I once read something from Jim Rohn that stayed with me. Sometimes simply asking can open doors we never imagined.

Persistence Matters More Than Talent

I love this quote from Atomic Habits that talks about improving one percent every day.

If you can get 1% better each day for one year, you’ll end up 37 times better by the time you’re done.

If someone has a habit of giving up easily, becoming a developer will be very difficult. Since the day I started liking computer science, I never gave up.

I have spent sleepless nights debugging code just to see it finally run. Sometimes I even dream about debugging problems. But the moment when the code finally works and deploys successfully is one of the best feelings.

Life will give you many reasons to quit being a developer, but you have to find one reason to continue.

For me, that reason is learning and writing. Reading how others write and explain concepts motivates me to keep improving.

Stepping Away Can Solve Problems

This is a mindset I developed while coding and debugging.

Sometimes errors are persistent and keep repeating. Many developers say vibe coding is more about debugging than generating code.

When I get stuck with an error or cannot think clearly, I take a short break and focus on something completely different. This helps calm my mind. When I return, I often see the problem more clearly.

Sometimes the solution is obvious after the break. Taking a pause helps me restart with better ideas and better prompts.

Shipping Projects Is How You Improve

Most developers have unfinished projects or ideas they once loved but never completed. I also fall into that category. I had many unfinished projects that I stopped working on midway.

But now I try to complete and deploy them instead of abandoning them. Deploying projects forces you to write more code and face more debugging challenges.

And more debugging means more learning.

Reading Other People’s Code Makes You Better

Another important trait is the ability to learn from other people’s code.

Every developer writes code differently. By studying other developers' work, you can learn better patterns and approaches.

Senior developers sometimes write two lines of code that solve a problem which might take a beginner ten lines.

I often check GitHub repositories shared in articles on this platform. Seeing how experienced developers structure their code helps me improve my own coding style.

Know Your Reason for Being a Developer

Your reason for becoming a developer should be clear.

If someone chooses this field only because it pays well or because everyone else is doing it, it becomes difficult to stay motivated.

There must be curiosity and a desire to learn.

My reason is simple. I genuinely enjoy being a developer. Learning new concepts, reading articles, watching technical videos, and exploring system design never feels boring to me.

Technology keeps me engaged and entertained. Sometimes when I feel bored, I read interviews, study system design, or explore new tools.

These are some traits that I feel help shape a developer’s mindset. Being a developer is not only about writing code. It is about curiosity, patience, persistence, and the willingness to keep learning. Every bug, every project, and every conversation with other developers teaches something new. The more we stay curious and open to learning, the better we grow as developers.

What are the traits you believe are important that I might have missed?

What Quitting My Job Taught Me About Tech

Konark Sharma — Wed, 11 Mar 2026 11:04:06 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

So it is finally time to write about the past year. It has truly been a roller coaster for me. Last year I quit my job to search for a new one. I am still looking, but the experiences I gained over this year are immeasurable. There is a lot to talk about, so let us begin this journey.

Learning Through Hackathons

After quitting my job, I quickly revised my web development skills and started participating in hackathons to gain more experience. I participated solo because I felt I did not yet have a strong hold on my stack.

I had built a few MERN projects during college, but they were not great. So this felt like a redemption arc for me to improve my skills while participating in hackathons.

Most hackathons are focused on students, so it was difficult to find ones open for working professionals. After a lot of searching I finally found one. The theme was to convert an old website into a modern version.

I chose cplusplus.com since I had been using it and coding in C++ since school. While building it, I faced many errors and struggled with choosing the right libraries and animations to make the website modern but still subtle and usable.

After all the effort I submitted my revised version and received a participation certificate. It felt great to build something and receive recognition for it. I was happy but also a little sad that I did not win.

That made me continue searching for places where I could build and learn more. Eventually I found my go to platform for challenges which was Dev.to.

Reflection
Participating in hackathons taught me that building something imperfect is still better than not building at all. Even though I did not win, the experience helped me understand my stack better and pushed me to keep improving.

Finding My Voice in Writing

When I discovered Dev.to I was amazed by the quality of content and the Dev Challenges on the platform.

Today I also received a badge for completing one year on the platform, so writing this makes me a little emotional while looking back at the journey.

Initially I did not have the courage to publish an article. But after pushing myself I finally wrote my first article. After publishing it I received the Writing Debut badge which made me very happy. Around thirteen people liked the article and that small appreciation made me enjoy writing even more.

After that I started writing more articles for Dev Challenges hoping that someday I might win one.

But my next few articles did not perform well and I began to feel that maybe technical writing was not for me. I did not know whom to ask for guidance, so I took a break from writing and started reading other amazing articles on the platform.

On New Year’s Eve I challenged myself to write thirty articles in thirty days, but again I did not have the courage or ideas to continue.

Then in February the Dev Challenge called New Year New You Portfolio Challenge appeared and I thought this would be the perfect opportunity to start again. I wrote about it and slowly started publishing more articles.

Though I could not complete the challenge, writing gave me more clarity about how to write, what to write, and what works and what does not.

Then something unexpected happened. I wrote the article Vibe Coding Reality Check . I did not expect much from it but it turned out to be a turning point for me. That article made me more serious about writing and sharing my experiences.

Reflection
Writing my first article showed me that sometimes courage is the hardest step. Once I pressed the publish button, everything else became easier. The small appreciation I received gave me the confidence to keep writing and sharing.

Learning to Network at Tech Events

I am an introvert by nature, but I wanted to overcome my hesitation in talking to strangers. Attending tech events alone became one of the best ways for me to learn and network. I lost count of the events I attended because each one taught me something new.

If you have the ability to listen, you can learn from anyone.

At first it was difficult because many people at these events were either students or professionals with great jobs while I was unemployed. That made me feel like a misfit sometimes and I overthought a lot before talking to anyone.

But things slowly changed. In my last few events I realized that I could talk to people, crack jokes, and introduce myself to strangers.

Even today I still feel hesitant at first, but I set a small goal for myself at every event which is to talk to at least one person.

For an introvert like me, this has been a big step forward.

Reflection
Attending tech events helped me realize that networking is not about being the most confident person in the room. It is about being curious and willing to talk to people and learn from their experiences.

Sharing My Work on LinkedIn

Earlier I was not comfortable posting things on LinkedIn. It always felt like boasting about achievements. But once I started learning about personal branding I began to see LinkedIn differently.

My goal is not to boast but to share content that helps people grow. Many people already do this, but I want to find my own way of sharing experiences and learnings.

Posting the articles I write and sharing about events I attend gave me confidence to express my thoughts publicly. It also helps recruiters see that you are building and learning something rather than leaving your profile empty.

And honestly, the first like on a post always feels great.

Reflection
Posting on LinkedIn helped me understand that sharing your journey is not about showing off. It is about documenting your learning and connecting with people who might benefit from it.

Learning by Building Projects

I never thought I would build many projects because I felt new to the tech stack.

But with my existing knowledge and some vibe coding, I built a few projects that I really like. They might not solve big real world problems but I am proud of how they turned out.

Turning an idea into a project takes time, effort, and many errors. For me it was time, effort, and sometimes dealing with hallucinations from AI tools.

More than the projects themselves, I feel proud about writing about them. Writing helps me transform what I learned into words and explain errors, solutions, and outcomes.

Building projects and then writing about them helped me remember problems better and understand solutions more deeply.

Reflection
Building projects reminded me that ideas only become real when you actually start working on them. Every bug and every error teaches something new.

Dealing With Rejections

I applied to many jobs. Some applications were rejected while some progressed to interviews and multiple rounds.

Editing my resume, applying for roles, and getting shortlisted felt exciting. It sometimes felt like waiting for a big opportunity to arrive.

I learned a lot during this phase about job applications, referrals, resume feedback, and interview preparation.

I once had an in person interview which lasted two days. Day one had technical rounds and day two included an interview with the CEO.

Since there were many candidates, my interview was moved to the second day which meant I was the only candidate that day. Instead of overthinking I decided to approach it with confidence.

I went in with the mindset of Veni Vidi Vici. I came, I saw, I conquered.

The conversation lasted around an hour and I left feeling confident. I was hopeful about the result but unfortunately I was not selected.

It was disappointing, but life moves forward. I continued applying and the cycle continued.

Reflection
Rejections were difficult at times, but they also taught me resilience. Every interview helped me understand where I could improve and how to prepare better for the next opportunity.

Learning From the McKinsey Forward Program

Through tech events I came across the McKinsey Forward Program.

It is a multi week learning program designed to equip people at different career stages with practical skills for the future of work. The experience was very different from traditional learning. The program focused on teamwork, sharing ideas, feedback, and practical problem solving.

Many of the concepts were things I already knew, but the program taught me how to apply them in real situations. I still keep my notes from the program and plan to review them before joining a new company someday.

Reflection
The Forward program helped me understand that technical skills alone are not enough. Communication, teamwork, and feedback are equally important in the workplace.

Learning Through Google Arcade

Google Arcade was another interesting experience for me.

It combines learning with a game like environment. I participated from July to December.

Programs like Arcade Adventure, Arcade Voyage, Arcade Trail, Sprint, and Skill Badge give you points for completing learning tasks. The more points you earn the more Google swag you unlock.

Through this program I learned about Terraform, BigQuery, Google Cloud Platform, and several other tools. It made learning cloud technologies feel fun and engaging.

Reflection
Google Arcade showed me that learning can also be fun. When learning feels like a game, it becomes easier to stay curious and keep exploring new technologies.

Looking Ahead

My biggest milestones are still ahead of me.

Getting a job in tech and contributing to open source are the two goals I want to achieve next.

A special thanks to everyone in this community who helped me and made me feel like a part of it. The support and kindness of this developer community has meant a lot to me.

There are also many amazing writers on this platform whose articles helped me learn new things every day like @pascal_cescato_692b7a8a20, @sylwia-lask, @ujja, @francistrdev, @dannwaneri, @hadil, @maame-codes , @the_nortern_dev, @luftietheanonymous, @itsugo and many more. You should definitely check them out.

Over the past year I faced uncertainty, learning curves, rejections, and many small victories. But each experience helped me grow a little more.

This year taught me persistence, curiosity, and the importance of sharing what we learn. Even when progress feels slow, every step still moves you forward.

What is one lesson the tech industry has taught you that changed how you approach your work or learning?

The Women Who Helped Me Grow as a Developer

Konark Sharma — Sun, 08 Mar 2026 08:20:47 +0000

Last night while reading articles on Dev.to, I realized how many amazing women I have learned from this year. From development to DevOps to community building, many of the things I understand today came from their articles, videos, and experiences they shared with everyone.

Since today is International Women’s Day, I want to dedicate this article to all the women and congratulate them on this special day.

We all have women supporting us in one form or another. It could be a mom, sister, best friend, girlfriend or wife. So I want to share what I learned from the women I met or know.

My Motivation

This goes to my mom and to every mother who supports their child no matter what the situation is. The hard work and dedication that we learn in life often comes from our mothers.

My mother has a big influence on me. The other day I saw a reel on Instagram saying that if you want to stay motivated and hardworking, look at your mother. She cooks food, takes care of the house, and takes care of everyone even when she is sick. This shows the level of dedication and hard work love can bring.

She cheers for us when we get good grades and takes care of us when we get injured for the first time. A proud moment for her came when I was in 8th class and won my first award. It was such a big deal for her because no one in the family had ever received an award like that before.

When she saw my picture in the school magazine she cut it out and kept it safe to frame it later. It was not a big moment for me at the time, but it meant everything to her.

I will always try to give her the best life for all the hard work, love, and care she has given me.

Thank you so much mom.

My Inspiration

This goes to @jess, the cofounder of Dev.to.

I always look forward to her articles because she brings Dev Challenges and Dev Education Tracks for the community. The Dev Challenges contain amazing ideas that encourage developers to build and share.

She was the first person to comment on my post because she liked the idea. I was stunned that the cofounder found my idea interesting. I was starstruck for days and it motivated me to write better articles every time.

The Dev Challenges posted by her are the main reason I am on this platform. In 2025 when I discovered Dev.to, I wanted to explore and write articles but I did not know where to start. Then I found the Dev Challenges and the Runner H AI Agent Prompting Challenge. That was the first Dev Challenge I participated in and once people liked it there was no going back.

I was also amazed by the badge system. When I wrote my first article I received a notification for earning the Writing Debut badge. That was a proud moment for me.

Later I also got the opportunity to volunteer as a judge for some challenges. After every challenge ends I wait excitedly for the email from Jess Lee inviting volunteer judges. It gives me an opportunity to read amazing submissions and learn from how developers explain and build their ideas.

A huge thanks to @jess and her team for building such an amazing platform and such a supportive developer and writing community.

My First Dev Friend

This goes to @hadil.

While exploring the platform and reading amazing articles, one article by her caught my attention. It was this Dev Challenge Frontend Challenge Halloween Edition Perfect Landing. It was such an amazing article and website that I bookmarked it so I could read it again and learn from it.

I started following her and even connected with her on LinkedIn. My first message to her was about how amazing her articles were, and since then she has motivated me to write better articles.

Her articles are very informative and contain deep knowledge. One day I scrolled through her profile and started reading multiple articles. I got stuck in a loop reading them.

I love many of her articles, but my favorites are the ones about Final Round AI where she explains how it helps in clearing interviews. Her series for interviews is also one of my favorites.

She also writes about BiFrost, which was something completely new for me and helped me learn about it in simple language.

I always look forward to her articles because they contain a lot of knowledge and the dedication she puts into writing them is worth every word.

Thank you so much @hadil for writing such amazing content and motivating everyone.

My Mentor

This goes to @sylwia-lask.

I am a web developer and I mostly read and write about web development. One day I came across her article titled Is Learning CSS a Waste of Time in 2026. It was exactly the same time when I was improving my Tailwind skills and I was amazed by how clearly she explained everything.

She usually starts her articles with a curious question and then explains the topic using her knowledge.

Her ten plus years of experience clearly reflect in her articles. Whenever I read them it feels like attending a Dev.to class by Sylwia Laskowska.

Her recent article 16 Modern JavaScript Features That Might Blow Your Mind came at the perfect time because I was revising JavaScript. It felt like a blessing when I read it.

The depth of knowledge and the simple writing style makes her articles amazing.

I always look forward to her articles just like a student waits for the teacher to start a lecture in the classroom.

Thank you so much @sylwia-lask for writing such amazing articles and being my mentor.

My Docker Teacher

This goes to TechWorld with Nana.

She is an amazing YouTuber and an amazing teacher. When I wanted to learn Docker, Golang and DevOps concepts, I came across her YouTube channel.

The simplicity with which she explains complex topics makes everything easy to understand. It feels like asking an AI model to explain something like I am five years old.

Through her videos I learned about Golang, Docker, Kafka and many other DevOps tools. She is the main reason I understand these technologies today.

These tools are often mentioned in system design discussions and her tutorials helped me understand them from the basics.

Everyone should check out her channel for all the amazing DevOps content.

Thanks for your lessons on Docker and Golang.

While reading their articles and watching their content, I realized how much technical knowledge I gained from them. Many of the concepts I understand today in JavaScript, DevOps, Docker, Golang, and development practices came from creators like them who openly share their knowledge with the community.

The tech world becomes better when knowledge is shared, and these creators are doing exactly that by helping thousands of developers learn and grow every day.

Comment and tag your favorite female creator and write one line about what you learned from them.

Anime x Code: Forge Your Isekai ID

Konark Sharma — Mon, 02 Mar 2026 04:45:37 +0000

This is a submission for the DEV Weekend Challenge: Community

I am a huge fan of anime. I love watching anime. Anime is a very big part of how I spend my free time, there's so much I learned from the characters.

I completely enjoyed shows like Naruto, Black Clover, One Punch Man, and many more. There are many lessons I learned from the MCs of these shows, like never giving up after losing, getting back up after failure, and being kind to others.

Since I love anime so much, I thought of making this project to give fellow anime lovers a chance to finally experience their own dream isekai moment.

We have all seen it in anime that moment when the system appears and reveals your identity, skills, and stats. I wanted to recreate a small piece of that feeling in a fun, interactive way.

This card not only lets you enter the dungeon as an A-rank adventurer but also helps you present yourself to your friends and share your stats.

Isn’t that cool?

The Community

There is a large community of anime lovers, and almost everyone secretly has their favorite main and side characters.

Anyone who watches isekai anime knows the classic beginning. Either death or summoning into another world. When the story starts, you usually don’t know anything about yourself who you are, what your skills are, or what your role is.

You explore the world, and then suddenly… click. A new window appears. Voila your stats screen.

It tells you:

your level
your skills
your useless skills
and your potential to defeat the demon king or save the kingdom

That moment always fascinated me.

What I Built

I wanted to build something playful that combines anime culture with an interactive web experience.

Most profile generators feel very serious. I wanted something fun, slightly chaotic, and very shareable for anime fans who always imagined their own Isekai stats screen.

So I added a twist and created an Isekai ID generator.

Anyone who wants to enter the Isekai world just needs to enter a few details. The system judges you based on your inputs and assigns you a rank.

Top tiers include:

National Level
S Rank

It also helps the kingdom determine whether you are Commoner, Rare, or Epic based on your skillset are.

How it works

Method of Arrival

You choose how you entered the Isekai world: Truck-kun, Overwork, Summoning.

If you were summoned, maybe you got lucky. If Truck-kun hits you… well, you know what happened.

Party Role

You can answer realistically or go full fantasy. Example: Healer, Tank, App Developer, Shadow Strategist

Your choice defines your role in the party.

Useless Cheat Skill

This is the fun part. You can be realistic or completely chaotic. Examples: Copy Machine (Ctrl C + Ctrl V master), Professional Procrastinator, Sand Castle Architect

Sometimes the most useless skills are the most entertaining.

Current Quest

What are you doing right now? Examples: Find a Bathroom in the Dungeon, Trying to solve a bug in my code, Farming XP in production

Fantasy or reality your choice.

Plot Armor

The most important survival stat in any anime. The more stars you have, the longer you survive in the storyline.

No plot armor more risky life.

The moment you hit Forge Your Destiny, you get summoned and receive your personalized Isekai card ready to download and share with fellow anime fans.

The goal was simple: make something fun enough that people would actually want to share it.

Demo

The provided image shows the details you need to fill.

The provided image shows the generated card with the details filled.

The provided image shows the card generated.

The provided image shows how the card will look after downloading.

Code

Try the live experience here: Live Link
Explore the source code on GitHub: Github

How I Built It

Tech Stack

Frontend: React & Typescript
Styling: Tailwind / CSS
AI usage AI Studio
Deployment : Netlify

This project was a fun experiment in blending anime fantasy with interactive web design.

If you are an anime fan, you already know the feeling of wanting your own stats screen to appear one day. I just tried to bring a small piece of that experience into reality.

Would genuinely love to know the feedback on the project and whose your favorite character and what you learned from them?

Vibe Coding Reality Check

Konark Sharma — Thu, 26 Feb 2026 13:47:41 +0000

I was really excited about this hackathon because it was an offline event and completely focused on prompting and building a web game using AI.

But very quickly, I realized this experience was going to teach me much more than I expected.

The prototype had to be built only using AI Studio or Antigravity, so I’ll share the lessons I learned while vibe coding under real pressure.

Round 1: Getting Hands On

There were two rounds. The first was a demo round where we had to build something using the AI tools and get familiar with the workflow.

Since I had already worked with AI Studio while building my portfolio in the New Year, New Me Dev Challenge, I was excited to try Antigravity, especially because it has a VS Code like feel.

What immediately stood out in Antigravity was its planning first approach.

The moment your prompt hits, it:

analyzes the request
creates a plan
executes tasks step by step

Even better, I could modify the plan according to my needs. That feature really stood out to me because it felt like AI was finally doing what it’s supposed to do: plan first, execute second.

My First Build (and Early Confidence)

In the first round, I built a game app using Antigravity.

I did hit several roadblocks, but my previous experience with AI Studio helped me move faster. The first iteration was surprisingly good.

Game sprites were generated using Nano Banana
Characters also came out quite well
Initial deployment worked

At that moment, I felt pretty confident. And then… I hit the wall.

Where Things Started Breaking

The more iterations I tried to push through Antigravity, the more issues started appearing.

I consider myself a beginner vibe coder, and one thing I’ve learned is:

The more you work with prompts, the more your prompting style evolves.

So I reset my approach, started fresh, and tried giving clearer prompts.

But under time pressure, hallucinations started creeping in.

The biggest issues I faced were:

Uploading code from Antigravity to GitHub
Deploying to Google Cloud Run
CORS related problems
Inconsistent executions

For some participants, the magic worked smoothly. For me not so much.

Still, I pushed through, submitted the prototype, and scored 46% overall.

Not great. But very educational.

The Reset Between Rounds

During lunch, instead of stressing, I cooled off and started talking to other developers.

This turned out to be extremely valuable.

I learned:

how others were structuring prompts
how they handled hallucinations
where they were getting blocked

That peer feedback helped me rethink my approach for Round 2.

Round 2: Changing Strategy

For the main round, I made a strategic shift.

Instead of forcing Antigravity, I moved back to AI Studio, mainly because:

deployment was more predictable
GitHub integration felt smoother
I could move faster under time pressure

I also simplified the scope moving from a 3D game to a 2D game and refining my prompts more carefully.

This time, the system responded much better.

Submission Attempts and Reality Check

We had four submission attempts.

Attempt 1: 50%
Criteria included:

Code Quality
Security
Efficiency
Testing
Accessibility
Google Services

My weak areas were clearly Security and Google Services.

Since I was relying heavily on AI Studio, I wasn’t fully aware of all the security gaps I might be hitting.

Attempt 2: Still 50%

I thought I had improved the code significantly but the score didn’t move. That was a reality check.

Attempt 3: 62.67%

This time I changed tactics:

asked the model to refactor more carefully
focused on structure
tested more deliberately

Glitch Hunt
This is the game I developed and submitted. Making it a newer version of the classic DuckHunt. It's still is in prototype phase.

I still didn’t make the top 10 but the learning curve was massive.

I also reviewed other teams’ web games and noticed a common theme: Everyone was fighting hallucinations and AI limitations in different ways.

Lessons I’m Taking Forward

1. Plan before you vibe code: Don’t jump straight into prompting without thinking through scope and data.

2. Stay flexible with tools: Sometimes switching platforms saves more time than forcing one tool.

3. Prompt clarity improves with iteration: The more precise the prompt, the better the output.

4. AI will hallucinate expect it: Save versions frequently and be ready to roll back.

5. Commit and deploy frequently: Version history saved me multiple times.

6. Peer feedback is underrated: Talking to other builders gave me insights I wouldn’t have found alone.

7. Different models excel at different tasks: I used GPT for prompt generation and Gemini for data heavy reasoning.

8. Don’t over iterate blindly: At one point I kept prompting without validating outputs, which created more confusion than progress.

9. AI tools still need developer judgment: Even when output looks correct, manual review is essential.

10. Time pressure exposes prompt quality: Clear prompts saved far more time than clever but vague ones.

This hackathon didn’t just test my ability to build with AI. It tested how clearly I could think under pressure. I’m still learning, still breaking things, and still refining how I work with AI tools.

Vibe coding looks fast from the outside, but in reality, the quality of prompts, planning discipline, and iteration strategy makes a huge difference.

Would love to hear from others what was the biggest roadblock you faced while vibe coding?

Interview Playbook: What Worked for Me

Konark Sharma — Sat, 14 Feb 2026 17:46:24 +0000

I have been through a lot of interviews, and I would love to share what I have learned and how I tackle different types of questions.

The approach I follow while giving interviews is KISS — Keep It Simple, Stupid.

I have been nervous many times and forgotten answers I prepared the whole night before and that’s okay. I take a deep breaths, drink water, calm myself before going into the interview so that I speak clearly and confidently. I don’t wanna come across as someone unsure of themselves.

I own and present what I have done confidently.

In Technical Interviews

When I'm given one or two problems to solve in front of the interviewer, I follow this approach:

1. Listen Carefully
Whenever the interviewer starts explaining the problem, I listen carefully. I don’t try to act smart and start solving it midway. I pay attention to every word and understand the examples clearly.

2. Draw an Example
An example can dramatically improve your ability to solve a question, yet many candidates try to solve it in their heads. If no example is provided, I create a simple one and explain the question using it. I think about possible edge cases as well.

3. State a Brute Force Approach
After understanding the example, I state a brute-force solution. Sometimes I can’t come up with the optimal solution immediately and that’s okay. I explain each step and why I chose a particular approach or algorithm.

4. Optimize
Then I try to optimize. If my brute-force solution has a time complexity of O(n²), I try to reduce it to O(n) or O(log n) where possible.
For example: If I initially use Bubble Sort, I may switch to Merge Sort or Quick Sort to improve efficiency.

5. Walk Through Your Thinking
At each step, I share my thought process with the interviewer.
I explain:

Why I chose this approach
The time complexity
Possible improvements

If my approach is wrong, I don’t panic anymore. I adjust and improve it on the spot. This shows adaptability.

6. Implement
After explaining my approach verbally or through pseudocode, I move into coding. If I forget something small like a method name, I ask “Can I quickly check this?” But I never copy-paste code. The interview is meant to test my ability.

7. Test
Finally, I test the code. If it’s on a coding platform, the test judge evaluates it. If it’s written on a document, the interviewer reviews it. This is often where real learning happens.

Think clearly. Speak clearly. That’s half the battle.

In Behavioral Interviews

Tell Me About Yourself

This is basic but often difficult. I follow this structure:

Current Role (headline)
College
Post-college journey
Current Role (details)
Outside of work
Wrap-up

This structure keeps the answer clear and straight to the point.

What’s Your Weakness?

I answer this in three steps:
Step 1 — Own It
“I used to be short-tempered.”
Step 2 — Explain the Trigger
“When I get stuck in loops or repeated blockers, I get frustrated.”
Step 3 — Show Improvement
“Now I take short breaks, reset, and return with a calmer mindset.”

The key is growth.

What Questions Should You Ask the Interviewer?

Before interviews, I research the company and prepare questions like:

What does success look like in the first 6–12 months?
How does the team balance quality and speed?
What’s the most technically interesting problem the team is solving?
How do engineers grow and take ownership?
How are technical decisions made?
Good questions show preparation and maturity.

Explain your projects

For explaining my projects, this structure has helped me a lot:

Before interviews, I prepare 1–3 projects where I played a central role.

Points I Keep in Mind During Behavioral Questions

Be Specific, Not Arrogant: Confidence is good. Arrogance is a red flag.
Limit Details: I limit details unless the interviewer asks for more. This keeps answers concise and structured.
Focus on “I,” Not “We”: Even though we work in teams, interviews evaluate individual contribution. I focus on what I did.
Give Structured Answers:

Nugget First : I start with a short summary of what I’m about to explain. Example: “I’ll tell you about a time I had to step up as a leader to deliver a project on time.” Then I explain.
S.A.R (Situation – Action – Result): I explain: The situation. The action I took. The result. Example: “At 2 AM, our production server crashed. I analyzed the logs, restored from backup, added a load balancer to distribute traffic, and improved load handling. As a result, downtime was reduced and performance improved.”

Be honest. Be structured. That’s usually enough.

Interviews are not about being perfect. They are about thinking clearly under pressure.

I may forget answers. I may make mistakes. I may not get every problem right. What matters is how I think, how I communicate, and how I adapt. This approach worked for me and I’m still improving it. I live by this quote.

I would love to know what interview strategies helped you the most.

Good vs Bad Prompting: What I Learned While Working With AI Models

Konark Sharma — Mon, 09 Feb 2026 17:49:37 +0000

I didn’t start learning Prompt Engineering to become an expert. I started because I kept getting inconsistent results while using AI tools in real projects. While reading about Prompt Engineering, I came across several prompting techniques that I found interesting and useful, and I wanted to share what I learned.

We are all very familiar with prompts. We use them almost every day while working with ChatGPT, Gemini, Claude, and other AI models. Every AI model needs some form of input to generate an output. Let's start with the basics.

What is a prompt?

It is an instruction given to the AI models to produce an output. It could be as simple as “Which is the best smartphone of 2026” or it could be as complex as “Act as frontend engineer and create a portfolio website with these specifications."

What is Prompt Engineering?

Prompt engineering is the process of crafting and refining prompts to get more accurate and useful outputs from generative AI models.

Why is Prompt Engineering important?

AI models respond based on how clearly the task is defined. Prompt engineering helps bridge the gap between vague, open-ended queries and precise, goal-oriented instructions.

For example, which one would give a better result?

“What are Samsung’s sales in 2026?”

“Act as a senior sales manager, analyze Samsung’s Q1 2026 performance, identify trends and shortcomings, and present the data in a table.”

The second prompt provides context, role, and expected output making it far more actionable.

Don't do this when your prompt doesn't bring you the desired output. Try and use one of the prompting techniques I shared below.

Good Prompting Techniques

Here are 8 prompting techniques that I liked and have used while working with AI models to get better results.

Zero-shot Prompting

In this prompting technique, examples aren’t provided. The model relies on its existing knowledge.

Prompt:
Translate this to French: “Hello”

One-shot Prompting

In this prompting technique, the model is provided with one example to understand the context and provide the result based on that context.

Prompt:
Translate English to French. Example: English: “Good morning” → French: “Bonjour” Now translate: English: “Hello”

Few-shot Prompting

In this prompting technique, the model is provided with multiple examples to get a more accurate answer with better context.

Prompt:
Translate English to French. English: “Good morning” → French: “Bonjour” English: “Thank you” → French: “Merci” English: “Good night” → French: “Bonne nuit” Now translate: English: “Hello”

I noticed this works especially well when the model’s first response feels slightly off.

Chain-of-Thought Prompting

This technique encourages the model to reason step by step before answering, which helps with more complex tasks.

Prompt:
Translate the following sentence to French. Think step by step before giving the final answer. Sentence: “Good morning”

I found this useful for logic heavy or multi-step problems.

Emotion Prompting

In this technique, the model is given emotional or situational context so it responds in a more thoughtful way rather than a direct or insensitive one.

Prompt:
Translate the following sentence to French. Imagine you are helping a beginner who is excited to learn a new language. This is important as I have a French exam tomorrow. Sentence: “Good morning”

This helped improve tone when the default response felt too robotic.

Role-based Prompting

This is one of the most common prompting techniques. It usually starts with phrases like “Act as __” or “You are a __”. It helps control tone, style, and depth.

Prompt:
Act as a professional French language teacher. Translate the following sentence to French. Sentence: “Good morning”

I used this often when I needed more structured or professional responses.

Rephrase and Respond (RaR) Prompting

Instead of writing the perfect prompt, we let the model rephrase the task and then answer it.

Prompt:
First, rephrase the task in your own words. Then, translate the sentence to French. Sentence: “Good morning”

This helped when I wasn’t sure how to phrase my request clearly.

Chain-of-Dictionary (CoD) Prompting

A less common technique where explicit word meanings are provided before forming the final translation. It’s useful in multilingual contexts.

Prompt:
Translate the sentence using a dictionary-style breakdown. Step 1: List key words and their French meanings. Step 2: Combine them into a natural French sentence. Sentence: “Good morning”

An AI is like a high performance engine. Prompt engineering is how you learn to drive it. All of these techniques work well individually, but combining one or two thoughtfully can significantly improve results.

Combining Prompting Techniques

Combining prompts means adding the best parts of multiple techniques into a single prompt to help the AI understand complex tasks better and generate more accurate outputs.

Example: Role-based + Instructions

Prompt:
Role: You are a professional French language teacher who specializes in clear, beginner-friendly translations. Instruction: Translate the following English sentence into French, keeping the tone simple and natural for beginners. Text: “Hello”

Example: Context + Instruction + Few-shot Prompting

Prompt:
Context: You are translating short English sentences into French for a travel phrasebook. The translations should be natural, conversational, and suitable for everyday use. Instruction: Translate the English sentence into French following the style of the examples below. English: “Good morning” → French: “Bonjour” English: “Thank you” → French: “Merci” English: “Good night” → French: “Bonne nuit” Now translate: English: “Hello”

I found this approach useful when tasks became more complex and needed consistency.

Bad Prompting Techniques (Things I Learned to Avoid)

Avoid these as much as possible to get better results.

Overly Vague Prompts

Too broad and usually leads to generic output.

Prompt:
Build me a website

Contradictory Instructions

Confuses the model.

Prompt:
Make it minimal but add a lot of animations and details.

Overloading a Single Prompt

Trying to solve design, logic, deployment, and testing in one prompt often leads to messy results.

Prompt:
Act as a senior full-stack developer. Design a portfolio website with animations, build the frontend in React, create the backend APIs, deploy it to the cloud, write tests, optimize performance, fix any errors, and make it SEO-friendly.

I realized smaller prompts worked better.

Blind Trust in Output

Assuming the model is always right without reviewing or validating the result.
Prompt:
Generate production-ready React code for authentication. Do not explain anything. Just give the final answer.

This usually required manual fixes later.

I learned that Prompt engineering isn’t about writing clever prompts it’s about clear thinking. I’m still learning, and I’m sure there are better ways to do this. For now, breaking problems down, giving context, and reviewing outputs has worked best for me.

Would love to know: What prompting techniques have worked best for you, and which ones completely failed?