A long technology list is the easiest part of a developer profile to write.

It is also one of the weakest hiring signals.

React, Node.js, Next.js, MongoDB, AWS, AI.

Fine.

Now ask what happens when the requirement is unclear, the data is sensitive, the deadline is fixed, and the existing code does not match the screenshot.

That is where the evaluation starts.

Begin with the problem, not the stack

A useful first brief explains:

• the user;
• the business outcome;
• the current system;
• the biggest risk;
• the required deadline;
• the evidence that will define success.

If the developer immediately prescribes a stack without asking about those points, the answer may be rehearsed.

Good technical decisions depend on constraints.

Ask boundary questions

I would ask a candidate:

1. Where should authentication be checked?
2. How will tenant or account ownership be enforced?
3. Which data can reach the browser?
4. What happens when a provider times out?
5. How will retries avoid duplicate work?
6. What must be backed up?
7. How will a release be rolled back?
8. What is deliberately excluded from the first version?

The exact technology matters less than whether the developer sees the failure path.

Request one comparable example

“Show me your best project” often produces the prettiest screenshot.

Ask for one comparable decision instead:

Show me a system where you handled a similar data boundary, workflow, integration, or deployment risk. What did you own, and what would you change now?

The answer can be anonymized when client confidentiality matters.

Look for:

• a clear problem;
• the developer’s actual ownership;
• a reasoned decision;
• a tradeoff;
• verification;
• an honest limitation.

Use a paid discovery task

For meaningful work, a small paid discovery phase is often safer than a large free “test.”

Possible outputs:

• current-system map;
• risk register;
• scoped first release;
• architecture decision;
• migration plan;
• representative prototype;
• estimate with assumptions.

This reveals how the developer reads, asks, documents, and decides.

It also produces value even if the build does not continue.

Evaluate communication as engineering

For international clients hiring in Bangladesh, time-zone communication deserves explicit review.

Ask:

• What is the update rhythm?
• Where do decisions live?
• How are blockers escalated?
• Which hours overlap?
• What does a demo include?
• How will scope changes be recorded?

A developer who writes clearly can move work while you sleep.

A developer who hides uncertainty can lose a week inside one sentence.

Clarify ownership before coding

The agreement should identify:

• source-code ownership;
• repository access;
• infrastructure ownership;
• account and domain ownership;
• licensing;
• third-party costs;
• data responsibility;
• handoff material;
• support window;
• confidentiality.

Do not let production depend on an account only the developer controls.

Do not ask the developer to share private credentials casually either.

Use least privilege and named ownership.

Price the risk, not the country

Bangladesh has developers at many experience and price levels.

So does every other country.

The lowest quote may be correct for a narrow task.

It may be dangerously low for a system involving payments, tenant data, migrations, or business-critical operations.

Compare:

• scope assumptions;
• risk coverage;
• exclusions;
• communication;
• maintainability;
• verification;
• post-launch ownership.

The number makes sense only beside those details.

Red flags I would not ignore

• Guaranteed ranking, revenue, or “bug-free” delivery.
• A precise estimate before reading the system.
• Production secrets requested through chat.
• No questions about authorization or data ownership.
• Every problem answered with a rewrite.
• No written exclusions.
• No plan for failure, recovery, or handoff.
• Client work shown without permission.

Confidence is useful.

Certainty about an uninspected system is not.

A practical shortlisting process

1. Send the same outcome-focused brief to each candidate.
2. Compare their questions before their proposal.
3. Run a paid discovery task with the strongest fit.
4. Review the artifact and communication.
5. Agree on scope, ownership, verification, and handoff.
6. Start with one bounded milestone.

This process costs more attention at the beginning.

It usually saves expensive confusion later.

For engagement structure, read fixed-price versus hourly development. For a view of how I operate, read my async client communication system.

If you are hiring for a Full-Stack, SaaS, or AI automation project, send the outcome—not a preselected stack.