What we look for in cohort applications

We get the question often enough that it is worth putting in writing. What does Solutech actually look for in an application?

The honest answer is shorter than people expect, and it has very little to do with seniority. Our flagship cohorts — AI-201, AI-401, RAG-301, INF-401, LDR-401 — are capped tightly on purpose. We screen the applications by hand. Roughly forty percent of applicants make it in.

The thing we read first

The first thing we read is the “what are you trying to learn?” paragraph. Two-thirds of applicants write something like, I want to learn AI engineering to grow my career. That is a reasonable thing to want, but it is not a thing we can teach against. If you write something specific — I own a RAG system at work that is somehow worse than it should be, and I do not know whether the problem is ingestion or retrieval or generation, and I would like to find out — you will move to the second pile.

A specific question signals something we cannot test for any other way: that you have been doing the work, and you have run into the part of it that is not obvious. We can teach that engineer something. We can almost never teach the engineer who is hoping the cohort will tell them what they should want.

Senior vs. junior

We do not weigh seniority heavily. Some of the best students in any given cohort are five years out of school and have done the work. Some of the weakest are fifteen-year veterans who arrive looking to be told that the field has not changed as much as it has.

What we weigh is one variable that correlates poorly with title: the willingness to be wrong in front of forty other engineers. The format does not work if you cannot stand to post an unfinished idea and have someone else point out the problem. We have seen director-level applicants flinch from this and Series-A founders thrive in it.

When we say no

We say no when applications signal three things, individually or in combination.

The first is a hope that the cohort will substitute for work. Cohorts amplify work; they do not replace it. If you write that you cannot allocate any project time during the six weeks, we will say no, kindly, and suggest you wait until you can.

The second is a tone of mastery. The applicants who write as though they already know what we are going to teach — of course evals matter, of course tracing matters — usually find the course frustrating, because the value is downstream of treating the material with curiosity rather than agreement. We try to spare them and us the experience.

The third is a fit problem with the cohort. Our seats are limited, and a cohort with twelve product managers and four engineers does not work the same as a cohort with two product managers and fourteen engineers. We sometimes turn away strong applicants for nothing more than balance.

What we do not weigh

We do not weigh which company you work at. We have had successful students from labs you have heard of and from companies you have not. We do not weigh credentialing — degree, conferences, talks. Some of these correlate with the things we do weigh; many do not.

We do not weigh how long you have been using LLMs. The field is too new for that to be a meaningful signal. The engineer who shipped their first feature six months ago and learned from it is, in our experience, often a better student than the engineer who has been calling APIs for two years and is bored.

Closing

If you are considering applying — particularly to one of our heavier cohorts — write the paragraph that says what you are trying to learn. Make it specific. Make it about the work you have already done. That is the paragraph we will read first, and it is the one that moves applications.

We will read it carefully, and we will write back.