A full sample review

Why: Argo Workflow is huge, you need to be more specific as to what you used. Shows you know what you are talking about. In this case, you want to target keywords around Infrastructure Automation or CI/CD:

What did you support exactly with your pipeline? Kubernetes rollout? Pod readiness checks? Error validation? “What” led to 97% downtime?

Also 97% downtime sounds like bullshit. This is why you need to be specific on where.

“Event-driven recovery system” - This is specific, not just “ops automation pipeline”

“Broker outages, replication inconsistencies” - specific cases we are targeting.

Why: Focus on Impact at a business level. You need to add more “general terminology” What does this multi-workflow orchestration do?

The second bullet point is too implementation heavy. If a senior engineer was reviewing your resume, that would be fine. Unfortunately it’s a recruiter. They only look at “buzzwords” and “impacts”.

But we want to focus on is

1. What did you do? – Designed a coordinated multi-workflow system

Why? - To reduce deployment time and eliminate manual coordinate steps

Result? – unfortunately Chatgpt sucks here because it didn’t give that. Here I would revise it and say, you allowed 10+ services to deploy asynchronously or something. Or saved 50+ Hours per week on deployment time.

Why: MTTR - either abbreviate it or don’t. You’re wasting space. MTTR is usually a pretty general term so it’s fine. But good rule of thumb is just don’t abbreviate for most things. Find a way to concise it simply write it out if it’s that important.

Why: “Refactored and developed” - pick one. That makes no sense, if you developed it, you developed it. Refactor usually refers to making changes on another person’s project. Develop keyterm refers to the initial phase of a service/project. There’s going to be maintenance / refactoring but that’s still part of the development pipeline. It’s called refactoring once this hits production and unexpected behaviors surface.

DLQ should not be abbreviated here. Dead letter Queue is pretty advanced topic and should be fully written as not many people know what it is.

Again, this sentence doesn’t include a business impact. The reason why we implement a DLQ is because we want to save data (typically logs or error messages) that are critical to operation that we HAVE to save in the event our ingestion pipeline dies.

In this case, what data were you saving? What’s the impact here? What did the data save help improve? Observability?

This bullet has the same issue as all of your above bullets. Too many buzzwords and low-level details we don’t care about.

“Protocol Buffers, RAII, smart pointers, GTest, and GFlags”

I don’t even know what half of those mean. Buzzwords only mean when it’s related to the architecture of the solution. For example, “I stored data using a S3 Bucket.” – S3 bucket matters because there’s other solutions, like Google Cloud Storage. Or “I built a microservice system….” Microservice matters because it’s an architecture and it’s a broader thing you are familiar with. Monolith would be the alternative.

The reason you try to use so many buzzwords is because you feel like you want to show you know everything and you’re trying to come off smart. But it’s actually the opposite because a senior engineer would never put any of those and simply put the high level keyword like “Microservice resiliency” - It will assume they know about circuit breaker, rate limiting, scaling, and thundering herd.

Why: Not gonna lie, this bullet is very much useless compared to what you did above. If there’s no space, Delete this.

Why: This is good to keep. But would try to combine with bullet 2 if possible.

Why: The hexagonal architecture is so outdated here. Spring boot is also whatever. MySQL is fine. Would take it out if there’s no space

Why: If there’s no space, take this out. You’re literally just describing what redis is meant to do. Not much crazy going on.

Why: Ehhhhh, it’s ok. Basically you integrated Kafka and connected frontend code to Oracle and Hbase. Would leave this one in.

Why: Take this one, it’s garbage. This is probably a 3 point ticket that took you a week or two and it’s mostly just optimizing some simple thing that the senior engineers should’ve done beforehand and forgot.

Why: These should be shorter. This is much earlier in your career and obviously there’s no way you did anything amazing. Keep it simple and short so you have more room to make your above internships matter.

Why: I think this is the research project you are planning to present about right? I would beef this up more and cut down of the more useless parts above.

Research presentation is a HUGE thing.

1. What is this about? – You have that

2. Why does it matter? – log replication, state recovery. Looks good

3. Where is this going to be used? – Ask your professor, any alpha testers or early adopters?

4. Where are you presenting this? Literally just find the Conference name and slap it in. Make another bullet point with it. And literally put your professor name, gives people a name to google. It’s ok to have a public name because your professor’s name is already a public citation. Do it.

Really play with this one. Even ask your professor, what does this exactly do and how does this help things. What are some big companies that might adopt this? Or Why is this such an important research that warrants a presentation?

Why: I assume you’re going to try to clean this up a bit. But still have a structure, vomiting all these words are kind of useless. In that case, when you actually have a lot, it’s better to simply just delete the languages like Java, C++, Go. Those are the useless ones and first to go. Abbreviate some of them, ATS robots should be able to figure out what your looking at. Things like Google Cloud Platform can be GCP. “Regex” is useless. Focus on Framework, Cloud tech, and architectural systems.

It’s important to figure out “if” your resume requires tweaking. The best way to check this is simply, figuring out the ratio of interview/applications. If you applied 1000 times and got 100 interviews -> that’s a 10% callback rate. That is very high. Generally 5% is considered pretty good because that’s 50 interviews per 1k interview with more elite resumes generally going up to 15%.

If you are getting decent rates, it’s more practical to focus on getting better at interviewing than micro-tweaking resumes.