Forem: Elmer Chacon

Technically Approved, Still Rejected: The Feedback Gap in Hiring

Elmer Chacon — Fri, 02 Jan 2026 20:42:20 +0000

Technically Approved… and Still a “No”

Recently I went through a full recruitment process for a .NET Developer role. I passed every stage. The final message sounded like a win:

“You have been technically approved… Nevertheless, the team decided to move forward with another candidate…”

That sentence is tricky.

It’s positioned as encouraging, and maybe it’s meant to soften the disappointment. But as a candidate, it leaves you in a weird place: If I’m approved, what exactly made me not the choice?

The part that bothered me wasn’t the “no”

Let me be clear: I can take a rejection.
Hiring is competitive. Sometimes another candidate is a better fit for the exact situation. That’s normal.

What’s not normal—at least not healthy—is how often candidates are left with ambiguity, especially after investing real time:

technical interviews
coding tasks
multiple calls
preparing, studying, reorganizing schedules
emotional energy and expectations

When I asked for feedback, I got the classic response:

“I will talk to the team and let you know.”

And then… nothing.

Why this matters (even if recruiters mean well)

A generic rejection isn’t just disappointing. It’s also a missed opportunity for growth.

If I don’t know what influenced the decision, I can’t improve intentionally. I’m left guessing:

Was it salary or budget constraints?
Was it seniority level, like they wanted someone more junior or more staff-level?
Was it communication style (English level, clarity, confidence, leadership)?
Was it specific technical gaps (system design, testing, cloud depth, performance)?
Was it a team fit factor (domain experience, timezone overlap, collaboration style)?
Did I lose to an internal candidate, referral, or someone with a niche stack match?

Any of these are valid reasons. But without clarity, the candidate is stuck.

“Technically approved” is not the same as “best match”

I’ve learned something important:
Passing the bar doesn’t mean you win the role. It may simply mean:

you met the minimum technical threshold
but someone else matched this specific team’s needs better

That’s fine—but the way we communicate it matters.

Because “approved” implies certainty. It implies readiness. It sounds like a yes. And then you get a no.

What candidates actually need (and it’s not a long report)

I’m not asking recruiters to write a novel, or expose internal discussions.

But even two honest sentences would be enough:

“We chose a candidate with deeper Azure + Kubernetes production experience.”
“The role required strong stakeholder communication; the other candidate showed more leadership in that area.”
“Budget was capped at X and we moved forward with someone within range.”
“We needed someone with direct marketplace/domain experience.”
“Your technical skills were strong, but we needed more depth in system design.”

That feedback doesn’t harm the company. It doesn’t create drama. It doesn’t require hours of work.

But it gives the candidate a direction.

The “we’ll be in touch” line

Stimulating hope is easy. Managing expectations is harder.

When a message says “we will be in touch 😉” but there’s no follow-up, it becomes noise. Candidates remember these things.

If the real meaning is: “We’ll keep your profile on file, but there’s no timeline,” that’s okay—just say that.

My message to recruiter teams

Recruiters have a hard job. I get it. Hiring managers are busy. Processes are messy.

But if you want better candidates in the future, better relationships, and a healthier hiring culture, this is a simple improvement:

Don’t leave strong candidates guessing.

We can take a “no.”
We can handle honesty.
What we can’t do is improve based on silence.

A practical ask

If you’re a recruiter reading this, here’s a tiny habit that would make a huge difference:

After rejection, send one of these:
Skill-based reason (one sentence)
Role-fit reason (one sentence)
Compensation range mismatch (one sentence)

That’s it.

And to candidates: here’s how I’ll handle this going forward

I’m also learning to protect my energy:

If feedback is vague, I’ll ask once, politely.
If it doesn’t come, I’ll assume it was a fit/budget/timing decision.
I’ll take notes on how I performed and keep improving anyway.

And I’ll continue applying where the process respects both sides.

Because professionalism isn’t only about passing interviews.
It’s also about how we treat people when the answer is “no.”

🧠 The Ultimate C# Cheat Sheet & Quick Reference

Elmer Chacon — Fri, 13 Jun 2025 19:50:23 +0000

Whether you're new to C# or a seasoned developer who needs a quick refresher, this cheat sheet is for you. It’s a compact but powerful reference filled with practical examples and syntax reminders that’ll keep you sharp and efficient as you code.

🧱 Basics

✅ Variables

int age = 30;
double pi = 3.14;
string name = "Elmer";
bool isActive = true;
char initial = 'E';

✅ Constants

const double Gravity = 9.81;

✅ Nullable types

int? score = null;

🔁 Conditionals & Loops

✅ If-Else

if (age > 18)
    Console.WriteLine("Adult");
else
    Console.WriteLine("Minor");

✅ Switch

switch (dayOfWeek)
{
    case "Monday":
        Console.WriteLine("Start of week");
        break;
    default:
        Console.WriteLine("Any day");
        break;
}

✅ For loop

for (int i = 0; i < 5; i++)
    Console.WriteLine(i);

✅ Foreach

string[] fruits = { "Apple", "Banana" };
foreach (string fruit in fruits)
    Console.WriteLine(fruit);

✅ While

int counter = 0;
while (counter < 3)
{
    Console.WriteLine(counter);
    counter++;
}

📦 Classes & Objects

✅ Defining a Class

public class Dog
{
    public string Name { get; set; }
    public void Bark() => Console.WriteLine("Woof!");
}

✅ Using a Class

var myDog = new Dog { Name = "Rex" };
myDog.Bark();

🎯 Methods

✅ Method with Parameters and Return

int Add(int a, int b) => a + b;

✅ Optional Parameters

void Print(string msg = "Hello") => Console.WriteLine(msg);

🧰 Collections

✅ Arrays

int[] nums = { 1, 2, 3 };

✅ List

List<string> names = new List<string> { "Alice", "Bob" };
names.Add("Charlie");

✅ Dictionary

var ages = new Dictionary<string, int> { { "Tom", 30 } };
Console.WriteLine(ages["Tom"]);

🚀 LINQ

var evens = numbers.Where(n => n % 2 == 0).ToList();
var names = users.Select(u => u.Name).ToList();

⚙️ Exception Handling

try
{
    int x = 10 / 0;
}
catch (DivideByZeroException ex)
{
    Console.WriteLine("Cannot divide by zero");
}
finally
{
    Console.WriteLine("Cleanup code");
}

🔄 Async / Await

async Task<string> GetDataAsync()
{
    await Task.Delay(1000);
    return "Data loaded";
}

🛠️ Useful Tips

Use var when the type is obvious
Use ?? for null-coalescing:

string name = input ?? "Default";

Use string interpolation:

Console.WriteLine($"Hello, {name}!");

📌 Bonus: Attributes & Enums

✅ Enum

enum Status { Pending, Approved, Rejected }

✅ Attribute

[Obsolete("Use NewMethod instead")]
void OldMethod() {}

🧠 Final Thoughts

This cheat sheet is just the tip of the iceberg when it comes to C#. Keep it handy as a quick reference, especially when you're juggling multiple projects or switching between languages. C# is expressive, powerful, and clean—and with a reference like this, you can focus more on building and less on remembering syntax.

🧱 Mastering CQRS with MediatR in C#

Elmer Chacon — Sun, 08 Jun 2025 03:29:06 +0000

CQRS (Command Query Responsibility Segregation) is a powerful architectural pattern that helps scale and organize modern applications, especially in the context of Domain-Driven Design (DDD). Combined with MediatR, a popular .NET library for implementing the Mediator pattern, CQRS becomes clean, maintainable, and testable.

In this blog, we'll explore:

What is CQRS?
Why use MediatR?
Implementing CQRS with MediatR in C#
Folder structure best practices
Examples: Create, Read, Update
Validation and error handling
Dependency injection and testing tips

🔍 What is CQRS?

CQRS stands for Command Query Responsibility Segregation. It separates:

Commands: write operations that change state (e.g., Create, Update, Delete)
Queries: read operations that fetch data

This separation allows each side to scale independently, apply different optimizations, and follow different architectural principles (e.g., write = strict validation, read = performance-focused).

🧭 Why MediatR?

MediatR allows decoupling request handling logic using the Mediator pattern:

Commands and Queries are simple C# objects (POCOs)
Handlers encapsulate the logic
No service locator, no static dependencies

dotnet add package MediatR dotnet add package MediatR.Extensions.Microsoft.DependencyInjection

🏗️ Recommended Folder Structure

✍️ Command Example: Create Product

Step 1 – Define the Command

public record CreateProductCommand(string Name, decimal Price) : IRequest<Guid>;

Step 2 – Create the Handler

public class CreateProductHandler : IRequestHandler<CreateProductCommand, Guid>
{
    private readonly IProductRepository _repository;

    public CreateProductHandler(IProductRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> Handle(CreateProductCommand request, CancellationToken cancellationToken)
    {
        var product = new Product
        {
            Id = Guid.NewGuid(),
            Name = request.Name,
            Price = request.Price,
            CreatedAt = DateTime.UtcNow
        };

        await _repository.AddAsync(product);
        return product.Id;
    }
}

Step 3 – Use It in a Controller

[HttpPost]
public async Task<IActionResult> Create(CreateProductCommand command)
{
    var id = await _mediator.Send(command);
    return CreatedAtAction(nameof(GetById), new { id }, id);
}

🔎 Query Example: Get Product By ID

Step 1 – Define the Query

public record GetProductByIdQuery(Guid Id) : IRequest<ProductDto>;

Step 2 – Create the Handler

public class GetProductByIdHandler : IRequestHandler<GetProductByIdQuery, ProductDto>
{
    private readonly IProductRepository _repository;

    public GetProductByIdHandler(IProductRepository repository)
    {
        _repository = repository;
    }

    public async Task<ProductDto> Handle(GetProductByIdQuery request, CancellationToken cancellationToken)
    {
        var product = await _repository.GetByIdAsync(request.Id);

        if (product == null)
            throw new NotFoundException(nameof(Product), request.Id);

        return new ProductDto(product.Id, product.Name, product.Price);
    }
}

✅ Best Practices

1. Separation of Concerns
Don't put domain logic in handlers.

Keep handlers thin—delegate to services or aggregates if needed.

2. Validation with FluentValidation

public class CreateProductValidator : AbstractValidator<CreateProductCommand>
{
    public CreateProductValidator()
    {
        RuleFor(x => x.Name).NotEmpty().MaximumLength(100);
        RuleFor(x => x.Price).GreaterThan(0);
    }
}

services.AddValidatorsFromAssemblyContaining<CreateProductValidator>();
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));

ValidationBehavior Example:

public class ValidationBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
     where TRequest : IRequest<TResponse>
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
    {
        _validators = validators;
    }

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        var context = new ValidationContext<TRequest>(request);

        var failures = _validators
            .Select(v => v.Validate(context))
            .SelectMany(result => result.Errors)
            .Where(f => f != null)
            .ToList();

        if (failures.Count != 0)
            throw new ValidationException(failures);

        return await next();
    }
}

3. Use DTOs – Don’t Expose Entities
Avoid returning domain models directly. Instead, return DTOs like:

public record ProductDto(Guid Id, string Name, decimal Price);

4. Keep Handlers Simple and Focused
Bad:

Does Validation
Mapping
Domain Logic
Logging

Good:

Validate (via pipeline)
Call service/repo
Return result

5. Unit Testing Handlers

[Fact]
public async Task CreateProduct_Should_Return_Id()
{
    // Arrange
    var mockRepo = new Mock<IProductRepository>();
    var handler = new CreateProductHandler(mockRepo.Object);

    var command = new CreateProductCommand("Test", 10);

    // Act
    var result = await handler.Handle(command, CancellationToken.None);

    // Assert
    Assert.IsType<Guid>(result);
    mockRepo.Verify(r => r.AddAsync(It.IsAny<Product>()), Times.Once);
}

🧠 Wrap-Up

CQRS + MediatR = Powerful, clean, and testable architecture.

It helps you:

Organize codebase by behavior
Reduce complexity and duplication
Facilitate testing and scaling
Introduce pipelines for validation, logging, and metrics

Start small. Even if your app doesn’t need full CQRS, using MediatR for commands and queries can enforce structure and testability from day one.

🚀 Ready to Try?
You can bootstrap this pattern in any clean architecture app using:

dotnet new webapi -n YourApp dotnet add package MediatR dotnet add package MediatR.Extensions.Microsoft.DependencyInjection dotnet add package FluentValidation

Then start building commands, queries, handlers, and enjoy a maintainable codebase!

Teammates: Enemies or Allies? When They Know More Than You

Elmer Chacon — Thu, 05 Jun 2025 04:28:18 +0000

We've all been there.

You join a new project, and one of your teammates just knows everything. The tools, the stack, the architecture—they speak fluently, they move fast, they shine. And you? You’re still finding the right repo, trying to guess which package controls what.

In that moment, a sneaky thought creeps in:

Is this person a threat? Are they competition?

The Real Question Isn’t About Them, It’s About Us

When we feel outpaced by someone on our team, it's easy to slip into defensiveness. We might fear being overshadowed, being irrelevant, or—let’s be honest—being exposed. But the question we should be asking isn’t, "Are they a danger to me?" but rather:
"How can I grow because of them?"

Knowledge Isn’t a Weapon—It’s a Bridge

A teammate who knows more isn't a threat—they’re a shortcut to your own growth. Their experience can save you weeks of trial and error. Their guidance can level you up faster than any tutorial. And their mistakes? They're lessons you didn’t have to pay for in time or stress.

But here's the catch:

That only happens if you drop the ego.

Ego Creates Enemies—Curiosity Creates Allies

If you see your teammate as competition, you'll close off. You’ll avoid asking questions. You’ll try to “prove” yourself instead of learning. And that builds walls.

But if you stay curious—if you ask, listen, and collaborate—they’ll become your biggest ally. Most people love sharing what they know, especially if they feel respected. You can transform that “intimidating expert” into a mentor, a partner, a champion.

Leadership Isn’t About Knowing Everything

The best leaders aren’t the smartest in the room—they’re the ones who create space for others to shine. If you're in a position where someone else on your team outshines you in knowledge, that’s not your failure.

That’s your advantage—if you know how to use it.

Let them lead where they're strong. Support them. Learn from them. And show your own strengths in return. Because here's the truth: no one knows everything. You bring something to the table too—maybe it's communication, big-picture thinking, empathy, or raw grit.

Final Thoughts

A teammate who knows more than you isn’t an enemy—they’re an asset. The danger isn’t their knowledge—it’s our fear of looking small next to it.

So next time you feel intimidated, flip the script.
You don’t need to compete.
You need to connect.
Because the best teams aren’t built on ego.
They're built on trust, humility, and the willingness to grow together.

Do you know about Jabit! ?

Elmer Chacon — Thu, 10 Oct 2019 17:25:04 +0000

Hi everyone!

This is my first post and I'm so exited about that! Well, I want to share with you this page that I found recently but was a very extremly good help for me and I know will be for you too. Its name is Jabit! http://jabit.org/ This is a code generator tool created by Dennis Madrid | Ronald Madrid.

You can choose differents templates (Backend and Frontend):

NetCore WebApi
NodeJs
Angular (Beta)
React (Beta)
Vue (Beta)

Next Releases: Net Core Blazor, Razor and Python

This tool already have a template to start to play with, but you can easily replace the Models with json structure (for reference: http://jabit.org/documentation) and create your own application!!

Go to the documentation and check it out how to create it (you just need to run a line command in CommandPront).

I hope this can be helpful for everyone!

Cheers! :)