If you’ve taken the Cloud Resume Challenge, it’s reasonable to assume that you’re looking to start a career in the world of cloud computing. Congratulations or condolences, to your preference.
There’s a good chance that in hopes of snaring your next great job, you’ve built a portfolio website on top of AWS to show off your cloud computing prowess. Unfortunately, the interview process isn’t as easy as saying, “Here’s the site I built, where’s my desk?”
Instead, let’s explore how to talk about the site you’ve built in ways that answer the questions your interviewer has but likely won’t do a great job of articulating — and how to decide if the job is right for you.
The 3 questions interviewers ultimately want you to answer.
Every job interview you ever have distills down to three questions, asked in a variety of ways. They come down to your ability, drive, and compatibility. Cast the questions your interviewer asks through the lens of these high-level questions, and you’ll understand where the employer is coming from a lot better.Can you do the job?
Are you crap at computers?
Do you have the raw technical skills needed to do the job?
Do you have experience working at similar points of scale? Are you current with the technologies we work with / can become so in a reasonable timeframe?
The hiring manager absolutely needs to have confidence that you can get the job done. It doesn’t matter how much they like you, how convenient it would be to hire someone immediately, or how impressive your résumé is if you’re fundamentally incapable of doing the job that they need done. Will you do the job?
Are you going to rage quit in a month?
Is the role aligned with your interests, or are you likely to job-hop a few weeks in and leave the employer back at square one?
Will you be happy in the role, or will you hate large parts of it and constantly try to avoid them? Does the job align with your future plans?
Hiring people is expensive. Once someone starts, it’s even more expensive because now other staff needs to devote time and energy to bringing the new hire up to speed. If you quit before the company has the chance to realize that investment, you’re not a solution … you’re an expensive problem.Can we stand working with you?
Are you a jerk?
Are you going to pick fights with colleagues?
Are you going to interrupt people when they’re explaining things? Are you going to presume that your coworkers are fools?
If you’re amazing at the role but can’t collaborate with other people for more than four hours before they threaten to quit, you’re not a hire that any reasonable company is willing to make.
How to show off your portfolio site during interviews
The Cloud Resume Challenge was posted in 2020 and continues to be a popular structure for folks new to cloud to demonstrate their skills. The challenge outlines requirements for cloud career hopefuls to go through the process of building a blog on top of AWS and creating a blog post. This includes:
- Passing the entry-level Cloud Practitioner certification.
- Creating an HTML version of your résumé.
- Styling with CSS.
- Hosting on S3.
- Configuring DNS correctly to get TLS working.
- Enabling a counter with Javascript that stores its data inside of a database.
- Building an API in Python for the previous two things to communicate.
- Testing for the aforementioned Python.
- Making sure all of this lives in GitHub, via “Infrastructure as Code.”
- Putting in place CI/CD for both the frontend stuff as well as the backend.
- Above all else, writing the blog post!
If it wasn’t clear, this is a lot of stuff.
It touches basically everything under the sun in terms of cloud skills. It requires research and asking for help. In the process, you’ll discover some aspects that naturally align with how you think while other stuff remains a mystery to you.
In the context of an interview, if you say building this site was all easy, absolutely nobody will believe you. Be prepared to talk about what parts were easy for you, which parts were challenging, and why you made the choices that you did. Be prepared to pull up different sections of the code you wrote (this is part of the reason to keep it in GitHub — easy demonstrations mid-interview!) and show the parts you’re particularly proud of. Be prepared to explain any aspect of your code in terms of why it works the way that it does.
Let me underscore the importance of being prepared. It may take you a minute or two to come back up to speed if it’s been a few weeks or months since you built your portfolio. Most of us see code we wrote six months ago as having been written by a stranger.
Talk through your thought process during the interview. You want to show the interviewer how you think.
Reminder: Interviews are 2-way streets
If your interviewer makes comments along the lines of “that doesn’t seem hard to me” or is otherwise dismissive of your portfolio, it’s a red flag.
Someone who’s universally good at everything contained within the Cloud Resume Challenge is an incredible rarity. Prospective employers who don’t recognize that are likely to have incredibly unreasonable expectations for their staff. I’m pretty good with the cloud stuff myself, but the JavaScript, CSS, and testing portions are all things I’d struggle with if I personally did the challenge.
I absolutely understand being in the position of “I need a job, any job.” I spent a lot of time there myself in my early career days! But if you have the luxury of being picky, the first thing I’d veto is obnoxious managers and colleagues — especially those who underestimate the work and workload. The job and its managers should be as good a fit for you as you are for them.
Remember those three questions an interviewer is trying to figure out the answers to? You need to find your own answers to them, too.
- Can I do the job?
- Will I do the job?
- Can I stand working with you?
If the answer to any of these is “no,” you should think long and hard before accepting the job.
Tech takes a backseat to company culture and learning
A lot of folks are very picky about what technologies they’ll work with. I get it! If I were taking a cloud job, I’d be far less useful in a shop that used Azure than I would one that used AWS. But I’ll put even that preference in the backseat compared to how I’d consider working somewhere that didn’t treat people like human beings.
Technologies come, and technologies go. The danger in tying your identity so closely to a particular stack is that when the technology starts to be supplanted in the market, you’re more likely to dig in your heels and resist the change.
It happens to all of us. I started my technical career as a large-scale email systems administrator. The SaaS wave started supplanting email because most companies don’t need a dedicated on-site email admin when they’re using Gmail or Microsoft 365 to serve their email needs. It was apparent that this wasn’t going to be something I could coast on for the next four decades, so it was time to improve my core skillset and embrace something else. I focused on configuration management for a time, using tools like Puppet and SaltStack — and then it happened again. Containerization and “immutable infrastructure,” particularly infrastructure as code, changed that particular landscape.
These days I focus on cloud, specifically AWS. If AWS starts losing market share and mind share, it’ll be time for me to once again shift to embrace whatever the market is doing.
One thing about technology that stands in stark contrast to many other professions such as accounting, law, civil engineering, and many more: Today’s “state of the art” is tomorrow’s “how legacy companies do things.” You’ll be forced to learn new things and experiment wildly as you evolve your career, and so will the companies you work for. That’s going to be something you need to take to heart, lest you wind up with 10 years of experience that’s really just one year that you repeated 10 times. “Evolve or die, dinosaur,” is the way this industry works.
