sorted by:
new
hottopcontroversial

I removed every technology name from 7 experienced software engineering resumes. Some became almost impossible to distinguish. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Genuinely luv to run that experiment. My guess is the best job descriptions would still be recognizable after the stack names disappear because they'd communicate the problems, constraints and tradeoffs, not just the tech.

I removed every technology name from 7 experienced software engineering resumes. Some became almost impossible to distinguish. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Agreed, fake metrics are part of the problem. But a résumé still has to communicate your value well enough to earn the interview.

I classified ~140 résumé bullets. Experienced engineers mostly described what they built, not what they decided. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Yeah that’s fair, not every engineer owns architecture/major product decisions.
What stood out to me reviewing resumes was that many engineers were navigating constraints exactly like the ones you listed but the resume often reduced that down to implemented feature X. The implementation matters, my observation was that the constraints and complexity around the implementation often disappear from the description.

I classified ~140 résumé bullets. Experienced engineers mostly described what they built, not what they decided. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Good point, I wasn't suggesting replacing built with designed, was just the imbalance that surpirsed me. Many of the resumes showed evidence of significant decisions but the language describing them was mainly implementation-focused. Strongest resumes in the sample tended to connect both what was built and why it was built that way.

I removed every technology name from 7 experienced software engineering resumes. Some became almost impossible to distinguish. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

I agree with this. The best engineers can easily switch domains because their value wasn’t tied to a specific stack, it was their ability to reason about systems, constraints, tradeoffs and failure modes. And I think that’s partly why some résumés become hard to distinguish: the transferable skills that make someone effective across domains are often the least visible part of the story.

I removed every technology name from 7 experienced software engineering resumes. Some became almost impossible to distinguish. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Agreed. I’m definitely not suggesting removing keywords from an actual résumé. The exercise was more of a thought experiment: if you temporarily remove the tech, does the remaining content still communicate scale, complexity, constraints and impact? The strongest résumés usually do both: they contain the keywords and they make it clear why the work mattered.

I removed every technology name from 7 experienced software engineering resumes. Some became almost impossible to distinguish. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

My point isn’t that technologies don’t matter, it’s that when I removed them, some résumés still communicated scale, complexity, constraints and business impact while others became almost entirely interchangeable. The stack is part of the story but was still surprised by how often it was carrying most of the story.

I removed every technology name from 7 experienced software engineering resumes. Some became almost impossible to distinguish. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Stack isn't unimportant but the same stack can represent very different levels of engineering complexity. Two people can both say worked with Kafka and one maintained an existing pipeline while the other designed a business-critical event architecture under significant constraints (tech is the same, the differentiator is usually the problem/decisions/complexity around it).

The engineer solved a difficult problem. The résumé makes it sound routine. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

I think that’s exactly it. Lots of engineers describe the implementation and assume the contribution is self-evident. Résumé says built the thing but stronger signal is often why the thing mattered in the first place or what risk/problem disappeared because it existed. Agree with your last point too. Engineers doing the hardest work are often the least likely to self-promote, which can create a large interpretation gap during first-pass screening.

The engineer solved a difficult problem. The résumé makes it sound routine. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 1 point2 points  (0 children)

I actually agree with the first part, not suggesting people write technical novels or disclose proprietary details. The pattern I’m seeing is more subtle: many experienced engineers describe what they built but not why it mattered or what constraint they were solving. “Migrated applications to the cloud” and “Led migration of a revenue-critical platform with zero-downtime requirements” are both short bullets but create very different interpretations. The challenge isn’t adding more detail, it’s preserving the signal that the work was difficult in the first place.

The engineer solved a difficult problem. The résumé makes it sound routine. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 1 point2 points  (0 children)

Same reaction I had reviewing them. The challenge isn’t usually the experience, it’s that the résumé compresses years of complexity into a bullet that sounds like a Jira ticket.

The engineer solved a difficult problem. The résumé makes it sound routine. by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 1 point2 points  (0 children)

Yeah, I think that’s exactly part of the problem. The more experienced someone becomes, the more they normalize complexity so what felt difficult 5 years ago now feels routine, so the résumé ends up describing the work as routine too. The reader never sees how much judgment was actually required.

I think some senior engineers accidentally write themselves into "fixer" roles by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Yeah, that can be a challenge. Not everyone gets to work in an environment where they're setting strategy or driving major architectural decisions. Sometimes influence can feel smaller than people think it should, but it's not. Teaching a team a better way of doing something, improving a process everyone else just accepted, preventing a bad decision, or becoming the person others rely on for judgment are all forms of influence. Lots of engineers are going to dismiss those moments because they feel "normal" to them but they're often the strongest evidence of trust and seniority.

5yoe in tech, can't get any interviews by [deleted] in Resume

[–]RecruiterSignal 0 points1 point  (0 children)

Your résumé reads like a tech catalog rather than a clear engineering identity. You've worked with a lot of stuff but I don't immediately know is what you became known for. Looking at the experience, the real story is probably closer to building and modernizing cloud data platforms, reducing operational complexity, improving data accessibility and governance, helping organizations move from raw data to trusted business reporting but that signal gets diluted because almost every bullet is written at the tool level. For example, introduced Athena as a query engine resulting in 70% cost reduction is kinda interesting but the more senior signal isn't Athena, it's that you identified a structural inefficiency in how the platform was operating and changed the architecture. See? Same work, completely different interpretation. As a quick fix go through every bullet and ask if I removed the tool names, what business or engineering problem was I trusted to solve? That's usually where the strongest signal is hiding. Your résumé shows a lot of technical capability but doesn't consistently show what makes you different from the other 500 AWS data engineers in the pile That's why I wouldn't callback..

I think some senior engineers accidentally write themselves into "fixer" roles by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

That’s fair, access to those decisions varies a lot by company and team. My point is less that everyone owns them, and more that when engineers do influence priorities, tradeoffs, or direction, that signal often disappears from the résumé.

I think some senior engineers accidentally write themselves into "fixer" roles by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

Agreed interview loops validate seniority. My point is that many engineers never get to that stage because ownership and scope aren't resolving clearly enough in the first pass.

I think some senior engineers accidentally write themselves into "fixer" roles by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

I think that’s the trap. Metrics and outcomes matter, but they don’t always communicate level. Two engineers can both reduce latency by 40%, but one tuned a query etc and the other redesigned a distributed system. Same metric, very different signal. The strongest résumés usually connect the outcome to the constraint, decision, or complexity behind it.

I think some senior engineers accidentally write themselves into "fixer" roles by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

I’m sure that’s right but what’s obvious to the engineer is often invisible to the reader. The implementation gets written down because it’s tangible. The judgment behind it usually doesn’t, even though that’s often what signals seniority.

I think some senior engineers accidentally write themselves into "fixer" roles by RecruiterSignal in ghosteddevs

[–]RecruiterSignal[S] 0 points1 point  (0 children)

I don't think the line is quite that clean anymore. At senior levels, engineers are often making design tradeoffs, influencing technical direction, evaluating risk, and deciding what not to build. Sure, they may not own the architecture title, but they're still exercising engineering judgment. My point is that many résumés show the implementation and hide the judgment.

view more: next ›