Search for a command to run...
5 Tips To Ask Better Questions and be a Great Junior Software Engineer
I'm a developer from Vancouver, BC who's had an interesting journey in tech starting from support, through cloud infrastructure and project management. Currently I work as an SRE at lightstep helping build and "operationalize" things that helps to guide others towards better o11y :)
No comments yet. Be the first to comment.
How a quotable movie from the 90's drove me to build our internal support & success tooling.
How Terraform's setunion() disregards ordering.
How using a table during the planning step could have saved a lot of headache.
A practical guide in using Bash to solve a real-world problem with examples.
This week I've been finishing up a task that involves updating our CI/CD pipeline to make use of a feature available in the newest release of the Open Telemetry Collector to validate configuration files. In doing so, I got a chance to get up close an...
This article has a companion video:
And there's a chart at the end :)
It's can be scary doing something new. Especially if it's something like starting out as a new engineer, or maybe even as an experienced engineer but starting within a new team. In additional to all the technical aspects - there's so many new relationships to feel-out, norms to establish and culture to absorb.
I remember just a couple of months ago when I was starting my new job, I had the same anxieties as when I started my first job:
Am I asking too many questions?
omg, are my teammates getting annoyed?
Is this a dumb question?
While a big part of getting past that stage involves pushing through those thoughts to ask questions - there's value in strengthening our questioning skills as it is one act that we have complete control over, and which increases our ability to learn, grow and contribute faster.
Photo by Benjamin Child on Unsplash
My first job after graduating from college with a Bachelors in Computer Systems Technology was starting as an IT Support Administrator at medium sized corporate org. At this job, I was given a desk that belonged to someone else with the caveat:
Oh just move some stuff around a bit, but heads up, they might be back soon".
With a cluttered desk, hand-me-down laptop and a notepad - I was left to my own devices to learn about a complex global IT system with a senior engineer who seemed more annoyed to be interrupted by my presence than interested in teaching me.
I lasted two months (but walked away with an amazing friend!).
My next job was also another "awkward fit". I was a Junior Front-End engineer working on a very small start-up that had no documentation or process for helping juniors, and where asynchronous PR reviews were the norm. I still remember my excitement in submitting my first ever PR and then the immediate horror as I looked at the Trello card afterwards which had 74 points to fix as single statements (and no advice or suggestions).
Let me know when you're ready to resubmit.
I let them know after 4 weeks - that this probably wasn't the right fit for me.
After these discouraging experiences, I went through an identity crisis (the first of many!) where I wondered if I was ever meant to be Software Engineer. So much so that the next gig I took on was joining a recently acquired start-up as a Customer Support Representative.
And this is it where it all "happened" for me. This was one of my most critical formative experiences in tech where I lean on the skills I learned, refined and mastered every single day.
Welcome to Support, The Best Damn Org In The Company
Maybe not what you'd expect to hear in that sort of organization - but that was the first thing my team lead said to me. The culture in that company was electric, but the espirit-de-corps and morale in that support team was off the charts. And I think that's because a large portion of them were professionals.
The purpose of a support organization is to assist customers with their questions and problems. To this end, our bread-and-butter was working on tickets. A ticket is generated when there's an interaction from a customer (like an email, or a phone call), and all correspondence takes place on that ticket until the ticket is completed* .
^ Working on tickets
I must have worked on thousands of tickets over my 2.5 years in support, with each ticket having at least 2 interactions. In these tickets, the goal is to identify a customers problem and provide solutions or a course of action as soon as possible. Because of this, I became very good at asking clarifying questions to isolate problems and structuring information into logically ordered, bite-sized pieces. In fact I remember thinking to myself:
At school I learned how to do a wide range of things, from building a custom OS kernel from scratch to writing programs that can handle concurrency and YET; the class that I've used the most in this gig is my Philosophy class.
Logical fallacies. Presenting information. Ordering premises. My non-technical profs would be thrilled!
As part of our daily work - one activity that would come up is Escalations
Photo by Kelly Sikkema on Unsplash
Customer Support Representatives (CSR's) worked on newly created tickets. We would work with the customer to collect diagnostics and recommend solutions based on those efforts. Usually, most problems were common issues that could be solved with a link to a document or a recommendation to do a few things. These were the cases in which a ticket could be considered completed and be closed.
Sometimes - there would be tickets where as a CSR you run to the end of your abilities. Either in what you know about the issue, or in you abilities to troubleshoot and resolve the issue. At this point, is when we'd need to escalate the ticket UP to a Technical Support Engineer (TSE).
Prior to escalating, you had to fill out Escalation Notes on the ticket and let the customer know that the ticket is being escalated. Think of Escalation Notes like a sticky note that you'd put on an essay before you handed it off to an advisor. These Escalation Notes were crucial to a TSE because it would be their first point to orient themselves on what's happened, happening and needs to happen. If it was a long runnning ticket before escalation, the Escalation Notes would hopefully contain the necessary highlights and summary needed in order to hopefully skip reading the rest of the thread. This was was especially important if you were transferring an agitated customer from a call and demanding an escalation because it's taken too long (oops!) -- these escalation notes could be all the TSE has to skim before jumping on to fight the fire.
In this practice, you learned the value of writing good escalation notes quickly.
Bad Escalation Notes required a TSE to chase after you to get more information or ask clarifying questions.
Really Bad Escalation Notes missed critical pieces of information, and would be de-escalated for more fact-finding. Not great if you've just told your customer that you're escalating the ticket.
Oof. Not great when your metrics revolve around the amount of interactions you have a with a customer, and how long a ticket has been in progress for.
However, a set of Good Escalation Notes -- ones where:
They are the equivalent of sending a polished bowling ball down a freshly waxed lane. You can see it get accepted and worked on by a TSE and (depending on the issue) quickly move towards resolution. Strike!
Photo by Ella Christenson on Unsplash
If you wrote good escalation notes, tickets got solved faster.
If you wrote good escalation notes consistently, the TSE's would quietly DM you and teach you about the issue and how to solve it in the future, and sometimes - would even give you the answer and send you back to the customer to be able to close the ticket yourself. (In support, being able to work with the customer to close is a pretty satisfying feeling!)
Photo by Camylla Battani on Unsplash
Fast forward a couple of years and I made the leap from Support into Engineering as a Cloud Infrastructure Engineer. I was now a small fish in a huge ocean and had so, many, questions to ask. This need for information, paired with a large amount of anxiety & impostor syndrome was not a good combination. While my team-mates were so supportive and always around to answer questions, I started wondering:
Hmm, what if I started thinking of questions as escalations? Would that make a difference.
The answer, is yes.
I noticed that when I started applying the same principles, the following happened:
So with that, here are:
After I had gotten a bunch of bad escalations punted back down to me - I started getting into this weird "shadow-boxing" mindset where I would assess my notes in the point of view of a TSE.
What questions would they ask?
Does this give enough information?
What if they ask about X?
Should I clarify Y?
Putting yourself in the shoes of the person reading your question bolsters the quality of your question and also allows you to do some self review.
What's the problem?
In one line, boil down the most important parts of the problem. If there are multiple problems, list the most concerning and make a note that there are other problems (with more info available upon request).
Why is this a problem? What are you trying to do? What's your desired end-state?
If the problem-statement is your starting point, the context should explain your desired end-state or where you want to go. Doing this allows the person answering your question to simply focus on charting the line between the two as opposed to narrowing down the problem scope with (as many) follow-ups.
What have you alread tried and researched?
This portion of the question is extremely useful for so many parties
For the people reading your question, this can serve as a list of things on what not to recommend / check because you've already done it - saving time. It also shows that you as the asker have spent time qualifying your question.
If posted in a team / group space - this can highlight resources or context that others may not have known about.
For the asker, this can help you feel more confident about the validity of your question because you see that you have put effort into research, investigation and solving it yourself.
This portion also allows your coach to get a look into your problem-solving and response processes, which will only help hone your instincts for the future.
What are some next steps you'd try or things you'd investigate?
This step is huge for the person receiving your question.
At best, showing what you've thought about poking next means that they can potentially conserve effort by nudging you in the right direction with some information as opposed to coming up with the whole solution.
At worst, they can disqualify those solutions and explain why - which again, hones your skills for the future.
And sometimes, even they might not even know where to start - but this statement might spark their thought process!
What help do you need? When are you available?
Most team-mates want to help you. However, they're also busy with their own work. Sometimes, they might see your question (and know the answer!) but the task or call in the moment might short-circuit their desire to reach out to you.
If you explain what help you need, and what meetings you're available for (and when) - this could allow a team-mate to acknowledge and set up time for later as opposed to needing to acknowledge and try to come up with a solution.
This question is taken from one that I needed to ask last week!
Photo by kubectl edit on the cluster next, but not sure if that's the best way.This article is specifically titled Junior and not suffixed with Engineer because while this post is specific to engineers, it can apply to a junior in any field. I validated this with a friend who's in Customer Success, and they mentioned that this is exactly the kind of information they'd want from a Junior Account Manager.
As a more CS tailored example:
I hope this post helps ya'll in asking questions, and if there's other points that you'd add - please leave me a comment :)