Toss Place Data Analytics Engineer Application Result

# Toss Place Data Analytics Engineer Application Result

AI Summary

Purpose:

• Preserve the reported application outcome and evidence-based document-screen retrospective for the Toss Place Data Analytics Engineer role.

Key points:

• The user reported on 2026-07-23 that the application was rejected at the document-screen stage.
• A user-provided rejection-email screenshot shows a notification timestamp of 2026-07-22 14:15. The email says incumbent-role staff reviewed the documents and that the decision was made to hire someone more suited to the Data Analytics Engineer role.
• The employer provided no competency-specific feedback. Every explanation involving Snowflake, dbt, DW modeling, product metrics, document structure, or other concrete factors remains an inference from the captured posting and submitted artifacts.
• The highest-confidence explanation is criteria mismatch: the role centered on Snowflake, dbt, formal DW modeling, SSOT, and product metrics, while the strongest submitted evidence was operational data engineering, MySQL schema and query work, collection pipelines, and infrastructure operations.
• ATS or PDF rendering failure is unlikely to be the primary cause: the resume was an extractable three-page A4 PDF with no visible clipping, overlap, or broken glyphs.
• The previous 75-85% fit estimate was over-optimistic because it gave too much credit to transferable SQL, data-quality, and standardization experience and too little weight to missing direct Analytics Engineering and DW evidence.

Relevant when:

• Evaluating future Analytics Engineer, Data Analytics Engineer, DW modeler, data-governance, or metric-platform roles.
• Distinguishing document quality from job-posting fit and screening likelihood.

Do not read full document unless:

• You need the detailed cause ranking, submitted-artifact observations, or durable screening lessons.

Linked documents:

• ../../wiki/projects/2026-career-transition.md
• 2026-07-16-job-search-context.md
• 2026-07-17-four-company-cto-resume-review.md
• 2026-07-22-toss-place-dae-rejection-email.png
• ../../../human/reports/2026-07-17-claude-code-resume-critical-review.md

Open Questions

• Exact application date: Unknown.
• Rejection notification shown in the supplied screenshot: 2026-07-22 14:15. Timezone is not displayed in the screenshot.
• Competency-specific employer feedback: Unknown. The email provides only a general comparative-fit explanation.
• Whether the application form separately captured undergraduate education: Unknown.
• Applicant-pool strength, internal hiring priorities, and headcount changes: Unknown.

Details

Verified result and tracker state

• Company: Toss Place.
• Role: Data Analytics Engineer.
• Result: document-screen rejection, user-reported on 2026-07-23 and supported by a supplied rejection-email screenshot.
• Notification timestamp shown in the screenshot: 2026-07-22 14:15. Timezone: Unknown.
• Canonical tracker state: rejected (불합격).
• Highest confirmed stage: applied (지원완료).
• No interview or coding-test stage was reached.

Employer-stated explanation

The supplied email contains two relevant statements:

• 현욱님의 서류를 현업 담당자들과 함께 리뷰하였으나 — the employer states that incumbent-role staff reviewed the submitted documents.
• Data Analytics Engineer에 보다 적합한 분을 모시기 위한 결정 — the employer frames the result as a comparative role-fit decision.

This supports relative role fit as the main retrospective axis and makes a purely automatic ATS-only rejection less likely. However, the wording may be part of a standard rejection template, so the screenshot does not independently prove the exact review process or identify which requirement determined the outcome. It does not specifically mention Snowflake, dbt, DW modeling, product metrics, AI-generated language, document length, or any other concrete cause.

Posting criteria captured before the application

The role was closer to Analytics Engineer + DW Data Modeler + Data Governance Engineer than to a general data-pipeline role. The captured responsibilities and requirements emphasized:

• Snowflake, dbt, and Airflow-based SSOT construction;
• formal data-structure and standard design;
• DW modeling concepts such as fact, dimension, grain, SCD, and star schema;
• product-metric design and analytical marts;
• metadata, documentation, data quality, and cross-functional model review.

The applicant had strong direct evidence for SQL, Airflow, data quality, identifier policy, reconciliation, backfill, schema work, and operational documentation. Direct production evidence was absent for Snowflake, dbt, formal DW modeling, analytical marts, semantic or metric layers, and product-domain metric ownership.

Submitted artifacts inspected

• Resume: career/클로드이력서/토스플레이스-dae/김현욱_토스플레이스_DAE_이력서.pdf.
• Portfolio: career/클로드이력서/토스플레이스-dae/김현욱_토스플레이스_포트폴리오.pdf.
• The resume was three A4 pages. PDF text extraction succeeded, and visual review found no clipping, overlap, blank page, or broken glyph.
• The resume was not tagged PDF, but its single-column reading order remained extractable. This is a minor ATS risk, not a persuasive primary cause.
• Page one contained a long two-paragraph introduction and nine dense career bullets. Page three was comparatively sparse, so the three-page length did not use recruiter attention efficiently.
• The portfolio contained nine projects across ten A4 pages. Its strongest items covered MySQL schema/query work, data collection accuracy, index optimization, ETL redesign, Airflow/Kubernetes operations, monitoring, and AWS-to-IDC migration.
• The portfolio did not contain direct Snowflake, dbt, dimensional-modeling, analytical-mart, semantic-layer, or product-metric platform evidence.
• The resume's human-voice linter result was BAN 0 / STRUCT 0 / WARN 0; generic AI wording is therefore not a strong rejection explanation.

Inferred cause ranking

#### 1. Criteria mismatch — high confidence

The submitted package proved a capable operational data engineer, but the role required direct evidence of Analytics Engineering and DW modeling. SQL tuning, MySQL schema redesign, identifier policy, reconciliation, and Airflow operations are transferable, but they do not replace production dbt, Snowflake, dimensional modeling, or analytical mart ownership during a short document screen.

The employer's comparative-fit wording is consistent with this explanation, but it does not verify which missing or weaker criterion drove the decision.

The resume made this gap explicit in the skills section with dbt and formal DW modeling are being learned. This was honest, but it also allowed the reviewer to confirm immediately that central job criteria were not yet demonstrated.

#### 2. Evidence portfolio pointed to the adjacent role — medium-high confidence

The first four portfolio projects were library-table redesign, OS vulnerability collection accuracy, DB index optimization, and DB engine comparison. These are strong engineering cases, but together they signal database and data-platform operations more strongly than Analytics Engineering. The one popularity-score case showed a policy metric for crawl scheduling, not ownership of a product KPI, metric layer, or experiment-ready data model.

#### 3. First-page signal dilution — medium confidence

The resume tried to preserve most major career achievements. The resulting first page mixed vulnerability mapping, MySQL query plans, RubyGems reconciliation, index removal, ELT redesign, Airflow scheduling, scoring, monitoring, and cloud migration. A reviewer had to infer the Analytics Engineering through-line instead of seeing direct DW or metric evidence.

The identical problem-solving method paragraph and repeated detailed cases consumed space that did not close the central dbt, Snowflake, DW, or product-metric gaps.

#### 4. Positioning stretched the verified role — medium confidence

The headline described the applicant as a Data Analytics Engineer candidate, while the verified employment role was Data Engineer. The body still read mainly as collection, database, pipeline, and infrastructure operations. This made the application look like a role transition rather than an immediately deployable Analytics Engineer hire.

#### 5. Secondary completeness risk — low confidence

The submitted PDF listed the master's degree but not the undergraduate degree. This may have been harmless if the application form separately captured education. It should not be treated as a confirmed cause.

Explanations not supported by the evidence

• ATS parsing failure: not supported; text extraction succeeded and standard sections were readable.
• Purely automatic ATS-only rejection: less likely because the employer states that incumbent-role staff reviewed the documents, although the possibility of template wording prevents treating the review process as independently verified.
• Broken PDF layout: not supported; no clipping, overlap, or glyph problem was observed.
• Generic AI copy: unlikely as a primary cause; automated human-voice checks were clean and the document contained concrete operating details.
• Lack of technical depth: not supported in general. The problem was that the depth was concentrated in an adjacent engineering profile.
• Competency-specific employer reason: Unknown because the email gives only a general comparative-fit explanation.

Durable conclusions for future applications

• Treat roles with Snowflake, dbt, formal dimensional modeling, marts, semantic layers, or product-metric ownership as stretch roles until direct evidence exists. Do not score them as high-fit from SQL, schema, Airflow, and data-quality transferability alone.
• Keep document-quality scores separate from posting-fit scores. A truthful, polished package can still be screened out when central evidence is absent.
• For future screening analysis, count direct support for each must-have requirement. Label adjacent experience transferable; do not count it as full support.
• When a role is a transition, the project portfolio must prove the target role. A collection of technically strong adjacent projects does not close a missing core criterion.
• The Toss Place result is one data point, not proof that all Analytics Engineer roles are unsuitable. It is evidence that direct DW and metric-modeling requirements carried more screening weight than the earlier fit estimate assumed.

Retrospective tags

• weakness_tags: [기준미스매치, 근거부족, 표현문제]
• Primary axis: 기준미스매치.
• Secondary axes: 근거부족, then 표현문제.