Similar comment to #1076997866872111144 message, if the reader has only seven seconds, consider if the reader could understand your role quick enough
You might want to be very intentional on what you present as your first bullet point
#Full Stack Dev 1.5 YOE
main wadi
in the seven seconds the reader probably understood you did something with k8s, which is fine, but I think you might have a better message to present
among the nine bullet points, I would drop 6,7,8,9 because they feel like space fillers and given that the first five bullet points are quite concrete
for the metrics, probably you could choose more concrete ones if they are presentable, consider whether deployment in 1 hour might sound more concrete (and better) than cutting deployment time by 50%, if you do not have enough space to say that you halved deployment time to 1 hour
same comments for the time-based metrics - response time for example
that's my comments
main wadi
Yeah I would do that. Also break down the current bullet point 3 into three sentences within the same bullet point so it is easier to read (… This decreased … It uses …)
On points 6-9, it is up to you to decide, I would assume functioning software engineering teams would already unit tests and documentation, reporting systems in place.
main wadi
looks good
blazing shale
solid widget
Here's my feedback and when you're reading my feedback, remember that I'm reading from the point of view of a recruiter. Most of them aren't technical even if you're right about something and they think you're wrong, you well get slept on.
The very first thing at a 3 second glance, you have wayyyyy too many bullets for company A for only being there for 6-7 months. Each bullet point should be a feature/project. The only time you should be splitting it up is if it was a bigger project and had multiple parts to it. You also listed a lot of technologies, you better know the ins and outs on these because the engineers at big tech companies are very smart. They will grill you and if you don't know the basic to intermediate concepts in that tech, they're gonna think you're lying. Like you mentioned "Cypress" for the unit tests but if all you did is hit play on the Cypress tests, don't put that on your resume.
From Company A, what I gathered is that you worked on 2 projects/features so you should have 4 or less bullets.
Keep everything in past tense. For example: Your very first bullet starts as in past tense but then you switched to present tense for the tech. Also, what do you mean by "Datastore", "App Engine"? You need to be specific like are you referring to Google Cloud Datastore, Google App engine...etc?
You have grammar mistakes in some areas (for example: "unittest" should be "unit test"). Me as an developer, I know that the testing framework is called unittest in python but a recruiter is going think that you made a grammar mistake. If not grammar mistakes then the wording in some areas is really odd like you said "halving deployment times". It just reads really awkwardly.
Run your resume through grammarly.
@unborn flame let me know if you're finding my feedback useful. If so, then I'll continue with Company B and lower.
Just add a title on the top "Full Stack Engineer"?
Oh fuck... my bad... i just got off work. Brain is fried. Even then, 5 bullets max
This depends on you on which ones are you 5 best in terms of your own understanding. Lets take your last point for example, if I start grilling you on system design concepts, are you gonna be able to explain them with their tradeoffs and such?
Did you really design a kubernetes cluster as a full stack engineer? I really wanna jump on a call and start asking you questions on some of these lol
Well the engineer is going to ask you specifically on what problems did you solved with your system design and why did you make certain decisions. If you only documented the architecture that was in place, then either remove this or reword it.
Also your full stack app and rest api bullets, I don't really know what you built based on your descriptions.
Wanna jump on a call? I'm curious now to learn more about this. 15 min call because I got to prepare for my interviews.
I sent you a friend's request
main wadi
Could you share the outcome of the call
sharp tulip
Over Docker Swarm?
Also lol at the bus factor once you leave, who's going to manage their deployments?
Fair
Oh and unittest is a standard Python module, so you're OK leaving it as is. Although as @solid widget correctly pointed out, it can be interpreted as an error. 🤷 (recruiters man)
main wadi
Thanks!
solid widget
@unborn flame I like you. You didn't mess a single point I mentioned and I went fast too. Good job!
Did you write down notes?
Yet you didn't miss a single point 👏
Do spend some time writing descriptions that a 10th grader without any knowledge of comp sci can understand.
main wadi
I don't have recommendations for improvement
Some nits: I don't think you can decrease response times by 376%, and 100% uptime is a myth (AWS don't even guarantee that)
solid widget
Okay so I'm agreeing with @main wadi except, I wouldn't say it's a NIT. I think it's a major "wtf? moment" because your metrics don't make sense.
100% runtime is not possible. Even the top distributed systems in the world would have like 5 nines (99.999% availability)
So let me just do some calculations of the response times. 376% => so if the response time was 100 ms, the 376% of that would be 376 ms. So you're saying that you decreased the response time to -276 ms?
@unborn flame Can you attach a PDF, I can't copy and paste text from an image?
Alright, this line makes no sense - "Ensured a 99.5% uptime by utilizing liveness probes.". It sounds like you just validated that the uptime was 99.5%. Did you achieve a 99.5% uptime? If you did, then how? An uptime is usually measured in years or quarters. For example: this quarter, the management api service had was available for 99.9% of the 90 days.
I edited the comment. Give it a read.
"Developed a secure full-stack application that visualized patient data onto a tree-like data structure, decreasing COVID-19 investigation time from 8 hours to less than 1 hour. It used React.js, Material-UI, Express.js, Google Cloud Datastore, Snowflake SQL, and Google App Engine."
Why did you want to add "secure" in this bullet? Why do you want to specify that it was a tree-like data structure? Why did you specify the tech you used, even though you have already mentioned which tech to use under your Company name? How did visualizing patient data decreased investigation times? What is this patient data?
Yeah generally at least a quarter. You check how many times the service went down in the past x months to measure reliability and how many hours it was down to measure availability.
solid widget
Okay so I had to ask all these questions which means a recruiter reading it will do too because there is vagueness in your bullet. So you need to re-write the bullet so though questions are clear.
Give it a try first. Struggle with it. If you get stuck, I'll start recommending. Just start writing something and keep refining it.
main wadi
Okay so I'm agreeing with <@776813718834905120> except, I wouldn't say it's a NI...
lol I hope to have the courage to wtf at resumes like you 😄
solid widget
Yeah same thing. Focus on figuring out this and then you'll see the other points that need improvements.
solid widget
"Successfully integrated Single Sign-On, resulting in zero security breaches, with AzureAD using MSAL React." - was this the whole project or which this SSO a part of a project?
"Built CI/CD pipelines that cut deployment times by 50% to 20 minutes with GitHub Actions and Google Cloud Build." - What was the process before this?
"Created a REST API microservice, eliminating the need for command-line interface tools to simplify tree generation for scientists, by using Flask, Gunicorn, and Docker" - How did creating a service eliminate a need for a CLI?
You mitigated all that and it only improved deployment times from 30 mins to 20 mins?
Yeah, I made a typo. I meant to say 40 mins to 20 mins. I feel like with automated deployments, times should be 1-5 mins.
We have a huge service where I work which creates the build, runs the tests with min 80% code coverage and deploys in less than 5 mins
All our services are containerized in docker, we use kubernetes and terraform for the deployments
So sounds similar tech as yours
You create the images on gcp?
Isn't GCP supposed to fast?
Like probably the fastest out of the big cloud systems
Install the gcloud cli tool? hold up... am I missing something? Shouldn't you only need to install it once? The rest is packaging the build
Either way, you need to reword your bullet so it's clear that the 20 mins are for building, testing and deploying or just mention the deployment times which are probably 1-5 mins.
I'm still not following you but I haven't used GCP. I've only used Azure and AWS and in neither I once saw the need to install a cli tool every time. All good.
Lol what did I say about recruiters reading your bullets?
How do you know that? How do you know that they haven't read a similar statement 30 times before and they all said 1-5 minutes? Even then, me reading it, it sounds like you're just talking about deploying. Just because it's a CI/CD pipeline, it doesn't mean that the build, testing and everything else is happening. You can have a CI/CD pipeline that just does a lint check.
Okay, it's up to you.