We will definitely repeat history if we don’t learn from history. A big shout out to those applicants who post their rejections on this platform, because it takes humility and courage to make our shortcomings public.
These rejections are actually incredible resources. If new applicants study them, they can avoid the same potholes others have tripped over. I am opening this topic to analyse actual rejection feedback and provide suggestions on how to mitigate these risks. I will be updating this, hopefully, weekly and I welcome other experts to support.
Rejection Feedback Sample #1: The “Over-Experienced”
“The applicant is seeking endorsement through the Exceptional Promise route despite having more than five years of experience. They need to justify why they still fit the ‘early-career’ criteria required for the Exceptional Promise route.”
We know the Exceptional Talent pathway is for established leaders who can show significant impact over the last five years while the Exceptional Promise pathway is for those with the potential to become leaders.
Beyond the level of impacts, that differentiates these pathways, there is also the ILR factor Talent applicants can settle in 3 years, while Promise applicants takes 5 years. Even with these, many applicants with 5+ years of experience still choose “Promise” because they feel it’s an easier pathway, assuming the bar for “potential” is lower than “talent.” this can be strategic, however, this may be one of the reasons for your rejection.
How to Mitigate This
If you have more than five years of experience but are applying for Promise, you must be strategic about it. Don’t leave it to the assessor to guess why you aren’t applying as a Talent.
1. Address it in your Personal Statement : Explicitly state why you fit the “early-career” definition. Tech Nation usually views “early-career” as having a bit less than or 5 years of digital technology experience. but have more experience in related generalist role, with transferable skills. So, state it clearly on your statement.
2. Weave the justification into your Evidence Descriptions : When describing your evidence, don’t just talk about what you did; subtly reinforce your “Promise” narrative.
For instance:
“I was invited to speak as a subject matter expert at this conference because of my specialised technical insights. While I have a career spanning 8 years, I spent the first 4 years in Education as a lecturer in the computer science department before pivoting into the digital tech sector 4 years ago, as detailed in my personal statement. Therefore, I am demonstrating my rapid trajectory and potential as an emerging leader within the tech ecosystem.”
The “Pivot” Narrative
If you have 5+ years of experience, your application could focus on one of these “justifiers”:
- Career Pivot: How you recently switched from a non-tech field to a product-led tech role.
- Academic Transition: You were in deep research or PhD studies and have only recently entered the commercial tech industry.
- Recent Specialization: You moved from a generalist role (like IT support or services) into a high-growth field like AI or SaaS product development.
By providing a clear justification for your chosen pathway, you remove the “guessing game” for the assessor and significantly lower the chance of a rejection based on years of experience.
Rejection Feedback Sample #2: The “Self‑Authored”
“Additionally, all the evidence provided consists of unverified self‑authored text, screenshots that do not name nor connect to the applicant, and a letter which is not supported by sufficient third‑party evidence to verify the claims made. This is not sufficient evidence.”
This is one of the most common and most avoidable rejection reasons. Many applicants underestimate how strict Tech Nation is about verification. The assessor is not allowed to “trust your word,” even if everything you wrote is true. If the evidence cannot be independently validated, it is treated as self‑authored, and therefore weak.
And this doesn’t only apply to text you wrote yourself. It also includes:
- Screenshots of internal dashboards
- Screenshots of frameworks or tools that are not from a reputable, publicly accessible platform
- Metrics that cannot be traced back to a credible source
- Reference letters that make big claims but provide no supporting proof
If the assessor cannot verify it without relying on your personal explanation, it is considered self‑authored.
A Simple Illustration
Imagine you tell someone:
“I’m the top performer in my company. I increased revenue by 200%.”
Now imagine you show them a screenshot of a dashboard with numbers—but the dashboard has no logo, no URL, no timestamp, no name, and no external confirmation.
To the assessor, this is the equivalent of saying:
“Trust me.”
And Tech Nation does not operate on trust. They operate on evidence.
Now imagine instead you show:
- A public article from your company announcing the revenue milestone
- A LinkedIn post from your CEO celebrating your achievement (Not an evidence, but can help your narrative)
- A dashboard screenshot with your name, company branding, and a link
- A reference letter that includes a link to a press release or GitHub repo confirming the work
Suddenly, the assessor doesn’t need to “trust you.” They can verify you.
That is the difference between just an evidence and validated evidence
How to Mitigate This
Here are practical, simple ways to avoid the “self‑authored” trap:
1. Use Evidence That Exists Outside of You
Anything you claim should be backed by something that lives on a reputable platform:
- Company website
- GitHub
- App Store / Play Store
- Press articles
- LinkedIn posts from other people(Not an evidence)
- Conference websites
- Public repositories
- Award listings
If it’s only on your laptop, it’s not evidence.
2. Strengthen Your Reference Letters
A reference letter is not evidence by itself. It is only strong when:
- The referee provides links to verify what they are saying
- They reference public work, public achievements, or public impact
- They attach or point to third‑party proof
A referee saying “Raphael built X” is weak. A referee saying “Raphael built X, which you can see here: [link]” is strong.
3. Make Internal Work Verifiable
If your achievements are internal, you can still make them credible:
- Ask your company to publish a blog post about the project
- Request permission to share a redacted screenshot with branding
- Get a senior leader to post publicly about the milestone
- Use LinkedIn posts from colleagues acknowledging your contribution
- Provide a signed letter from your company confirming the metrics
The assessor needs something that shows your work exists beyond your own explanation.
4. Avoid Anonymous Screenshots
A screenshot with:
- No name
- No logo
- No URL
- No timestamp
- No external confirmation
…is almost guaranteed to be dismissed.
Add context. Add branding. Add traceability.
5. Pair Every Claim With a Third‑Party Anchor
A simple rule:
If you say it, someone else must say it too, or a credible platform must show it.
This is how you turn self‑authored content into verifiable evidence.
A Practical Example of “Fixing” Weak Evidence
Weak version: A screenshot of a dashboard showing “1M users” with no branding.
Strong version:
- A link to the product on the App Store showing 1M+ downloads
- A company blog post announcing the milestone
- A reference letter from the Head of Product confirming your role
- A dashboard screenshot with company branding and your name
Same achievement. Completely different credibility.
More reasons will be aded - Keep an eye
All the best.