Red Flag #1: Portfolio with No Live Products or Real Users

Every developer has a portfolio. The important question is: do those projects have real users? A GitHub repository with a travel app demo and 3 stars tells you the developer can build from a tutorial. It tells you nothing about what happens when the database has 100,000 rows, the API has 50 concurrent users, or a customer reports a bug at 2am.

How to check: Ask for a link to any live product they built that real people use. Then ask: “How many users does it have? What was the hardest production problem you solved on it?” Developers with genuine production experience have specific answers.

Red Flag #2: Multiple Interview Reschedules or No Camera

One reschedule happens. Two in a row, or a refusal to use video for the interview, signals something. Either the person is interviewing for multiple roles simultaneously and hasn’t prioritised yours, or they’re misrepresenting who will actually be doing the work (a surprisingly common issue with unvetted freelancers).

How to check: State in your initial message that the interview will require video. If they push back, treat it as a hard no.

Red Flag #3: Claims Expertise in 15+ Technologies

A five-year senior developer who is expert in React, Vue, Angular, Node, Django, Rails, Go, Java, Kubernetes, AWS, GCP, Azure, React Native, Flutter, and blockchain is not real. Expertise requires depth, and depth requires time. A developer who claims everything is expert in nothing.

How to check: Pick two of their “expert” skills that are adjacent but require genuine depth (e.g., TypeScript generics and React performance), and ask specific technical questions about each. Surface claims collapse quickly under specific questions.

Red Flag #4: No Questions for You

Strong developers ask questions. They want to understand the architecture before they commit to approaches. They want to know what “success” means. They want to understand the technical debt situation. A developer who goes through an entire interview without asking a single substantive question about your product or technical environment is not engaged — or not experienced enough to know what questions to ask.

Red Flag #5: Rate Significantly Below Market

A developer quoting 40–50% below the market rate for their claimed level of experience is a red flag — not a deal. The reasons a developer accepts below-market rates are limited: they’re desperate because clients keep leaving them, they’re misrepresenting their experience level, or they intend to leave quickly when something better appears. None of these are outcomes you want.

Reference: a mid-senior React developer in India working with international clients should be in the 8–5/hr range. A quote of /hr for “5 years React experience” warrants skepticism.

Red Flag #6: Slow or Vague Responses to Simple Questions

Before you hire someone, notice their communication quality. If it takes 36 hours to get a response to “what’s your availability?”, or if their answers to specific questions are vague and general, this is your preview of what working together will look like. Communication quality in the hiring process is highly predictive of communication quality during the engagement.

Red Flag #7: No Verifiable Code or GitHub History

Every developer working in 2026 has a GitHub account. If a developer has no public GitHub activity and won’t share even a private repo for a specific past project (under NDA if needed), they are either hiding low-quality work or don’t have the body of work they’re claiming.

Red Flag #8: “I’ll Add Tests Later”

Testing discipline is a professional habit, not a task that gets added at the end. Developers who routinely skip tests believe that shipping fast is the priority and testing is overhead — and in practice, codebases without test coverage accumulate technical debt exponentially. When you hear “I’ll add tests later,” the tests never get added.

Better signal: Ask to see a PR or a code sample from a real project. Check for test coverage. Ask: “Walk me through your testing approach for this feature.” The answer tells you everything.

Red Flag #9: Blames Every Previous Client

When you ask about a difficult past experience or a project that didn’t go well, how a developer responds reveals a great deal. A developer who consistently frames failures as entirely the client’s fault, with no self-reflection on what they could have done differently, will repeat those patterns with you.

Strong developers have clear-eyed post-mortems: “We underestimated the API integration complexity, and I should have flagged the risk earlier.” Developers who blame exclusively externally are difficult to work with and learn slowly.

Red Flag #10: Resistance to a Paid Trial Task

A developer who refuses to do a short paid trial task (2–10 hours of real work, compensated at the agreed rate) should be treated with significant caution. Strong developers welcome trials because they know they’ll do well. The most common reason for resistance is the awareness that their actual work quality won’t match their claims.

Note: the trial should always be paid. Asking for free work is exploitative and will attract resentment rather than best effort.