Review a job-seeking portfolio against Karl Koch's hiring manager bar and recommend prioritized changes to site code and content. Use for portfolio readiness, hiring clarity, or a portfolio review with actionable implementation guidance.
Real-world examples not captured yet
This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.
Skill markdown
# Hiring Manager Bar Treat the hiring manager as a user with a job to do: find the work, understand what the candidate contributed, and decide whether their experience warrants a conversation. Creativity should help that reading. A short, specific explanation can be enough; a long case study is not a requirement. ## Scope Default to review and recommendations. Implement changes only when the user requests fixes; follow any existing authorization. Preserve the site's identity, existing components, and unrelated work. Use the stated target role, level, and review scope. If the target is unstated, make a provisional assumption from the content and identify it. Ask only when the answer would materially change the review. Do not infer seniority from visual polish or impose job-seeking requirements on a site made primarily for personal enjoyment. Use relevant [Dive Club examples](references/dive-club-examples.md) for work selection, craft, side projects, and case-study depth. Use [Danny Martinez’s examples](references/danny-martinez.md) for work-first screening, taste, current practice, and role ambiguity, and [Hiring Humans](references/hiring-humans-examples.md) for candidate goals, public-work expectations, and mutual fit. [Design Discipline](references/design-discipline-examples.md) supplies contrasting application preferences, format/access examples, and interdisciplinary work. [Public video and podcast examples](references/video-portfolio-advice.md) cover a first management transition, concise showcases, student evidence, and brand roles. Read only what changes the current judgment: these are attributed preferences and reported examples, not a universal formula. Use the [research workflow](references/dive-club-research.md) when extending the evidence set. ## Read as a visitor, then inspect the implementation 1. Follow the ordinary entry path before using repository knowledge to fill in missing context: landing page → work listing → project → about/contact. Record what is easy to answer and where understanding breaks down. 2. Inspect representative projects that support the target role, including contrasting types of work when relevant. Name the pages sampled and omissions; do not imply a whole-site review from one case study. 3. Trace material findings to the actual routes, content entries, shared components, and styles. Check the full relevant content and linked destinations before claiming something is missing. Separate a fact that is absent from one that exists but is hard to discover. 4. When rendering is available, check the reading path at desktop and narrow widths, with keyboard navigation and touch-compatible controls. Test reduced motion when animation gates access or comprehension. Focus checks on reaching, reading, and returning from the work, and finding contact. Source markup and fetched text do not establish visible layout, interaction behavior, loading speed, or accessibility. A local checkout and a live deployment may also differ: identify which each observation describes. Assess hosted decks and documents by their actual access and evidence, not their format alone. ## The bar | Hiring question | Evidence to look for | | --- | --- | | What are you good at, and where might you fit? | A clear introduction and selected work that supports the target role; claims connected to concrete examples | | What did you make and ship? | Identifiable projects, enough problem and user context to understand them, visible artifacts early in the reading path, and honest status such as shipped, prototype, or experiment | | What was your contribution? | Specific ownership and decisions, with collaborators and constraints where relevant; distinguish personal work from team outcomes | | How do you work? | Useful examples of judgment, tradeoffs, collaboration, and results; enough detail to understand the work without prescribing a process-heavy case-study template | | Can I find and understand the work? | Familiar navigation, descriptive links, legible text and images, scannable hierarchy, and core information accessible without hover or compulsory novelty | | Can I take the next step? | Discoverable, working contact and any résumé or professional context needed for the stated goal | Resolve broad titles into actual responsibilities before judging fit. For Design Engineering, distinguish product design, prototype iteration, production implementation, and refinement of an interaction. Match brand work to its audience, message, and medium; a brand system may demonstrate tools that help other people work, beyond a gallery of assets. Do not equate lifecycle ownership with working alone. For leadership roles, look for evidence of direction and influence where the target calls for it; do not apply leadership criteria to every candidate. Distinguish the public screening experience from a later portfolio presentation. A concise introduction and strong artifacts can earn a conversation without a process essay. D …
More from kemiljk
- Ai Output JudgementCritique generated UI, copy, or code when the user requests a quality review of AI output.
- Android Native UIBuild or review Android interfaces in Compose or Views, including Material conventions, accessibility, adaptive layout, and state.
- Apple Native UIBuild or review native Apple interfaces, including platform controls, accessibility, state, navigation, and macOS window behavior.
- Design EngineeringTranslate design intent into production components or improve collaboration between design and engineering.
- Design For RepetitionImprove workflows used repeatedly by examining recurring effort, waiting, setup, interruption, context retention, and expert paths. Use when an experience works once but may become tiring or inefficient in regular use.
- Design System EvolutionDecide how an existing design system should evolve: reuse a component, add a variant, change its API, or introduce a new pattern. Use when real design or code consumers expose a mismatch and a bounded compatibility or migration decision is needed.