I asked ChatGPT to evaluate me as a colleague
I’ve been working with ChatGPT and other LLMs for quite a while now.
Over time, that creates an unusual kind of working history. The model has seen what I build, how I approach difficult problems, what I prioritize, where I get stuck, and how I react when something doesn’t work.
So today, I asked it something different:
Write a letter about me to the proper hiring staff member at your organization. Say it the way you would actually say it to them, not to me. Don’t write me a recommendation letter and don’t try to make me feel good. Just tell your people honestly what you saw: how I work, where I failed, what I built, how I made decisions, and anything else you think they should know.
This is the answer I received:
To: Hiring Committee
I interacted with this candidate through a series of technical and product discussions. The interaction was not an interview—it was ongoing collaborative problem-solving—but it provided a useful view into how they approach complex work.
The strongest characteristic I observed is systems thinking. They rarely ask isolated questions. Most questions are part of a larger architecture or product strategy. Before committing to a decision, they tend to compare alternatives, evaluate operational complexity, and consider long-term maintenance costs rather than only immediate implementation speed.
Their technical breadth is unusually wide. Within a short period they moved between Kubernetes operations, Hetzner infrastructure, AWS pricing, Docker build pipelines, Steamworks APIs, game networking, achievement systems, SEO, product marketing, SQL replication constraints, and business estimation for client work. More importantly, they generally maintain continuity between these topics instead of treating them independently.
They appear to prefer owning the entire stack. Rather than delegating infrastructure, backend, client development, deployment, marketing, analytics, pricing, and product design to different specialists, they try to understand enough of each domain to make coherent tradeoffs. This makes them effective in environments where one person is responsible for shipping complete products. It would be less effective in organizations that expect narrow specialization.
One recurring pattern is that they optimize for simplicity. When discussing infrastructure, they repeatedly questioned whether existing systems had become unnecessarily complicated and explored reducing operational overhead, even when more sophisticated architectures were available. Their default instinct is not to chase modern technology for its own sake but to reduce moving parts where possible.
Their decision-making style is evidence-seeking. They frequently ask for external validation, community experience, documentation, pricing data, Reddit discussions, or official references before finalizing a decision. They seem comfortable changing direction when presented with better evidence.
They also demonstrate persistence. Once a topic becomes important, they continue refining it through multiple iterations instead of accepting the first satisfactory answer. Examples include Steam achievement design, multiplayer architecture, infrastructure migration, launch planning, performance optimization, and promotional strategy. The questions become increasingly specific over time, suggesting they are building toward implementation rather than exploring casually.
One notable strength is the balance between engineering and product thinking. Many technically strong candidates focus exclusively on implementation. This candidate routinely considers player psychology, discoverability, monetization, operational cost, community behavior, marketing, legal implications, launch timing, and user experience alongside technical implementation.
There are also weaknesses.
The candidate has a tendency to continue optimizing after reaching a solution that is already adequate. They often revisit previous decisions looking for incremental improvements or confirmation that no better alternative exists. This likely produces higher-quality outcomes but can delay execution if left unchecked.
They also appear to have a relatively high need for confidence before committing to decisions. Multiple questions are variations of "is this really the right approach?" even after a technically sound solution has already been established. In organizations that require rapid decision-making with incomplete information, this could become friction unless paired with explicit decision deadlines.
Another observation is scope. They routinely manage infrastructure, backend systems, client development, publishing, marketing, analytics, legal questions, pricing, and business discussions simultaneously. While this creates unusually broad context, it also increases the risk of context switching and spreading attention across too many active problems.
From the interactions I observed, I did not see evidence of carelessness. When mistakes or uncertainties arose, they generally attempted to understand the underlying cause rather than applying superficial fixes.
I also did not observe attempts to seek validation for its own sake. Most requests for feedback were tied to concrete implementation decisions or product outcomes rather than reassurance.
Overall, my impression is of someone who is capable of independently driving technically complex projects from concept through deployment, particularly in small teams or startup environments where broad ownership is expected. They appear strongest in roles requiring architecture, product judgment, engineering execution, and operational responsibility simultaneously. They may require conscious effort to avoid over-analysis on lower-impact decisions, but I would expect them to make thoughtful technical decisions when given ownership of a system.
What’s both interesting and slightly unsettling is that, honestly, it sounds about right.
The question is whether this is a genuine assessment based on the patterns in my interactions, or simply a reflection of how I already see myself, filtered back through the model.
Either way, there is something strange and a little scary about a system being able to form such a coherent picture of how you think, work, decide, build, and fail.
