DEV Community: Dishit Devasia

The Real Reason You’re Getting Rejected in Tech Interviews (It’s Not Your Skills)

Dishit Devasia — Fri, 16 May 2025 19:02:58 +0000

You’ve spent years building your skills.

You’ve put in the late nights, the weekends, the debugging marathons. You’ve solved real problems, learned new tech, and stayed ahead of the curve.

But when it comes to interviews?

You feel stuck.

You give answers you know are technically sound. You talk about the work you’ve done. You try to be clear and confident.

And yet, the rejections keep coming.

Sometimes you get ghosted.

Sometimes you get told someone else was a “better fit.”

But deep down, you know the truth:

It’s not because you’re not good enough.

It’s because your answers did not resonate with the answers interviewers were expecting.

And that’s the part no one teaches you.

How to explain your thinking?

How do you tell the story behind your code without missing technical details?

How do you show value without sounding like you’re bragging or reciting from a textbook?

The worst part?

If you don’t fix this, you could stay stuck here.

Interview after interview. Job after job.

Watching less experienced people land roles you deserve.

Not because they’re smarter. But because they know how to talk like someone who belongs.

In this post, you’ll discover the three silent mistakes most developers and QA engineers make in interviews and how to fix them fast. Before they quietly kill your next opportunity, too.

Mistake 1: Not doing the right type of preparation

Most people focus on learning the technical details they may not know or trying to brush up on some areas they might have forgotten.

However, very few people focus on what they have put in their resumes.

One key question is, "Give me a brief overview of yourself." This is one of the first questions and is almost always given in most interviews.

Many people do not prepare for it. Some give a summary that tells nothing more than a CV, while others, still focused on remembering things they might get asked, ramble on without a beginning or ending.

Other common questions are likely to be asked, and it is better to prepare for them so that you can make a powerful impression.

Some of them include:

What are your strengths and weaknesses?

How do you overcome challenges at work?
What problems have you encountered in your past/current organisation?
What is one thing you do not like about your past/current organisation that you would like to improve?
How do you stay updated with technology advances?

Mistake 2: Treating the interview as a quiz instead of a conversation

As an engineer, you will always want to showcase your technical knowledge. So it makes us answer the question as fast as possible. Sometimes, we don’t even wait for the interviewer to finish the question.

Now this has a few problems.

It comes across as if you have memorised the answers. Competent people do not need to memorise the answers. They can pull the answer out of experience rather than memory.
The interviewer will feel that you have not listened to their questions completely, making the interviewer feel not in sync with you. You might come across as a person not open to listening.
When you focus on answering quickly, you forget to provide any nuance that the answer might have.

The interviewer might assume that you are not aware of the nuance (which will kill your chances) or might ask follow-up questions, and you may or may not get the nuance that the interviewer was looking for.

Mistake 3: Not referencing your answers with experience

Interviewers want to know about you and your experience. So when you answer a technical question without referencing your experience, you are giving away the opportunity to talk about your deep technical knowledge.

The interviewer is not looking for the technical answer, whether you know it or not.

They are looking for your experience in solving the problem.

For example, consider the question: In SpringBoot, what is the difference between the @Controller and @RestController annotations? Now the answer is straightforward.

@Controller is used to define a web controller that returns views (like JSP or Thymeleaf), while @RestController is a convenience annotation that combines @Controller and @ResponseBody, making it return JSON or XML directly from all methods by default. Use @RestController for APIs, and @Controller for web pages.

But if you answer it with an example from your experience.

@Controller is used to return a view and is typically used with something like Thymeleaf. I’ve used @RestController when building REST APIs. The nice thing is, I don’t need to add @ResponseBody to each method. It automatically converts the return value into JSON. So whenever I’m building a REST API, I just use @RestController.

This gives your interviewer a perspective that you have worked on it and have not repeated some answers that you memorised.

How to avoid these mistakes?

To avoid these pitfalls, you need to understand the different buckets of questions.

3 Question Buckets

Most candidates focus heavily on technical questions when preparing for software engineering interviews.

However, interviewers evaluate you on more than just your coding ability.

Based on my 15+ years of experience and being on both sides of the table, I find it helpful to divide interview questions into three main buckets, each with its own subtypes and preparation strategies.

Common Interview Questions

These questions aren’t meant to test your technical depth. They’re designed to understand your motivation, personality, and communication skills.

Often asked at the beginning of an interview, these questions help set the tone and offer the interviewer a glimpse into how you see yourself.

Examples:

Tell me about yourself.
What are your strengths and weaknesses?
Why are you looking for a change?
Where do you see yourself in 5 years?

How to prepare?

Draft these answers and practice them before a camera. Tweak answers as you find the right words.

Once you have mastered it, the words will come naturally from you.

Your answer will become to the point, and you will deliver it with confidence that will make a good impression, especially with the first question: tell me about yourself.

Technical Interview Questions

This is the meat of most interviews, especially for engineering roles. But not all technical questions are created equal. You can further break them into three subtypes, each requiring a different mindset to effectively approach them.

Fact-Based Questions - (Assessing Knowledge)

These questions test your understanding of specific technologies, tools, or concepts. The answers are usually short and have a “correct” answer.

Examples:

What does @AutoConfiguration do in Spring Boot?
What is a RESTful API?
What’s the difference between HashMap and ConcurrentHashMap?

How to prepare?

The trick here is to answer the question by adding scenarios you used in your experience.

If you have used it before, highlight specific examples of how you have used it before and also talk about some of the challenges you have faced.

If you don’t have experience, answer the question and tell them you have never used it.

This prevents further questions about topics you might not know, and the interviewer will move towards a topic you are familiar with.

Opinion-Based Questions (Assessing Preferences and Thought Process)

Here, interviewers are interested in how you form opinions, make trade-offs, and justify your choices. There may be no single “correct” answer, but they want to see if your thinking is grounded and experience-driven.

Examples:

Do you prefer SQL or Nosql databases? Why?
Would you introduce a new language like Python in a Java-heavy codebase?
What’s your take on using microservices vs. monoliths?

How to prepare?

These are tricky, as you might not know if the interviewer dislikes one part of it. The idea is to provide your opinions and give examples if you have them.

You can also reference blogs if you don’t have enough proof of experience.

In either case, the critical piece is the ending. You finish it by saying your experience or learning limits your thoughts, and you are open to ideas that will help you learn better.

This helps you get pointers if the interviewers have strong opinions about it and also showcases that you are open to feedback and learning.

Scenario-Based Questions (Assessing Application and Design Skills)

These practical, open-ended questions test how you think through real-world problems, design systems, or debug tricky issues. They simulate the kind of challenges you’d face on the job.

Examples:

You’re asked to build a REST API—what are the key things you’d consider?
How would you debug a slow-performing endpoint?
How would you handle consistency if multiple microservices need to share the cache?

Behavioural Questions (The Culture Fit Test)

Behavioural questions assess how you work with others, deal with conflict, handle pressure, and grow from challenges. These are crucial for determining whether you’d fit the team and company culture well.

Examples:

How do you handle tight deadlines?
What would you do if you’re blocked and not getting the needed information?
Tell me about when you received difficult feedback and how you handled it.

How to prepare?

Similar to common interview questions, the questions are limited. So you can prepare well for these.

You need to use the STAR technique to answer these questions.

If you can master this technique, you can also answer your technical questions with this approach.

The benefit is that this approach makes you tell a story. Now, the story might not be the best story in the world, but it will be enough to hook the interviewer's attention.

It also gives the interviewer opportunities to ask questions, and since you are basing it on your experience, you will always be on firmer ground than with other questions.

The STAR framework provides structure:

Situation: What was the context?
Task: What needed to be done?
Action: What did you do?
Result: What was the outcome?

Final Thoughts: Turn Preparation into Confidence

If there’s one thing to take away from this, great interviews don’t begin in the interview room.

They start with how you prepare.

Prepare answers to common and behavioural questions ahead of time—not to memorise, but to internalise.
Anchor your responses in your past experience. That’s where your strengths live.
Use the STAR technique to draw out scenarios in advance. The more you practice these, the more naturally they’ll come to you when it matters.
Don’t just say your answers. Practice them on a video call. Record. Rewatch. Adjust. This one step alone can drastically improve how you come across.

When you combine clear structure with authentic storytelling and real-world examples, your interviews feel less like an interrogation and more like a conversation you’re ready for.

Want help putting this into action?

Join me for the upcoming free live workshop:

3 Interview Mistakes Devs and QA Engineers Make That Sabotage Interviews (And How to Fix Them Fast).

I’ll discuss real-world examples, live breakdowns, and simple techniques you can use immediately.

A look at the real problems software architecture tried to solve, and why microservices might not be your first answer

Dishit Devasia — Thu, 10 Apr 2025 20:05:40 +0000

Dishit Devasia

Apr 10 '25

The Ultimate Guide to the Evolution of Microservices

#microservices #softwareengineering #eventdriven #architecture

Comments 1

11 min read

The Ultimate Guide to the Evolution of Microservices

Dishit Devasia — Thu, 10 Apr 2025 19:56:41 +0000

When software engineers talk about microservices, most do not understand the context in which the architecture originated. This leads to “doing microservices” instead of solving business problems. The assumption is that microservices are the silver bullet for solving business problems.

Think you have a solid grasp of microservices? Before you scroll further, take this 90-second Microservices Interview Readine...

But there are no silver bullets, as Frederick P. Brooks Jr. discussed in his famous 1986 paper, “NO SILVER BULLET — ESSENCE AND ACCIDENTS OF SOFTWARE ENGINEERING.” When you move to doing microservices, you only increase the accidental complexity that Brooks mentions in his paper.

So, how can you know if you are not introducing accidental complexity when building a microservices architecture? To understand this, you need to go back to the evolution of software architecture.

The Beginning

In the beginning, there was the computer—a massive, room-filling machine with thousands of vacuum tubes and transistors requiring an entire team of engineers to keep it running. In the 1950s, these behemoths—like the UNIVAC I and IBM 701—were the pinnacle of computing, and businesses lined up to access their raw power.

If you needed to do some processing, you didn’t just log in — you walked into a computer room, handed your punch cards to an operator, and waited. Computing was centralized. Expensive. Slow.

As Moore’s law took effect, computers started getting smaller and faster, but remained expensive. Therefore, people needed to share their computing resources.

This led to the Client-Server architecture.

Client-Server Architecture

This shift led to the client-server architecture, in which a central server handled business logic, and users accessed it through individual client machines.

Companies like IBM, Sun Microsystems, and Microsoft built ecosystems around this model, creating the foundation for modern business applications.

Now, in software engineering, we solve problems, only to find that the problems get bigger.

The client-server model worked well in the early days but had limitations.

You had desktop applications that connected to a server. The tight coupling meant that any change in business logic meant a change on the server, and all the clients needed to be upgraded.

Then the internet arrived.

The Rise of 3-Tier Architecture (1990s–Early 2000s)

Now, you only need a browser that connects to a server. Users do not need to have clients to access the server. The HTML browser was enough to get the work done.

What that meant was that the processing complexity increased on the server.

To cater to increased complexity on the server side, engineers developed the 3-tier architecture.

The server side was decomposed into three tiers:

User interface — what users will be able to see
Business layer — where all the business logic resides, like how to calculate an employee’s salary based on leaves, designation, role
Database layer — where all the information was stored, such as name, designation, role

This design sowed the seeds of monolithic architecture, which many junior engineers now consider an anti-pattern.

Monolithic Architecture

A monolith is a system in which all components (UI, business logic, database) are tightly coupled and deployed as one unit.

Example: A flight booking website built as a monolith:

- A user interface to search for flights  
- A booking module to reserve seats  
- A payment module to process transactions  
- A notification system to send emails

All these components exist in one codebase, database, and deployment unit.

Benefits

Easy to start with for small teams
One unit of deployment
Simpler deployment process
Straightforward transaction management
Lower operational overhead

Challenges

As application size increases, the deployment time increases
To scale, you need to use vertical scaling even if only certain application parts might require more CPU/memory
A bug in any layer would need full deployment of the entire package
Things can get messy quickly, as each new business functionality means re-wiring the logic
Team coordination becomes more difficult as the organization grows

Modular Monolith

A modular monolith is a monolithic application structured into separate, well-defined modules with clear boundaries. However, it is still deployed as a single unit.

Example: Flight booking website modules:

- Flight Search Module  
- Booking Module  
- Payment Module  
- Notifications Module

Benefits

This architecture offsets some of the challenges of raw monolithic applications. Here we are moving towards creating modules based on business functions.

The code is better organized and easier to maintain
Setting up mocks, stubs, or running multiple services is not required as the entire application is one unit
When a series of operations need to be performed as a single unit (i.e., a transaction), monoliths are easier to manage
Since operational complexity is low, the cost of running a monolith is often lower than running multiple services (for lower volumes)
Teams can work more independently within their module boundaries

Challenges

The challenges of scaling and deployment remained. But enterprises found a different problem.

Enterprise organizations found that they have multiple modular monoliths, and the business requires them to talk to each other.

You had multiple monoliths trying to talk to each other. These applications could be on different technologies. Any change in one application meant all the interfaces with which it interacted needed to be tested for regression impacts.

When to Use a Modular Monolith

When you want a structured codebase without the complexity of microservices
When the team is small but growing
For startups that know their key features and can work their way up from there
When your domain boundaries are still evolving
When operational simplicity is more valuable than fine-grained scaling

Service Oriented Architecture (SOA)

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. Service orientation is a way of thinking regarding services and service-based development and the outcomes of services. A service:

Is a logical representation of a repeatable business activity that has a specified outcome (e.g. check customer credit; provide weather data, consolidate drilling reports)

Is self-contained

May be composed of other services

Is a “black box” to consumers of the service

The SOA architectural style has the following distinctive features:

It is based on the design of the services, which mirror real-world business activities, including the enterprise (or inter-enterprise) business processes.

Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration. It places unique requirements on the infrastructure. Implementations should use open standards to realize interoperability and location transparency.

Implementations are environment-specific — they are constrained or enabled by context and must be described within that context.

It requires strong governance of service representation and implementation. Definition from The Open Group

This was the first attempt to move towards business functionality as services.

The idea was to have coarse-grained services, such as an entire business process, handled by a service. Most SOA implementations deployed an Enterprise Service Bus (ESB), facilitating communication between services.

When SOA was introduced, most organizations followed the waterfall methodology of software development, and deploying all applications as a single deployment was still the norm.

The other aspect was that container technology was either non-existent or not mature enough for engineers to consider deploying smaller services.

Services are coarse-grained and share a standard communication protocol (e.g., SOAP).

Benefits

Standardization: ESB simplifies governance and message routing
Reusability: Services can be reused across multiple applications
Technology agnostic: Services can be implemented in different technologies
Business-IT alignment: Services map to business capabilities

Disadvantages:**

ESB can become a single point of failure
Although ESB was intended to simplify application interfaces, the challenge of deploying ESB with multiple interface changes remained
Heavy governance requirements
Often led to complex, heavyweight implementations

Microservices

Microservices architecture is an approach in which an application is broken down into small, independently deployable services that communicate via APIs.

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are specific common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. — Martin Fowler, 2014

As the name suggests, microservices are more finely-grained services than services defined as part of SOA architecture.

Example: Microservices-Based Flight Booking System

Each function runs as an independent microservice:

Search Service
Booking Service
Payment Service
Notification Service

Benefits

Independent Scaling: Each service can be independently scaled depending on the volume requirements. For example, you have high search volume but low payment volume. If you only want to handle volumes related to search functionality, you can increase the containers handling just the search functionality. Smaller Builds: Build times are faster as the services are smaller, leading to higher developer productivity.
Independent Deployment: Each service is independent of others so that services can be deployed separately. Feature toggles and different approaches ensure you can deploy without affecting existing functionality.
Technology Flexibility: Teams can choose the best technology stack for their specific service requirements.
Team Autonomy: Teams can own and operate their services independently.
Fault Isolation: A failure in one service doesn’t necessarily bring down the entire system.
Smart endpoint and dumb pipes: The challenge with ESB was that the business logic started residing within ESB, and the owners of ESB had to be across all the business, which makes it a tough proposition. Microservices require inter-service communication on a light-weight protocol such as HTTP without context. The services are smart enough to process the requests and business knowledge remains within the service, making it easier to maintain.

Challenges

Increased Operational Complexity: Deploying each microservice means having different deployment pipelines. Each service is an infrastructure component, which increases the accidental complexity of maintaining services in production. This includes alerting, security, monitoring, and logging.
Distributed System Challenges: Microservices introduce all the complexities of distributed systems, including network latency, message serialization, and unreliable networks.
Data Management: Maintaining data consistency across services is challenging.
Testing Complexity: Integration and end-to-end testing become more complex.
Service Discovery: Services need to find and communicate with each other.
Team Overhead: This can be overwhelming for smaller teams, as most time might be spent on engineering work rather than building features.

As mentioned, microservices can get complicated fast. It is essential to understand the principles that guide service boundaries. One of the most influential approaches is Domain-Driven Design(DDD)

Domain-Driven Design and Microservices

Domain-Driven Design (DDD) provides crucial concepts for effective microservice architecture:

Bounded Contexts

A bounded context is a specific responsibility with explicit boundaries that separate it from other system parts. In microservices, each service typically represents a bounded context.
Ubiquitous Language

Each bounded context has its ubiquitous language—terms and definitions specific to that context. This helps define clear service boundaries.
Aggregates

Aggregates are clusters of domain objects that should be treated as a single unit. In microservices, aggregates often help define data ownership boundaries.

Implementing microservices without understanding DDD principles often leads to poorly defined service boundaries, resulting in tight coupling and distributed monoliths.

Let's explore how some real-world companies have approached microservices — successes and the challenges.

Case Studies

Netflix: Successful Microservices Adoption

Netflix began its journey to microservices in 2008, moving from a monolithic DVD rental application to a cloud-based streaming service composed of hundreds of microservices.

Key Factors in Success:

Gradual migration
Strong DevOps culture
Investment in tooling and infrastructure
Building for failure with techniques like Chaos Monkey
Team autonomy with centralized governance

Results:

Ability to scale to millions of users globally
Faster feature development and deployment
Improved system resilience

Segment: The Move Back from Microservices

Segment initially embraced microservices enthusiastically but later consolidated back to a more monolithic approach for their data pipeline.

Challenges They Faced

Operational complexity exceeded team capacity
Development velocity decreased due to cross-service dependencies
Testing and debugging became increasingly difficult

Key Takeaway: Microservices are not always the right solution, even for companies with technical expertise. Business needs must justify the complexity trade-off.

Data Management in Microservices

Data ownership and consistency become critical concerns in a distributed architecture. Let’s look at common challenges and patterns in managing data across microservices.

Distributed Data Challenges

Data Ownership: Each service should ideally own its data
Consistency: Maintaining consistency across services requires careful design
Query Complexity: Joining data across services is challenging

Common Patterns

Database per Service: Each microservice has its own database
Event Sourcing: Using events as the source of truth
Saga Pattern: Managing distributed transactions across services
Event-Driven Architecture: Services rely on events to achieve eventual consistency

Infrastructure Requirements for Microservices

Successful microservices implementation requires significant infrastructure:

Container Orchestration: Kubernetes, Docker Swarm
Service Discovery: Consul, Eureka
API Gateway: Kong, AWS API Gateway
Monitoring & Observability: Prometheus, Grafana, Jaeger
CI/CD Pipelines: Jenkins, GitHub Actions, CircleCI
Configuration Management: Spring Cloud Config, Consul

Organizations must be prepared to invest in these technologies and the expertise to use them effectively.

Conway’s Law and Organizational Structure

Architecture isn’t just a technical decision — it mirrors the organization behind it. This is where Conway’s Law becomes especially relevant.

Conway’s Law states: “Organizations design systems that mirror their communication structure.”

For microservices to succeed:

Teams should be organized around business capabilities
Each team should own one or more services end-to-end
Teams should be cross-functional (developers, QA, operations)
Organizations must support autonomous teams with a DevOps culture

Migration Strategies: From Monolith to Microservices

For organizations considering a migration:

Strangler Pattern: Gradually replace specific functions with microservices
Domain-First Approach: Identify bounded contexts before technical implementation
Start with New Features: Implement new functionality as microservices while maintaining the monolith
Data Considerations First: Plan how to handle data before splitting services

Decision Framework: Choosing Your Architecture

Ask yourself these questions:

Scale Requirements: Do different parts of your application need independent scaling?
Team Size and Structure: How large is your engineering organization?
Deployment Frequency: How often do you need to deploy changes?
Domain Complexity: Is your business domain naturally divisible into bounded contexts?
Organizational Maturity: Do you have experience with automated testing, CI/CD, and observability?

Recommended Approach Based on Organization Size:

Startups/Small Teams (1–10 developers)

Start with a monolith or modular monolith
Focus on good separation of concerns
Consider microservices only for specific high-scale components

Medium Organizations (10–50 developers)

Consider a modular monolith with well-defined boundaries
Implement microservices for components with distinct scaling needs
Invest in automation and DevOps practices

Large Organizations (50+ developers)

Microservices can help manage team autonomy and scale
Ensure strong technical foundations first
Consider domain-driven design to identify service boundaries

Monitoring and Observability

Microservices require advanced monitoring approaches:

Distributed Tracing: Following requests across service boundaries
Centralized Logging: Aggregating logs from all services
Metrics and Dashboards: Tracking system and business metrics
Health Checks: Verifying service availability
Alerting: Notifying teams of issues

Without these capabilities, debugging issues in a microservices environment becomes extremely difficult.

Choosing the Right Architecture: Beyond the Hype

Microservices architecture didn’t emerge in a vacuum — it evolved as a response to specific business and technical challenges faced by organizations operating at scale. Before adopting microservices, organizations should honestly assess:

Team Size and Structure: Do you have the engineering capacity to manage multiple services and their infrastructure requirements?
Business Complexity: Is your domain complex enough to warrant separation into distinct bounded contexts?
Operational Maturity: Has your organization mastered automated testing, continuous deployment, and observability practices?
Scale Requirements: Do different components of your application genuinely need independent scaling?

Remember Frederick Brooks’ wisdom — software engineering has no silver bullets.

The best architecture solves your specific business problems with minimal accidental complexity.

Starting with a well-designed modular monolith provides an excellent foundation for many organisations.

This approach allows teams to discover natural service boundaries through experience rather than speculation, enabling a more organic evolution toward microservices only where necessary.

The goal isn’t to “do microservices” but to build maintainable software delivering business value.

Choose your architecture based on your constraints and objectives, not industry trends.

If you’ve made it this far, you’re serious about mastering microservices.

As a thank you, I’d love to offer you a free Microservices Interview Readiness Assessment — a quick yet deep-dive quiz that helps you discover how prepared you are, across 8 key areas.

The Github Shortcut: How to Get Hired Without a "Perfect" Project?

Dishit Devasia — Fri, 07 Mar 2025 22:06:15 +0000

Key Takeaways

1. Create a README Like a Solution Engineer (13:48)

Use your README to demonstrate your thought process by including solution diagrams, requirements, implemented features, and future enhancements. This showcases your problem-solving approach even before writing code.

2. Showcase Projects at Any Stage of Completion (18:22)

Even unfinished projects can demonstrate your skills - document implemented features separately from planned enhancements to show interviewers what you've accomplished and your forward-thinking approach.

3. Focus on the "Why" Behind Technical Decisions (22:47)

Clearly explain your design decisions and technology choices. Being able to articulate why you chose specific approaches demonstrates technical competence and helps differentiate your work from AI-generated code.

Here's the template link: https://gitlab.com/dd.omniview/github-readme

For your reference, you can find other aweseome README templates you can use in your projects if your goal is to have more open-source contributions

7 Things LeetCode Doesn’t Teach You About Software Development

Dishit Devasia — Fri, 07 Mar 2025 19:07:10 +0000

Everyone says the key to landing a software job is grinding LeetCode. Solve hundreds of problems, and the offers will roll in.

But here’s the harsh truth—LeetCode isn’t enough.

You can memorize algorithms, ace coding challenges, and yet struggle in real-world software development.

Because when you’re on the job, your biggest problems won’t be binary trees or dynamic programming.

They’ll be messy codebases, unpredictable users, and working with people who don’t think like you do.

Here's 7 reasons why solving Leetcode problems does not help you become a good software developer.

1. AI can solve LeetCode problems - where does that leave you?

All the LLMs can solve LeetCode problems in a matter of seconds. The accuracy will only improve as time goes on.

So what's the value that you can bring to an organization?

2. Users are unpredictable

This is an old joke.

A QA walks into a bar. Orders a beer. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a string of random characters. First real user walks in and asks where the bathroom is. And the whole bar catches fire.

Real-world users don’t follow predefined rules.

They input unexpected values, break your UI, and find edge cases you never considered.

In the video below, see what users are using the new Bounce Features for Mercedes.

// Detect dark theme var iframe = document.getElementById('tweet-1700606821914849469-14'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1700606821914849469&theme=dark" }

Writing production code means anticipating failures and designing for resilience—something LeetCode won’t teach you.

3. Your code is not an island

Most real-world applications interact with multiple external systems—APIs, databases, third-party services.

These systems change, fail, and return unexpected data.

Handling these changes with minimal disruption is a critical skill that LeetCode completely ignores.

I remember an issue where the labels on parcels got all mixed up.

How do you find what caused the issue?

You never learn to troubleshoot issues across many systems using LeetCode.

4. Your code is only the technical specification part of the software. The bigger part is people.

Software development is a team sport. You’ll collaborate with engineers, product managers, designers, and QA testers.

You’ll encounter tough personalities and conflicting priorities.

More importantly, you’ll get feedback.

QA engineers will break your code, senior engineers will challenge your designs, and business stakeholders will change requirements.

Learning to handle this with maturity and professionalism is essential—LeetCode doesn’t prepare you for that.

5. Seeing the Bigger Picture Matters More Than Fixing Bugs

Sometimes, a bug might look an easy fix. But if you do not take time to understand the consequences of the fix on the system, it might result in a host of new bugs that you never thought of.

Understanding the exact root cause of the bug and analyzing impact to the overall system is critical to doing good development work.

Key questions you can ask:

Are you 100% sure of the root cause? The best way to determine is if you can reproduce the bug.
When this fix gets deployed, is there any concurrent feature that this will affect?
Is this scenario one-off, or does it have the potential to repeat often?
Is there a requirement that will get affected in the near future?

6. There is a method to software development

Most often this method is Agile.

Understanding sprints, stand-ups, code reviews, and release cycles is crucial for working effectively in a team.

Without this, you’re just writing code in a vacuum. No company operates that way.

7. Writing Code Is Easy—Writing Simple Code Is Hard

"A code is written once but read a thousand times." - Robert C. Martin

Anyone can write code that works.

Great developers write code that is clean, understandable, and maintainable.

Future developers (including your future self) should be able to read and extend it without frustration.

Good coding practices include:

Writing clean, readable code
Following design patterns (be careful with this one)
Writing meaningful tests
Documenting edge cases and limitations

The Bottom Line

LeetCode is useful, but it’s not enough. Focusing solely on it creates massive blind spots.

The best developers go beyond algorithms. They learn:

How to write maintainable, well-structured code
How to debug and troubleshoot real-world systems
How software interacts with infrastructure and external services
How to work effectively in teams

Now you might be wondering, when you are just starting out or switching to software development, what is one practical step that you can take.

One key action is that you can build a real-world project. Now there are caveats to that.

I will add that in another post. But it helps with most of the problems discussed in the post.

Reader’s challenge:

Even if you skip LeetCode and work on a real-world project, which of these challenges do you think you’d still struggle to learn?

Hit reply to let me know. Looking forward to your reply.

End to End Testing No More

Dishit Devasia — Fri, 27 Dec 2024 02:39:34 +0000

It’s a typical Tuesday afternoon, and your team is gearing up for a routine release—a feature here, a bug fix there.

Nothing groundbreaking, but it’s part of the rhythm that keeps your product evolving.

Developers have wrapped up their work, testers have validated the changes, and the release is queued up for deployment.

E2E tests are triggered to check for impacts on the overall system.

Few test cases fail.

Developers are called in to look into the issues.

Delivery leads / engineering managers are notified of the issues and now everyone in the team is there.

The team investigates for a couple of days.

The result? 1 bug and 4 false positives.

Sometimes couple of days might turn into a week and what that mean more people in to understand the consequence of the issue.

Managers are left juggling timelines, explaining delays to stakeholders, and hoping the release goes out somehow.

Developers and testers context-switch from building things to fighting fire.

For teams operating in microservices architectures, this isn’t a one-off nightmare—it’s a recurring challenge.

Weekly or fortnightly releases get bogged down, and instead of delivering value to customers, you’re spending precious time firefighting.

Why Does This Happen?

The root of these challenges lies in the very thing that makes modern systems so powerful: microservices architecture.

In a microservices setup, your application is no longer a monolith; it’s a collection of smaller, independent services working together.

While this brings scalability and flexibility, it also introduces complexity—each service depends on others, and any mismatch or downtime can cause cascading failures, especially during E2E tests.

The main issues are:

Interdependencies - Microservices often rely on other services, databases, or external systems. If one of these isn’t available or has mismatched versions, tests fail.
Test Fragility - E2E tests need stable environments, but in dynamic systems, infrastructure, test data, or service availability can be inconsistent.
Troubleshooting Overhead - Pinpointing the root cause of a failure in a web of services takes time and coordination, delaying releases further.

So, how do you address this?

Fixing E2E tests is the easy solution. But you have to consider the tests also increase or modified as more features are built in. So fixing E2E tests becomes a moving target as there will bound to be some flakiness when you are testing the whole stack.

The idea here is to approach the problem from an extreme angle so that you reduce the dependency on E2E tests and thus reduce flakiness at the root.

Contract Testing

One way to reduce reliance on E2E tests is by adopting contract testing.

What is Contract Testing?

Contract testing focuses on verifying the interaction between two services. Instead of testing the entire system, it ensures that a service (the consumer) and its dependency (the provider) agree on how they will communicate.

Here’s how it works:

The consumer defines a contract specifying the API calls it will make and the responses it expects.

The provider validates this contract to ensure it meets the consumer’s expectations.

Benefits of Contract Testing

Faster Feedback - You can test interactions without spinning up the entire system.
Reduced Fragility - Tests don’t rely on all services being up and running.
Clear Ownership - Each team owns its contracts, making troubleshooting more focused.
Scalability - Contract tests scale better than E2E tests in large systems with many services.

By implementing contract testing, you can ensure your services work well together, even if they’re deployed independently.

But contract testing alone cannot solve logic changes in downstream systems.

For example, if a shared service like an authentication system updates its logic, it might still pass its contract tests but fail in actual integration scenarios.

Traceability Matrix

To address logic changes and ensure comprehensive testing, you need a traceability matrix.

What is a Traceability Matrix?

A traceability matrix maps requirements, features, or changes to the tests that validate them. In the context of microservices:

It links services and their dependencies to specific test cases.

It identifies which tests to run when a particular service or feature changes.

How It Works

When a shared service updates, the traceability matrix identifies all dependent services and relevant integration tests.

Instead of running the entire E2E suite, you execute only the impacted tests, saving time and effort.

Benefits of a Traceability Matrix

Targeted Testing - Run only the tests that matter, reducing execution time.
Simplified Debugging - Developers and testers focus on the exact areas impacted by changes.
Faster Releases - By avoiding full E2E runs, you streamline deployments.

As business logic grows and tests multiply, maintaining the traceability matrix becomes increasingly complex.

Over time, there’s a real danger of maintainers adding everything into the matrix to cover all possible scenarios.

This leads to the same problem you were trying to solve: running all E2E tests for every release, negating the benefits of targeted testing.

Leverage Domains

One way to keep the traceability matrix manageable is by organizing it around domains.

A domain represents a logical grouping of services and their associated tests within your organization.

For example, you might have domains like Payments, User Management, or Notifications, each with its own traceability matrix.

How Domains Help

Focused Ownership - Each domain has clear owners—teams responsible for maintaining its traceability matrix and ensuring its accuracy.
Simplified Maintenance - By limiting the scope of each matrix to a domain, you reduce its complexity, making it easier to manage and update.
Better Visibility - Domain-specific matrices provide a clear view of dependencies and test coverage within that domain, helping teams identify gaps or redundancies.

Challenges of Using Domains

Boundary Definition - Defining clear boundaries between domains can be tricky, especially in systems with overlapping responsibilities.
Cross-Domain Dependencies - Interactions between domains may require additional coordination, especially when logic spans multiple areas.
Initial Overhead - Setting up domains and assigning ownership requires time and effort, particularly in large organizations with legacy systems.

The Combined Power of Contract Testing, Traceability Matrix, and Domains

Each solution—contract testing, traceability matrix, and domains—addresses a specific aspect of the E2E testing problem. However, their true strength lies in using them together.

Contract Testing ensures service-to-service communication is reliable, reducing the need for full-system tests.
Traceability Matrix targets logic changes, ensuring only the necessary tests run, saving time and effort.
Domains keep the matrix manageable, preventing it from becoming a monolithic structure that’s hard to maintain.

By combining these approaches, you create a robust deployment strategy that balances speed and reliability.

Challenges and Open Questions

While these solutions address many pain points, they aren’t without challenges:

Tooling - What tools can help automate and maintain traceability matrices across domains?
Training - How do you ensure all teams understand and adopt these practices effectively?
Governance - Who oversees cross-domain dependencies and ensures alignment?
Scalability - How do these approaches scale as the organization and system grow further?

These open questions highlight the need for continuous refinement and adaptation of your deployment strategy.

Conclusion
End-to-end testing failures shouldn’t derail your releases.

By adopting contract testing, implementing a traceability matrix, and leveraging domains, you can address the root causes of these delays and deliver faster, more reliable releases.

These approaches empower your teams to focus on delivering value to customers rather than firefighting test failures.

While challenges remain, taking the first step towards modernizing your testing strategy is the key to staying agile in today’s fast-paced development environment.

With this combination, you’re not just fixing a process—you’re laying the foundation for smoother, faster, and more confident releases.

This was first published on my newsletter.
Subscribe like other software developers and testers to receive frequent updates

Weekend Developer | Dishit Devasia | Substack

A dose of motivation and resources to help you on your journey to becoming a professional software developer. Click to read Weekend Developer, by Dishit Devasia, a Substack publication. Launched 2 years ago.

weekendprogrammer.substack.com

Why Your Software Projects Aren’t Getting You Hired (And What to Do About It)

Dishit Devasia — Sun, 10 Nov 2024 19:50:22 +0000

Ever felt like the projects you’ve spent hours—maybe even months—working on just aren’t paying off?

Maybe you’ve been told to “build more projects” if you want to stand out to employers.

So you build and build, adding projects to your portfolio with the hope that quantity will somehow lead to quality.

Along the way you find, you had to abandon few projects because you got stuck. Or you find that other people have done some cooler projects.

You also feel that your project is what everyone else is doing.

Or you may feel that you are not confident about how you created the project.

You’re not alone.

Many developers and job seekers are facing the same issues—putting their time and energy into projects they think will make them job-ready, only to find they’ve missed the mark.

The Real Problem Behind "Just Build More Projects"

Building projects can be valuable, but only if you’re building the right projects for where you are in your career right now.

Without a clear method to choose, it’s easy to end up working on projects that either

don’t make a real impact,
become overwhelming, incomplete burdens that lead to burnout rather than career progress.

So how do you know if a project is right for you?

Well, I have been looking over all the mistakes that I made in my career when looking for a job and also some of the right things that I did.

I wanted to create something that would provide a step-by-step approach so that you do not make the same mistakes that I made and achieve the results faster than I did.

The result.

PACE Framework.

The PACE Framework: Plan, Analyze, Create, Execute

PACE is a simple, four-step framework I developed to help job seekers and developers select projects that lead to results. Here’s how it works:

1. Plan

Yeah, that doesn’t sound insightful. But doing the boring stuff works.

Before you begin your project there are 3 essential steps you need to do:

Market Research

Identify the available opportunities in the kind of role that you are looking for in the specific location you are looking for. Typically, you want it to be in the city you are living in unless you are looking for a remote job.

Learning Intention

Identify your learning goals based on your market research.

Project Selection

Use the outputs from your previous two steps to select a project that aligns with the available opportunities and your learning goals.

2. Analyze

Analyze requirements

Create a list of requirements that will help you achieve your goals.

Align architecture

This is where you will have the first brush with technology. Think about how the tech stack that you are looking to build in the project will fit with your requirements. You will draw boxes and think about how these boxes will interact with each other.

3. Create

Design Solution

It is time to go deeper with your diagram.

You will now develop on paper how these boxes interact with each other and in what sequence.

This is where you get the bigger picture of how everything will look once you have built it.

Breakdown into tasks/stories

This is when you break the gigantic piece of work into small bits of tasks that you can do and create goals around.

You created the map of what you have to do by designing the solution.

This step will help you create milestones within the map so that you know where you are and how far you need to go.

4. Execute

The final step is to start writing code. You take each story and start building.

Did you see how different it is compared to 90% of the people who begin writing code the first time they select the project?

These steps can help you take the guesswork out of selecting the right projects and build your portfolio with intention.

But there’s so much more that goes into this process.

That’s why I have created a free workshop where I will go deep with each of these steps so that you learn all the nuances and be ready to get the framework implemented in your current project.

You’ll learn more about what to look for in your own goals, how to tailor projects to your job search, and how to stand out in a competitive job market.

Register for the workshop - PACE Yourself to a Dream Dev Job: 4 Steps to Standout Software Projects

If you’re ready to stop wasting time on projects that don’t pay off, this workshop is for you.

Let’s make sure that every project you build is one that can help you move forward.

Hope to see you there!

The Top 5 Mistakes That Can Derail Your Development Projects

Dishit Devasia — Sun, 08 Sep 2024 00:00:00 +0000

Have you ever started a project, only to find yourself stuck midway and ultimately abandoning it?

You're not alone.

Many developers face feelings of overwhelm, frustration, and a lack of progress, leading to the abandonment of their projects.

But did you know that the root cause of these issues often lies in mistakes made even before you start?

Common Pitfalls to Avoid

Here are five common mistakes that can lead to feelings of being overwhelmed and stuck:

1. Lack of Learning Goals

One of the cardinal mistakes new developers make is not having clear learning goals. As Stephen Covey mentions in The 7 Habits of Highly Effective People, it’s crucial to "begin with the end in mind." Without defined learning objectives, you may lose sight of the purpose behind your project. Ask yourself:

What do I want to learn from this project?

What skills or knowledge will I gain?

2. Jumping In Without Preparation

Many developers skip essential background work and dive straight into coding after reading a blog or watching a video. Instead, break down your project into smaller, manageable chunks. This approach, often used in corporate environments, allows you to track progress and visualize your achievements, making it easier to identify when you're stuck.

3. Choosing a Complex Project

It's easy to underestimate the complexity of a project, especially if you’ve seen it executed by an expert. Remember, only an experienced developer can accurately assess a project's difficulty. If you take on something too complex, you may find yourself overwhelmed and unsure of how to proceed.

4. Using an Outdated or Cutting-Edge Technology Stack

Selecting the right technology stack is crucial. Using outdated technology may not be taken seriously by employers, while cutting-edge technologies can leave you feeling lost. If you're learning new technologies that few others have experience with, you might encounter unique challenges that are difficult to solve.

5. Lack of Mentorship

Working without a mentor can be detrimental. A mentor can provide guidance on whether your project is too complex, help you navigate challenges, and keep you on the right path. Without this support, you may struggle in isolation, missing out on valuable learning experiences.

The Consequences of Abandonment

Abandoning a project not only means losing the opportunity to learn but can also impact your resume and future job prospects. Some developers, feeling discouraged, default to easier problems that offer minimal growth, missing out on the significant achievements they could have gained from tackling more challenging projects.

Join Free Workshop!

I've seen these challenges affect many developers, which is why I'm hosting a free workshop to teach a specific framework that can help you overcome these obstacles.

And if you know someone else who might benefit from this workshop, feel free to share this post with them!

Thank you for your time, and I look forward to helping you achieve your project goals!

Why Following Traditional Advice Isn’t Enough to Switch from QA to Developer and What to Do Instead?

Dishit Devasia — Fri, 06 Sep 2024 19:50:55 +0000

You're a quality engineer.

You know your way around software, you’ve caught the bugs, optimized the processes, and saved your team from countless headaches.

But now, you’re eyeing that developer role—the one where you get to build, not just test.

The one where your ideas turn into code that shapes products. You want to move from a gatekeeper to a value creator.

Yet, every time you take a step forward, it feels like you’re lost in a maze of conflicting advice, never-ending roadmaps, and an overwhelming list of “must-know” technologies.

You’ve scoured the internet, read the blogs, watched the tutorials, and maybe even bookmarked roadmap.sh, only to be left feeling more confused than ever.

"Where do I even start? How long will this take? Am I learning the right things?"

It feels like you’re trying to drink from a firehose, with no clear direction, no real sense of progress, and no idea when you’ll be ready to make the leap.

It’s easy to get stuck in analysis paralysis, overwhelmed by the sheer volume of things to learn.

You might even think about throwing your hands up and diving straight into a project, hoping you’ll figure it out as you go—only to hit roadblocks that send you spiralling back to square one.

But what if I told you there’s a simpler path?

A path that starts with understanding exactly where you are, and maps out clear, actionable steps to get you to that full-time development role you’ve been dreaming about.

Not someday—sooner than you think.

This guide will help you doing just that.

It’s about cutting through the noise, focusing on what truly matters, and giving you the confidence to start building, learning, and applying for that dream job—all without getting lost in the endless sea of “shoulds” and “musts.”

Steps to Follow

Identify your starting point

Assess your skills.

Are you at the learning the loops stage? Or are you at a level where you can solve some problems in most of the key topics area of a language?

You know what to do if you are learning the loops or just getting started. You only need to focus on the fundamentals.

But what if you understand the language fairly well and only need to learn the skills that most mid-level engineers want to know?

This is where you face the conflicting information challenge.

What you can do here is build your programming muscle. You need to compete with other experienced developers who can write code without looking up the internet. So by solving simpler programming challenges, you can build the muscle to solve problems.

Try simple to medium complexity exercises on coding platforms such as Hackerrank, Codility, LeetCode.

Transitioning to Building Projects

After getting comfortable with solving coding problems, it’s time to start building real projects.

You’ll know you’re ready for this step when you can mentally map out solutions or feel a sense of boredom with repetitive coding exercises.

This indicates you’ve mastered the basics and are ready to apply your skills in a more meaningful way.

Start with Simple Projects

Begin with a small, manageable project that aligns with your goals, like a basic to-do app or a simple API service.

The key is to complete a project from start to finish rather than biting off more than you can chew with a complex, large-scale application.

Completing a project will build your confidence and give you a sense of accomplishment, which is crucial at this stage.

For common pitfalls to avoid when starting projects, you can check out my video where I cover the biggest mistakes new developers make.

youtube.com

Keep Practicing Problem-Solving

Even as you dive into projects, continue practising coding challenges at least once a week.

This habit will help you maintain your problem-solving skills.

It also keeps your coding speed sharp, which is vital for performing well in technical interviews.

Incorporate Libraries and Tools

One of the hallmarks of a seasoned developer is knowing when to leverage existing libraries instead of writing everything from scratch.

These libraries are used by thousands of developers and have been thoroughly tested in production environments, bringing robustness and efficiency to your projects.

Explore Useful Libraries

Identify commonly used libraries in your chosen tech stack that can make your code more concise and efficient.

For instance, in the Java ecosystem, Apache Commons offers a variety of utility functions that handle many of the repetitive tasks for you.

Integrating these libraries into your projects not only speeds up development but also teaches you how to rely on battle-tested code to solve common problems.

Identify and Address Skill Gaps

As you near the completion of your projects, take a step back and assess any gaps in your skill set. This might include missing technical skills, foundational concepts, or knowledge of software development processes.

The key here is to be honest with yourself about where you need improvement.

Create a Learning Plan

Address these gaps one at a time. You can extend your current project to practice these skills or start a new project specifically designed to target your weak areas.

For example, if you’re unfamiliar with certain libraries or need to brush up on data structures, make that a focus in your next project iteration.

Market Research and Applying for Jobs

Begin applying for entry-level developer positions, even if you feel you're not yet perfect.

The feedback you receive from job applications and interviews will provide invaluable insights into what employers are looking for and help you identify further gaps to address.

Conduct market research on job portals to keep up with the skills in demand for your desired tech stack.

Learn from Other Developer’s Code

Reading other developers' code is one of the fastest ways to learn.

It exposes you to different coding styles, best practices, and new tools.

Additionally, resources like roadmap.sh can offer more ideas and pathways to expand your skill set.

Leverage Your Experience

As you gain experience, it's time to capitalize on your hard work.

Update your resume with your new skills and completed projects.
Highlight the technologies you’ve used and the problems you’ve solved.
Start applying for more roles
Look to get interviewed to learn your skill-gaps.

Rinse and Repeat

This journey is iterative.

After completing a project and addressing your skill gaps, repeat the process to continuously build on the knowledge you’ve gained:

Identify New Skills

Regularly reassess and pinpoint the next set of skills you need to learn.

This process is continuous and should continue even after you get a job.

Expand or Start New Projects

Either enhance your existing projects to incorporate new skills or start a new project that challenges you in different ways.

You should look to continue even after getting a job. Side projects keep you on your toes and you can experiment as much as you want.

At the job, you may not be able to play with the latest technologies all the time.

Incorporate New Tools and Libraries

Continuously refine your code by incorporating libraries and tools you discover through research or by reading other developers’ work.

Refactor and Improve

Refactor your code to improve readability and performance, demonstrating your growth and commitment to quality software development.

By following these steps, you’ll create a solid foundation, gain practical experience, and confidently transition from quality assurance to full-time software development.

Conclusion

You’ve made it this far, but this is just the beginning.

The path from QA to full-time developer isn’t some distant dream—it’s within your reach.

You’ve already got the foundation, the drive, and the grit to make this transition. Now it’s about taking action, making strategic moves, and never letting the overwhelm keep you stuck.

But let’s be real: You can’t do it all alone.

Trying to piece together bits of advice from a hundred different sources will only slow you down.

You need a clear, focused plan that keeps you on track and shows you exactly what to do next.

That’s why I’ve put together a free mind map outlining the entire process—a proven guide to take you from where you are now to where you want to be.

And no, I’m not dumping it in this post because I want it in the hands of people who are committed to moving forward, people who are action-takers and who are serious about moving from QA to Developer.

If you’re ready to be one of those people, click the link below to get your free mind map.

Get Action Plan MindMap

And if you’re ready to supercharge your progress, don’t just stop at the mind map.

I’m hosting a FREE workshop that will walk you through building your projects—projects that employers can’t ignore.

It will provide you with a solid framework that you can use to build project after project.

Even after you get a job, you can use this framework to deliver projects on time without bugs.

Don’t wait—spaces are limited, and you don’t want to miss out.

This is your moment.

Your opportunity to stop dreaming and start doing.

Click the links, grab the resources, and let’s make your transition to software development a reality.

You’ve got this.

The Ultimate Guide to Create Custom Annotations in Spring Boot

Dishit Devasia — Sat, 24 Aug 2024 20:06:44 +0000

Such annotations fill the entire project in Spring Boot.

But do you know what problems these annotations solve?

Why were custom annotations introduced to begin with?

How to create custom annotations?

Today, I will cover:

Why create custom annotations?
What are the key benefits of using these annotations?
How to create custom annotations?
How does the annotated method get invoked?
When to use custom annotations?
When not to use custom annotations?
What are the disadvantages of using custom annotations?

🎯 Why Create Custom Annotations?

In Spring Boot, annotations are more than just a way to add metadata. They

Simplify complex tasks
Reduce boiler-plate code
Enhance code-readability

Before Spring introduced custom annotations, developers had to manage configurations like email validation using XML configuration files.

The XML configuration would define beans, validators, and other necessary components to perform tasks such as validating email addresses.

Here's an example of how email validation might have been configured using XML in a Spring application:

As you can see, this can easily become a nightmare where there are hundreds of classes with many of them relying on each other.

It also meant a developer had to go look up this XML every time they had to add a new dependency.

Key Benefits of Custom Annotations

Simplification of Configuration

Spring introduced custom annotations to simplify configuration by allowing developers to use annotations directly in their code.

This reduced the need for extensive XML configuration, making the codebase cleaner and easier to maintain.

Support for Declarative Programming

Custom annotations in Spring enable a declarative approach.

Developers can use annotations like @Transactional, @Cacheable, or @Scheduled to declare desired behaviors without writing the underlying logic.

This results in more readable and maintainable code.

Handling Cross-Cutting Concerns

Spring's custom annotations, often used with Aspect-Oriented Programming (AOP), allow developers to handle cross-cutting concerns in a centralized manner.

For example, the @Transactional annotation manages transactions across multiple methods or classes without scattering transaction management logic throughout the code.

Reducing Boilerplate Code

It reduces the need for boilerplate code by encapsulating common behaviours.

For instance, the @Autowired annotation simplifies dependency injection, allowing Spring to automatically inject dependencies, rather than requiring explicit constructor or setter methods

It is a different discussion whether you should be using @Autowired or not.

Improving Code Readability and Consistency

By abstracting configuration and cross-cutting concerns into annotations, Spring improves the readability of the code.

You and your peer developers can quickly understand the purpose of a method or class by looking at its annotations, and annotations help enforce consistency across the codebase.

Framework Flexibility and Extensibility

Custom annotations allow developers to create their annotations tailored to specific needs, thus extending the framework's functionality in a standardized way.

This flexibility has helped Spring remain relevant and powerful across multiple applications and architectures.

🚀 How to Create a Custom Annotation

Step 1: Define the Annotation

Create a new annotation by defining an interface.
Use @interface to declare it.
Add meta-annotations to specify how the annotation should behave.

package co.officegeek.tokenratelimiter;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)  // Annotation available at runtime
@Target(ElementType.METHOD)          // Can be applied to methods
public @interface LogExecutionTime {
}

@Target: Indicates where the annotation can be used (e.g., methods, classes).
@Retention: Indicates how long the annotation is retained (e.g., runtime, compile-time).

Step 2: Create an Aspect to Handle the Annotation

You can create a custom logic to process the annotation using Spring's BeanPostProcessor, Aspect, or custom annotation processing logic.

package co.officegeek.tokenratelimiter;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class LogExecutionTimeAspect {

    @Around("@annotation(LogExecutionTime)")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        Object proceed = joinPoint.proceed();
        long executionTime = System.currentTimeMillis() - start;

        System.out.println(joinPoint.getSignature() + " executed in " + executionTime + "ms");
        return proceed;
    }
}

Step 3: Apply the Annotation

Apply your custom annotation to methods, fields, or classes as defined.

package co.officegeek.tokenratelimiter;

import org.springframework.stereotype.Service;

@Service
public class TestService {

    @LogExecutionTime
    public void serve() throws InterruptedException {
        // Simulate some work
        Thread.sleep(2000);
    }
}

How It Works:

The @LogExecutionTime annotation doesn't cause any method to be called directly.
The Spring AOP framework detects that a method has the @LogExecutionTime annotation using reflection.
The LogExecutionTimeAspect aspect is configured to apply around advice when a method with the @LogExecutionTime annotation is called.
The logExecutionTime method in the aspect is executed before and after the annotated method (serve), logging the execution time.

How does the annotated method get invoked?

When you apply a custom annotation to a method, class, or field, the annotation itself doesn't directly cause any method to be called.

Instead, the logic associated with the annotation is typically implemented using reflection or aspect-oriented programming (AOP) in frameworks like Spring.

Here's a breakdown of how the compiler and runtime environment know what method to call when an annotation is applied:

1. Compile-Time Processing (Annotation Processors)

Some annotations are handled at compile time by annotation processors.

Java's javax.annotation.processing package allows developers to create custom annotation processors that generate code, validate annotations, or even modify the abstract syntax tree (AST) of the code being compiled.

The annotation processor reads the annotations during compilation and executes code based on those annotations.

This can include generating new classes or methods that the code will use later.

The @Override annotation is a compile-time annotation that doesn't invoke a method but instead tells the compiler to check if the method actually overrides a superclass method.

How It Works:

You define a custom annotation processor by extending AbstractProcessor and overriding the process method.
The processor will be invoked by the compiler when it encounters your annotation, allowing you to generate code or perform other tasks.

2. Runtime Processing (Reflection)

Custom annotations can be processed at runtime using reflection.

The runtime system (e.g., a framework like Spring) uses reflection to detect the presence of annotations on methods, classes, or fields, and then applies the corresponding behavior.

A custom annotation like @LogExecutionTime doesn't directly trigger any method call.

Instead, an aspect or some other reflective mechanism checks for the presence of the annotation at runtime and then wraps the method call with additional logic.

How It Works:

At runtime, you use Java's reflection API to check if a method or class has a specific annotation using methods like isAnnotationPresent.
Once detected, you can invoke methods or execute logic associated with that annotation. For example, if a method has a @LogExecutionTime annotation, you might measure the time before and after the method call.

3. Aspect-Oriented Programming (AOP)

In frameworks like Spring, AOP is commonly used to handle custom annotations.

AOP allows you to define "aspects" that can intercept method calls and perform additional processing before or after the method execution.

When the AOP framework (e.g. Spring AOP) detects an annotation, it triggers the execution of an advice method associated with the aspect.

This advice method contains the logic that the AOP framework executes when the annotated method is called.

A @Transactional annotation in Spring doesn't execute any logic by itself.

Instead, the Spring framework's AOP infrastructure intercepts calls to methods annotated with @Transactional and wraps them with transaction management logic.

How It Works:

You define an aspect class with advice methods that are associated with specific pointcuts (join points where you want to apply the advice).
The aspect uses annotations like @Around or @Before to specify when the advice should be executed.
The AOP framework ensures that when a method with a custom annotation is called, the corresponding advice is executed automatically.

Use Cases Where Custom Annotations Are a Good Approach

Cross-Cutting Concerns

Custom annotations are ideal for handling cross-cutting concerns like logging, security, transaction management, and caching.

These are concerns that affect multiple parts of an application but are not related to the core business logic.

The @LogExecutionTime annotation above is a good example as that can be used across all the methods and it does not have any business logic.

Declarative Programming

When you want to specify what should happen rather than how it should happen, custom annotations provide a clean and expressive way to do this.

Annotations like @Cacheable or @Retry allow developers to enable caching or retry logic declaratively, without writing the implementation code manually.

Framework or Library Integration

Custom annotations can simplify the integration of frameworks or libraries by hiding the complexity behind an easy-to-use annotation.

Annotations like @Autowired in Spring help in injecting dependencies without having to manually instantiate them.

Encapsulation of Complex Logic

When complex logic needs to be encapsulated in a reusable way, custom annotations can provide a clean API for applying this logic.

An annotation like @RateLimit could encapsulate logic to limit the number of times a method can be called, without cluttering the method's body with this logic.

Use Cases Where Custom Annotations Should Not Be Used

Simple or One-Off Logic

If the logic is simple or only needs to be applied in a single place, creating a custom annotation is overkill and can unnecessarily complicate the code.

Logic That Requires Dynamic Behavior

Annotations are statically defined at compile-time, making them unsuitable for scenarios where behaviour needs to be dynamically determined at runtime.

If a method's behaviour should change based on user input or external configuration, handling this with custom annotations can lead to complex solutions.

Business Logic

Core business logic should not be abstracted into custom annotations, as this can make the logic less transparent and harder to maintain.

Using an annotation to encapsulate a business process like @ProcessOrder might hide important business rules, making the code harder to understand and maintain.

Complex Interactions Between Annotations

If the behavior depends on complex interactions between multiple annotations, it can lead to unexpected results and make the code difficult to understand and debug.

Combining multiple custom annotations that affect the same method (e.g., @Retry, @Cacheable, @LogExecutionTime) can result in unpredictable behavior and is difficult to manage

Performance-Critical Code

Custom annotations often rely on reflection or proxy mechanisms, which can introduce performance overhead.

They should not be used in performance-critical sections of code.

Using a custom annotation to add logging to a method that is called millions of times in a tight loop could significantly degrade performance.

💡 Summary - When to Use Custom Annotations

Custom annotations are perfect for handling cross-cutting concerns like logging, security, and transaction management.

They're also great for scenarios where you need to apply the same behaviour across multiple parts of your application.

However, for simple, one-off logic, or where fine-grained control and flexibility are required, custom annotations might not be the best approach.

Consider the trade-offs before you decide to implement them.

🌟 Final Thoughts

Custom annotations are a powerful tool in your Spring Boot arsenal, but like any tool, they should be used judiciously.

They offer a clean, reusable way to handle repetitive tasks and enforce consistency across your codebase.

But be mindful of the potential downsides, especially for complexity and performance.

📣📣 Announcement

I am launching a 10-day cohort-based course for software developers and aspiring microservices architects on designing and implementing rate-limiting service using Spring Boot and Bucket4j.

You'll learn:

✅ How to design and build a production-ready microservice

✅ In-depth knowledge of rate-limiting algorithms and their implementation

✅ Best practices in Spring Boot development, testing, and containerisation

But it is also about

✅ breaking down the project into specific tasks

✅ Being accountable to yourself

✅ Designing and Building the project right

It is targeted at software developers who want to design and develop a microservice which is a use case relevant to most companies.

It's ESPECIALLY for those earlier in their software developer career who might not have "project experience" but tons of passion and ambition.

If this is something that you think will help you or even if you are just curious to know more:

This was first published on my Substack. Subscribe to my Substack - Weekend Developer to get updates first.

Are you a developer who needs feedback on the code you write?

Or do you want someone to review your code so that you are doing the right things?

I help people with free code review sessions so that they can get early feedback and write better code

DM me on Twitter (X) or on LinkedIn and I will help you with your code.

Are You Making This 1 Developer Mistake to Get a Job as a Software Developer?

Dishit Devasia — Sun, 04 Aug 2024 21:01:53 +0000

The Biggest Mistake

Do you know what one of the biggest mistakes that most developers make when starting out is?

It's focusing too much on solving LeetCode problems and understanding Data Structure and Algorithms (DSA).

While these are important, they shouldn't be the sole focus of your learning journey. Here's why:

Practical Experience

Spending all your time on LeetCode and DSA may cause you to miss out on practical experience, which is crucial for your career growth.

Job Requirements

On the job, you'll be working on problems that span multiple systems. This requires a different set of skills that solving LeetCode does not provide.

Reading and Research

In a professional setting, you'll spend a lot of time reading API specs, requirement documents, language documentation, and library documentation.

The Value of Projects

Instead of solely focusing on LeetCode problems, consider building projects with specific learning objectives. Here's why projects are valuable:

Real-life Experience

Projects provide practical experiences that are more relevant to real-world job requirements.

Integration and System Knowledge

Through projects, you'll learn to integrate systems, understand domains, and gain valuable domain-specific knowledge.

Interview Preparation

Many companies prioritise practical skills and domain knowledge over advanced algorithms, making project experience more valuable in interviews.

Workshop Announcement

Now, if you are looking to build project I am in the process of creating a workshop that will help you in your journey to create relevant project.

Let me know if you are interested.

Thank you for reading and stay tuned for more valuable insights for developers!

Before you go!

This was first published on my substack.

Join others in getting updates like this in your inbox directly by subscribing to it

I also run free code review sessions where I go through your code and provide feedback.

DM me on LinkedIn or Twitter

Case Study: Loosely Coupled Architecture

Dishit Devasia — Tue, 23 Jul 2024 21:35:27 +0000

If you've been in the world of software development, you've likely come across the concept of loosely coupled design.

You may have a basic understanding of what it is, but have you seen how it's actually implemented in practice?

In this post, I'm going to show you a real-world example of how loosely coupled architecture can make a significant impact in a production environment.

The Urgent Issue

The other day at work, I was tasked with fixing an urgent issue due to a change in a vendor system that we integrate with.

Typically, this kind of scenario would require running an entire suite of regression tests and involving quality engineers or software testers.

However, because of our loosely coupled architecture, the change was minimal and only required a small unit testing, avoiding the need for extensive regression testing.

The Architecture

Our architecture consists of a vendor application with an internal database exposed via a public API, which is accessed through an integration API by the front end.

When the vendor system made a change, we only needed to update the mapping in the integration API without altering the contract between the front end and the integration API.

This meant that the front end did not require extensive regression testing, showcasing the benefits of a loosely coupled architecture.

The Alternative

I also want to illustrate the alternative scenario where the front end directly accesses details from the public API.

In this tightly coupled system, any change in the public API would require the front end to change, leading to the need for extensive regression testing and the front end taking on additional responsibilities such as authentication, error handling, and retries.

Benefits of Loosely Coupled Architecture

The contrast between the two scenarios highlights the benefits of a loosely coupled architecture:

Isolation of changes

A change in one system does not affect the entire system

Reduced blast radius

Changes are contained within specific components, minimizing the impact on the overall system

Abstraction of complexities

Authentication, error handling, and retries are handled in the integration layer, abstracted away from the front end

In conclusion, a loosely coupled architecture provides numerous advantages in software development, ensuring that changes are isolated and do not disrupt the entire system.

Thank you for reading! If you found this information valuable, please like and share to help others benefit from it as well

Before you go!

This was first published on my substack.

Join others in getting updates like this in your inbox directly by subscribing to it

I also run free code review sessions where I go through your code and provide feedback.

You can DM me on LinkedIn or Twitter

DEV Community: Dishit Devasia

The Real Reason You’re Getting Rejected in Tech Interviews (It’s Not Your Skills)

Mistake 1: Not doing the right type of preparation

Mistake 2: Treating the interview as a quiz instead of a conversation

Mistake 3: Not referencing your answers with experience

How to avoid these mistakes?

3 Question Buckets

Common Interview Questions

Examples:

How to prepare?

Technical Interview Questions

Fact-Based Questions - (Assessing Knowledge)

Examples:

How to prepare?

Opinion-Based Questions (Assessing Preferences and Thought Process)

Examples:

How to prepare?

Scenario-Based Questions (Assessing Application and Design Skills)

Examples:

Behavioural Questions (The Culture Fit Test)

Examples:

How to prepare?

The STAR framework provides structure:

Final Thoughts: Turn Preparation into Confidence

Want help putting this into action?

A look at the real problems software architecture tried to solve, and why microservices might not be your first answer

The Ultimate Guide to the Evolution of Microservices

The Ultimate Guide to the Evolution of Microservices

The Beginning

Client-Server Architecture

The Rise of 3-Tier Architecture (1990s–Early 2000s)

Monolithic Architecture

Benefits

Challenges

Modular Monolith

Benefits

Challenges

When to Use a Modular Monolith

Service Oriented Architecture (SOA)

Benefits

Disadvantages:**

Microservices

Benefits

Challenges

Domain-Driven Design and Microservices

Case Studies

Netflix: Successful Microservices Adoption

Key Factors in Success:

Results:

Segment: The Move Back from Microservices

Challenges They Faced

Data Management in Microservices

Distributed Data Challenges

Common Patterns

Infrastructure Requirements for Microservices

Conway’s Law and Organizational Structure

Migration Strategies: From Monolith to Microservices

Decision Framework: Choosing Your Architecture

Recommended Approach Based on Organization Size:

Startups/Small Teams (1–10 developers)

Medium Organizations (10–50 developers)

Large Organizations (50+ developers)

Monitoring and Observability

Choosing the Right Architecture: Beyond the Hype

The Github Shortcut: How to Get Hired Without a "Perfect" Project?

Key Takeaways

1. Create a README Like a Solution Engineer (13:48)

2. Showcase Projects at Any Stage of Completion (18:22)

3. Focus on the "Why" Behind Technical Decisions (22:47)

7 Things LeetCode Doesn’t Teach You About Software Development

1. AI can solve LeetCode problems - where does that leave you?

﻿2. Users are unpredictable﻿

3. Your code is not an island

4. Your code is only the technical specification part of the software. The bigger part is people.

5. Seeing the Bigger Picture Matters More Than Fixing Bugs

6. There is a method to software development

7. Writing Code Is Easy—Writing Simple Code Is Hard

The Bottom Line

Reader’s challenge:

End to End Testing No More

2. Users are unpredictable