Stage 1: Application Review (Exceptional Talent)

Hi Committee,
Looking for some feedback regarding application for TN comprised of below documents. In my understanding, the new format does not explicitly require uploads for MCs/OCs but i have categorized the docs based of my own understanding>
Area - Software Engineering

MC1 - Comprised of evidence showing me as the top 1% performer in one of the FANG companies back to back years.

MC2 - High enumeration with evidence independent benchmarking from platforms like LevelsFYI

OC1 - Explaining how i independently researched, prototyped and acquired investment to a build a new service which is now being worked by an entire team which has already made millions in revenue. Including architecture diagrams, benchmarks and evidence. This is also corroborated with one of my LORs.

OC2 - Developed an infrastructure that leveraged LLMs to significantly reduce engineering (>3000 hours) of engineering effort, including architecture explanation. Backed up with metrics.

OC3 - Independently developed a open source SDK deployed in nuget that provides developers a cheap way to perform AI related tasks. It has over 1000 downloads in less than a month.

OC4- Independently developed a open source AI development framework proven to reduce hallucinations in AI systems. Backed up with evaluations against common benchmarks.

OC5 - I have two research papers published in open domain related to AI with over 6500 access along with performing 4 peer reviews from a prestigious conference.

OC6 - A letter from a principal engineer further corroborating all the data and metrics mentioned in OC 1 & OC 2.

I would really appreciated guidance on following:
1 - Review of above documents
2 - Can someone share how technical should a document be? Trying my best to calibrate between explaining the tech innovation vs too much detail.

The mandatory criteria is the weakest part of this pack and where I would spend the most time. A top-performer rating is an internal company signal, and the Guide is explicit that internal awards and certificates do not meet this criterion. Salary falls in the same trap: the Guide says remuneration alone is insufficient and you must show impact beyond your day-to-day role. Both mandatory pieces sit inside the job, when the assessor wants national or international recognition. That is the gap to close first.

Your optional criteria also work differently from how they are laid out here. There are four optional criteria and you pick two, with at least two pieces of evidence for each. The innovation work and the significant-contribution work look like the same project, and the Guide draws a line between them. Optional Criteria 1 asks for novelty, Optional Criteria 3 asks for measurable impact, and one piece for both often clears neither.

A reference letter alone satisfies no criterion, so the principal engineer letter needs to sit beside the evidence it corroborates rather than count on its own. An SDK with a month of downloads also risks reading as timed to the application, so lead with open source history that predates this submission.

The technical depth question comes down to the reader. The assessor moves quickly but can follow detail. Architecture diagrams and benchmarks work well when each document makes clear the work is yours, not the team’s. Lead with the impact, then keep the detail that proves you did it.

Thanks Akash for the review.

My plan was to include OC1 and OC2 to fall under the evidence of innovation. While OC3, OC4 and OC5 falls under significant contribution to the field.
Yes, the letter from principal is just to corroborate not add any specific evidence.

As far ask MC is concerned, I am thinking of adding invitation as a reviewer of a prestigious AI research conference. Would that be valuable?

@AJJ

Trust you’re doing well. Yes, applicants no longer upload evidence through Tech Nation’s platform, but the actual evidence requirements haven’t changed. You still need your CV, personal statement, a visible LinkedIn profile, three recommendation letters from established experts in the sector, and between six and ten unique evidence sets. At least 2 for the three criteria and at most ten overall.

There are three criteria - MC, OC, OC - and you must choose one MC and two OCs from OC1, OC2, OC3 or OC4. Based on your discipline, you’re a technical applicant (Software Engineering). The type of company you work for doesn’t affect your eligibility. The only place company type matters is OC3, where your contribution must be within a product‑led company.

For your evidence:

MC1:
Working at a FAANG, that’s major U.S. tech company can strengthen your narrative because Tech Nation does consider who hires you. But the job alone won’t meet MC. You still need to clearly show how you led the growth, direction, team, or development of a product and that the product has real value in the sector. External recognition like awards, news mentions, interviews, or strong reference letters can help validate this.

MC2:
Salary, no matter how high, is not enough on its own. Your application still needs to show how you’ve advanced the sector.

OC1:
Simply explaining innovation won’t prove what you actually innovated. An architecture diagram is just a visual map, it doesn’t show the innovation itself. Sales or adoption are strong validators because they show the market accepts what you innovated. So, clearly show the innovation, before showing the sales that came from it

OC2:
This is strictly about contributions outside your paid job. What you wrote feels more like OC1. You need to clearly show the innovation, the new concept, and the problem it solves to fit.

OC3:
Your evidence here looks more like OC2. Since you’re the developer, it could support MC if you can show recognition or adoption from other experts. Downloads can also demonstrate impact for OC2.

OC4:
If your innovation is clearly established, your listed OC4 can support OC1. OC4 is about how you’ve advanced the sector through research.

OC5:
This can work for OC4, but the topics must be relevant, the papers must be published in top tier peer‑reviewed journals, and you must show impact like reach, downloads, citations.

OC6:
Letters can support your case, but they are not evidence on their own and never sufficient.

On your question

Can someone share how technical should a document be? Trying my best to calibrate between explaining the tech innovation vs too much detail.

Tech Nation doesn’t rely on explanations, they rely on the evidence you can show. If you say you built something, show the code, repos, version control from reputable platforms, collaboration with other developers, or engagement with third party companies (APIs, payment gateways, etc.). You can blur sensitive information, but make sure ownership is clear. These are some of the ways technical contributions can be demonstrated.

All the best.

A reviewer invitation is a peer-regard signal, but on its own it sits below the bar the mandatory criterion sets. Reviewing for a conference shows the programme committee trusts your judgement, and plenty of active researchers review, so it reads as taking part in the sector more than being recognised as a leader within it.

Where it starts to count is the level of the role. An invitation as an area chair or senior programme committee member carries more weight than a place in the general reviewer pool, because it shows the field putting you above your peers. If the invitation spells out why you specifically were chosen, that context is what lifts it towards recognition.

I would keep it in the pack as support for your research contribution, but I would not lean on it to carry the mandatory criterion. That criterion still needs a piece showing the wider field rating you as a leader, and a reviewer role seldom does that by itself.

Continuing the discussion from Stage 1: Application Review (Exceptional Talent):

Your profile has several potentially strong elements, particularly the top-performer recognition, high remuneration,
measurable engineering impact, open-source work and research. The main thing I would change is the presentation:
don’t treat MC1, MC2 and OC1–OC6 as separate criteria. The application is
assessed against the mandatory recognition requirement and the four optional
criteria, with evidence allocated to the relevant criteria rather than treated
as six separate requirements. Instead, make sure each evidence document clearly
supports the relevant requirement and avoid duplicating the same achievement
across multiple documents.

For the
technical documents, aim for “technical enough to establish significance, but
not a technical design document.”
Explain the problem, what you personally designed/built, why your approach was
technically significant or innovative, and the measurable outcome. Architecture
diagrams, benchmarks and selected code/technical artefacts can be useful, but
avoid pages of implementation detail that don’t help the assessor understand
your personal contribution.

Your OC3/OC4
open-source projects would be
stronger if you can demonstrate adoption beyond download counts—for example,
external users/contributors, GitHub activity, integrations or independent
recognition. Similarly, for the research evidence, access numbers and
peer-review activity are useful, but explain the significance of the research
and your personal contribution.

The strongest
overall narrative appears to be: recognised engineer → significant technical
ownership → measurable real-world impact → contribution beyond employment
through open source/research.
Keep that narrative consistent throughout rather than trying to maximise the number
of achievements.

Thank you so much for your detailed review.
The evidence OC3 which is an open source SDK- I can show some quotes from community who have appreciated the use of the SDK to reduce their ingestion costs. Along with trends showing broader adoption with downloads. Do you think this would qualify as a MC?

@AJJ You are welcome. If you built the Software Development Kit yourself and can clearly show compilation of code commit summaries, repo, stars and recognition from industry peers, mentions, endorsements, expert references, along with broader adoption such as downloads and usage, then it can align well with MC for

Outside of your normal day-to-day job role, you led or were a significant contributor to a substantial open source project, as evidenced from compilation of code commit summaries, repo stars or similar metrics such as download statistics, where possible.

Community quotes and download trends strengthen the SDK, but they answer a different question from the one the mandatory criterion asks. Adoption and cost-saving testimonials show the tool works and that people use it, which is impact evidence. The mandatory criterion asks whether the sector recognises you personally as a leading talent, and happy users do not establish that on their own.

For the SDK to reach the mandatory bar, the recognition has to attach to you by name and come from voices the field already rates. A quote from a well-known engineer or an established company naming your work carries far more weight than a volume of users reporting savings, because it shows the field itself putting you above your peers. Maintainers of a recognised project adopting your SDK would do the same. Absent that, this reads as strong optional-criteria evidence for adoption and impact.

I would keep the community feedback and download trends under the optional criterion for contribution, where they land hardest, and build the mandatory case from evidence that shows external recognition of you as an individual.

@Akash_Joshi For the benefit of the platform and anyone who may read this later, I want to make a few clarifications on how downloads and adoption can demonstrate recognition. First, the statement below comes directly from Tech Nation’s own guidance for MC:

Outside of your normal day‑to‑day job role, you led or were a significant contributor to a substantial open‑source project, as evidenced by a compilation of code commit summaries, repo stars, or similar metrics such as download statistics, where possible.

While I’m not suggesting that an applicant should rely on evidence simply because the guidance lists them as examples, I want to explain how this aligns with this applicant’s case. MC is about what you did that was recognised, or what you were recognised for, in a way that has impacted or can impact the sector.

He is a software engineer who built a Software Development Kit that other experts like him are using, adopting, and downloading. These are his peers, just like peer reviewing, assessing other experts. He has done something that other experts recognised and choose to use and the usage can be measured through downloads. So, if you have any knowledge or domain advantage over your peers. It’s recognition that you are a leader(expert of experts).

That is a different level of recognition compared to downloads from a GitHub project where he is just one of many contributors that is required in OC2.

Thanks for the clarification.
Can you explain to me if the evidences need to be documented as Mandatory Criterion? I want to understand reviewers perspective, would they review all the evidences and validate if they full fill one MC and two OCs each with two evidences or do the applicant need to explicitly state it in the evidence.