DEV Community: Thilina Ratnayake

Asking Better Questions as a Junior

Thilina Ratnayake — Thu, 10 Feb 2022 18:15:34 +0000

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

Preamble

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.

Support Engineering

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

Escalations

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:

the TSE did not need to come back to you with any more questions,
has a summary on what's been tried,
contains everything they need to continue on the ticket;

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

Questions, as Escalations?

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:

My questions would get answered faster.
My questions would highlight resources and share understanding with the rest of the team.
My team-mates started sharing more about their thought process and how it aligned with my initial steps / research.

So with that, here are:

Photo by Zan on Unsplash

5 Tips For Asking Better Questions as a Junior

(Freebie) 0. Imagine Asking Your Question to Yourself.

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.

1. Problem Statement - One Liner

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).

2. Context - Desired End State

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.

3. Steps Taken - Qualify Question

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.

4. Next Steps - Possible Solutions

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!

5. Help Requested - Means for Assistance

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.

Example of a Good Question

This question is taken from one that I needed to ask last week!

Hey, does anyone know how to decrease the retention window for Prometheus-Server?
The disk on Prometheus-Server has filled up and it's not able to send metrics to Grafana
We've tried making changes in the helm charts but they don't appear to be sticking.
I'm probably going to try doing a live kubectl edit on the cluster next, but not sure if that's the best way.
I'm available for a huddle rn if anyone's available, but also good for a Google meet after 1 hour.

Conclusion

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:

Does anyone have a good compelling event to upsell startup to enterprise?
I have lots of startup clients who need to generate additional revenue for my portfolio
I've already used the multiproduct benefit pitch, but it hasn't landed
Im thinking of talking about a change in NIST regulation next year as my next angle
I'm free after 2 today if anyone is free to roleplay

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 :)

Starting a New Job - ✍🏽 Taking Notes

Thilina Ratnayake — Mon, 01 Nov 2021 04:48:13 +0000

Context

Two weeks ago, I started my new working adventure as a Site Reliability Engineer (SRE). In those two weeks, it's been a flurry of activities and a lot of drinking from the proverbial firehose. One thing that's helped me keep my head above water and really process what I've been learning, has been taking notes.

Here are some things that have helped me in the way I take notes.

Take Notes

Before you start a new job, you have to begin / renew your membership with the cult of note-takers by drawing blood from your hand with a quill. Make sure to ask about it if it's not in your onboarding package.

This is a joke, of-course, however the point still stands that taking notes is an important habit, nay, a way-of-life even, that if you are able to commit - will absolutely pay off ~~hella bank 💰~~.

Especially in the first couple of weeks when you can get lost in the sauce of all the stimuli coming at you - taking notes has has been a life-saver for me in all this if not for simply being a forcing function to pause and process. It's the most impactful, repeatable activity that's helped me ramp-up and build context.

There are so many advantages to this habit, but my biggest motivation for writing notes is that it's best early remedy for quelling Impostor Syndrome (which for me, spikes when I start something new). Taking notes provides an exercise that has a very low-barrier-to-entry where you can start excelling immediately. It allows me to say:

I might not be the best engineer in this room, but I will have the most / best detailed notes.

It's also a great way to be less of a burden on your peers and get quicker answers. Part of asking good questions is clearly defining what you know and what you don't know / need help on. Coming to a peer with a document that clearly defines the problem space, conveys what your context on that problem is and what you've already tried — means the more time that can be effectively spent on syncing state and working the problem.

👵🏽 If you come to me with a question that you've defined, what you've tried and what exactly you need - It is much easier for me to help you because you've already done the hard part. - An old mentor.

As with any habit though - the important part is commitment. You have to commit to taking notes - which if you're new to the practice, will take some time and repetition. The goal is to get to the point where opening up the notepad as your first-step, is second-nature.

Here are some things I do to make note-taking a part of my process and build that habit:

Use a system that's easy to maintain.

My whole system only has two types of notes.
Hook notes to process.
I create notes at the start of things (days, tasks, meetings) and reference notes at the end of things (PR's, summaries, agendas). Tying notes to process builds the habit.

I also have a standing tab on the very left of my browser that's meant purely for taking notes.

I'm fortunate that at this org, they've gone all-in on using Notion (which is what I've been using for personal notes as well) - which provides the benefits of being able to easily copy and sync notes from sources of truth, create powerful templates that fit my workflow as well as easily share notes for review with team members.

If you're not able to use Notion, I recommend using a markdown editor of some sort. One that I've had great success with in the past have been:

Bear
Typora

The reason I recommend markdown, is because markdown is the defacto standard for documentation in tech. This just allows interoperability if you end up wanting to copy/paste things from your docs to code or vice-versa.

But it doesn't have to be a flashy tool - even a word doc will even suffice.

The System

There's probably tonnes of literature and study on organizing information (in fact, there is - library science) that are probably much better thought out - however, here's what works for me.

I have 2 types of notes:

Daily Log
Detailed Notes

By default everything goes into the Daily Log is organized by date as recording your actions through-out the day. If something warrants more explanation (see below), it goes into a Detailed Note. The Detailed Notes should be linked to in the Daily Logs but can also be retrieved from a list.

They are split up in my note-taking tool (Notion) like this:

The first half are my Daily Logs and the second half is my Detailed Notes. The Detailed Notes section is broken down further into notes that are created dynamically ad-hoc, and those that are specifically tied into my own personal to-do list (which is just a different notion page, that has a kanban board).

1. Daily Logs

In Notion, I'll create a doc every-time I start a new day. This doc has my updates on things that happen through-out the day (kinda like a journal). This is especially helpful if I'm juggling multiple streams of work at once but mainly serves as a place to organize my flow through the day, and serve as a jumping off point for Detailed Notes.

Considerations

Daily logs contain my stream of consciousness through-out the day.
- Tasks I pick up (and why)
- Things I hear and have questions about / want to investigate later.
- Commands I see / things I want to research later
If a single point on the daily log ends up taking more than 1 paragraph, consider breaking it off into a Detailed Note

Structure

Since I know that Daily Logs should be something I do every-day, I have them set-up in a template in Notion that I can easily create via 1 click every morning.

It contains only 2 headings:

Important: (Anything that I should keep top of mind for the day - i.e. from my calendar/email)
Notes: Where all my notes fall into.

Here's an example:

Important

Meeting about X at 13:00 today

📅 Daily Log (Example)

Standup:
- Y is going to be working on cool-thing tomorrow, ask if I can ride shotgun
Call with X coming up on Thursday to domain naming conventions
- Read up on existing naming conventions for y
Starting task #SYS-234 from backlog to patch ABC on <system> .

→ Detailed Note: SYS-234, patching ABC on system
Paged for spike in slack mesages for #memechat
- Investigated it: The data platform team was experimenting with a meme bot for hackathon.
Continuing on SYS-234 → Link to detailed note

👾 Think of it like a systems-log, except you're the system.

If anything in the Daily Log meets the following criteria, I break it out into a Detailed note:

The thing I'm writing about or working on can use some extra detail (i.e. diagrams, etc)
What I'm writing about will stretch over multiple days
What I'm writing about can be used by someone else
It needs to be shared

💡A note on templates: Notion is great because it allows you to set and use templates. In my case, I have a template for Daily Log that I just create a new note based on every morning. However, in previous markdown note-taking apps, I simply created a markdown template that I would save as a text macro in something like atext.

2. Detailed Notes

These are more detailed notes that I can take in the process of completing a task or activity. They can also work for something like recording details from a meeting or pairing session as well.

Considerations

They should be "self-contained" - these notes should be easily picked up by someone (lol probably yourself) in 6 months and have enough context to read-through to the conclusion.
Notes should proceed from level of common understanding - > complex.
- This means that base context should be built at the beginning of the note and then proceed to get into more details. Think of it as if you were teaching a class to someone else - you wouldn't start with the end-state.

What helps me in filling out these notes is when I think back to my early days working in Customer Support.

Whenever we got a ticket and couldn't solve it in the first interaction - we were trained to make Internal Notes.

The Internal Notes would contain things like Customer ID, and initial context (ELI5) so that if you had to go offline, another support agent could continue the ticket with enough information instead of having to establish base context again. The other time that Internal Notes would be used for - is when doing an escalation (i.e. escalating a ticket up to the next tier of support).

A bad escalation is one where there's not enough information (especially from the customer) and requires to be sent back down to you. (An Involved effort required is required to proceed.)
A sufficient escalation is one where the majority of information is there but still requires fetching some information. (Some effort is required to proceed)
A good escalation is one where the escalation engineer wouldn't have to reach out to you to gather any more context to move forward.

Detailed Notes should be written in the form of escalation notes for yourself, where it should be able to take the reader from start to finish without needing additional context. This means erring on the side of over-communication and verbosity.

☝🏾 A Good Rule of Thumb for Detailed Notes: Ask yourself if a new-reader would be able to go from start to finish of a topic / lesson using your notes without having to ask question.

Structure

Concise Title Explaining What The Note Is (Think about your choice of keywords / what it'll be like when you need to run a search for this in a couple of months)
1-liner purpose / explanation of what this note is (if the title gets too long i.e. for URL readability reasons)
Link to completion details or TL:DR:
- If this note aided you in completing a ticket, pop that in here. This will be helpful for later if you get similar tasks and need to create process OR if there's an outage and you're searching your personal notes for things that may have interacted with a thing of interest. (It's a needle in the haystack for your search later)
- The TL:DR should be a 1-liner of the solution / thing you did or learned if possible.
Context: <5W's, what should I know if I'm reading this as a new-joiner>.
- Entrypoint <where did this task originate from (i.e. is there a ticket from the work queue like Jira or Zenhub?)
Notes:
- The meat of your note. This should contain anything/everything that you do and why you do it / why it's important.
- Feel free to include checklists along with commands that you ran.
  - Pro-Tip: Include command output as well if you want to make it easy on yourself when you refer to notes during a high-stress situation (i.e. during an outage)
- If there is another document / reference you had to read in order to do a certain thing, include it as a reference (and specifically, the portion from the reference that was important)
- If you learn things from people through word-of-mouth or DM, include that in the note as quotes with timestamps
References:
- Other docs that are useful at a high-level (anything that is required reading for the content of the note should be referenced in-line)
Conclusion:
- Bring it all home with what was accomplished / what you learned.

The Benefits

It's a forcing function to slow-down and structure information.
- Humans speak faster than most people can type. Writing notes as someone speaks is challenging, but forces you to both process hearing the message, as well as writing it down.
- Writing down notes also provides you something to look at in free-cycles which automatically incurs the sub-routine in your brain which tries to create structure and links. In these moments, you will find the gaps in understanding which you can act on to ask questions.
- That delay also allows your internal-voice to ask: "Okay but why?" and if you can't recall the answer instantly - gives you a prompt to speak up and ask for the clarifying information.
Leaving trail-markers / breadcrumbs along the way
- Everyone climbs the knowledge mountain via different paths. However the signs that you leave behind can help out other hikers find their way to where they're doing. Similarly, every time you document some part of your infrastructure, you are doing the same thing for future engineers.
DRY (Don't Repeat Yourself) Learning.
- Don't Repeat Yourself is one of tenets of engineering that are de rigueur and yet, everyone seems to forget this when it comes to process and documentation. Every document you right, is less time spent trying to re-learn a system (especially when in incident response mode) and less time state transferring state to someone in the future.
Build Training Materials As You Learn
- Every note you create for yourself, is also an easily convertible candidate for documentation - to help others.
- It's like a BOGO (Buy One Get One) deal for knowledge capture: wouldn't it be great if the next time someone joins your team, you could solve their entire question - or at least provide context for a large part of it because..you've gone through it before?
- Creating a training program, much-less resources for that program is time-consuming. Documenting as you go allows you to hit two birds with one stone and when documents are able to be examined overhead - allows you to easily determine similarities and paths through the required knowledge — which in doing so gets you pretty far for building a training program.
Auditability
- You have a record of what you did if anything goes wrong (i.e. rolling back in case of an outage). You have notes to back yourself up if you're asked to explain why on something (which can help outline things you can change for a process)

Conclusion

Starting a new job can be a stressful position - requiring the absorption of large quantities of information. One excellent way to to help ingest, process and package information is in taking notes.

While it can be annoying to build up to the habit - some ways to incorporate it into your daily toolset is by (1) hooking it into process and by (2) using a system with a low administrative footprint. It can be hooked it into process by making notes a priority at the start and finish of different events (i.e. start/end of day, tasks & tickets). The process can be made easier to adopt by only having two types of notes: Daily Logs, and Detailed Notes.

A good rule of thumb for writing Detailed Notes is to ask if a new-reader would be able to go from start to finish without having to ask a question. This can be done by providing concise yet richly linked context, verbose instructions and an easily digestable conclusion.

Spending effort to take notes early pays off dividends - in the short term with helping structure and pace learning, and longer term by providing materials that can easily be re-purposed and shared for onboarding and training.

"And for this interview, build me a custom REST-API router for a web-application"

Thilina Ratnayake — Tue, 18 May 2021 01:22:13 +0000

Palms are sweaty, knees weak, arms are heavy,

There's vomit on his Patagucci already

These are the types of tech interview questions my friends used to tell me about that would make me freeze up. The way it's phrased just seems like such a lot of work and hidden complexity. And, I'm sure there is - if you really wanted to knock it out of the park -- but today, at approximately 4 hours into a task that I found more annoying than complex, I realized I'd done just this (sorta, at a very low level).

Header Image Source

T, why were you creating a custom router?

That's a great question, I'm glad you asked 🕺🏽.

I'm currently working on a project where we're creating a bunch of babby API's to CRUD (Create, Retrieve, Update, Delete) some things from DynamoDB tables. From a bunch of reasons, not least of which including the fact that I am the sole engineer on this project - I'm trying to ~~win sales, earn bonuses and make hella money~~ move quickly and maintain as little "live-infrastructure" as possible.

Because of this, I came to the following conclusion(s)/decision(s) on how I would proceed:

TIRED 😰

Running a node.js webserver (and associated infra and management) to effectively broker CRUD requests to a DynamoDB?

WIRED ☕️

Setting up an AWS API Gateway that would trigger a Lambda to CRUD the required things from DynamoDB WIRED ~~We're $erverle$$ baaaabyyyyy~~

INSPIRED ✨

but also doing it all within Terraform so that it's documented, codified and re-usable

Anyways, the TL:DR on this is that there's going to be an API Gateway that gets HTTP requests and then sends them to a Lambda function which decides to how to deal with the request before brokering the interaction with DynamoDB.

I have a single set of resources projects that exist in DynamoDB (in a single projects) table, and my Lambda needs to be able to listen to the request and get the things from DynamoDB.

From skimming my original blue-print above, you might think:

This seems easy enough.

And you'd be right, if I only ever had to deal with one entity projects. As the project went on, now I have a second entity to deal with: status(es?) and more are soon to come.

Originally I'd thought:

1 lambda per resource. /resources will go to the resources-lambda, and /status will go to the status-lambda.

However this approach leads to a few issues:

For every endpoint/lambda, you need to create 3x API gateway references
For every endpoint/lambda, you need to make more IAM accommodations.
Deployments would get annoying because I would need to update a specific lambda, or multiple lambdas to implement one feature in the future (i.e. if i needed to add a new field to the status which makes use of projects)

I ultimately decided:

No, we're going to have the API gateway send all (proxy) traffic to a single lambda 1 lambda to rule them all (as a proxy resource), and then the lambda can decide how to handle it.

This is why I needed to create a router, so that my Lambda function could figure out what it's being asked to do before doing the appropriate response. For example, it would have to handle:

GET /projects - get me all projects in the database.
GET /projects:name - get me details on a single project.
GET /status- get me all the status entries in the database.
GET /status/:name - get me the status of a single project in the database.

Having worked with Node (and specifically Express) before, I knew there existed a way to specify routes like this:

app.get('/users/:userId/books/:bookId', function (req, res) {
  res.send(req.params)
})

And similarly for Lambda, there seemed to exist a specific node module for this case:

aws-lambda-router

import * as router from 'aws-lambda-router'

export const handler = router.handler({
    proxyIntegration: {
        routes: [
            {
                // request-path-pattern with a path variable:
                path: '/article/:id',
                method: 'GET',
                // we can use the path param 'id' in the action call:
                action: (request, context) => {
                    return "You called me with: " + request.paths.id;
                }
            },
            {
                // request-path-pattern with a path variable in Open API style:
                path: '/section/{id}',
                method: 'GET',
                // we can use the path param 'id' in the action call:
                action: (request, context) => {
                    return "You called me with: " + request.paths.id;
                }
            }
        ]
    }
})

However, unfortunately - proxy path support is still a WIP :( This would seem to imply that ❌ I wouldn't be able to get at route params like the name in GET /projects/:name WOMP WOMP ❌

It's also annoying that if you're using custom node-modules, you have to upload it as a zip every single time (as opposed to being able to code / test live if you're using native / vanilla Node).

Well Lambda, I think it's just you (-r `event` parameters) and me at this point.

This would just mean that I'd need to create my own router, and thankfully ~~obviously?~~, the event payload that's passed into a Lambda function by the API gateway contains all the information we could need.

Specifically, all you really need for a router is three things (to start);

HTTP Method: GET,POST etc
Resource: projects || status
Params (a.k.a keys): :name

Once I got these pieces extracted out from lambda by doing the following:

let method = event.httpMethod
let resource = event.path.split("/")[1]
let key = event.path.split("/")[2]

The actual logic of the router wasn't too hard. And I guess, just like in a tech interview -- I came up with 2 "solutions".

V1 - Switch on 1, add more detail inside

let method = event.httpMethod
let resource = event.path.split("/")[1]
let key = event.path.split("/")[2]

switch (resource) {
      case "projects":
        if (key == undefined) {
          body = await dynamo.scan({ TableName: PROJECTS_DB_TABLE }).promise();
        } else {
          let name = key;
          body = await db_get("projects",name)
        }
        break;
      case "status":
        break;
      default:
        body = {
          defaultCase: "true",
          path: event.path,
          resource: event.path.split("/")[1],
        };
        break;
    }

This approach was cool because it allowed me to use the path as the main selector and then code the logic for the required methods as they came up.

However.it doesn't... look great. On first glance, it looks gross, convoluted, and that's just with a single resource and a single method. Secondly, for any new engineers coming onboard - this doesn't immediately seem like a a router when compared to any previous work they may have done.

Going back to the drawing board, and wanting to get closer to the "gold-standard" I was used to, like in express-router.

I wanted to come up with something that would simply specify:

Here's the route that we need to handle
- Here's it's associated handler.

With that in mind, I came up with

V2 - Filter on 2 conditions, add more methods as they arise

let method = event.httpMethod
let resource = event.path.split("/")[1]
let key = event.path.split("/")[2]

 if (method == "GET" && resource == "projects") {
      body = await db_get(dynamo, "projects", key)
    }
else if (method == "GET" && resource == "status") {
    body = await db_get(dynamo, "status", key)
}
else {
  body = { method, resource, key, message: "not supported at this time" }
}

I like this because it's the closest I was able to get to express-router:

app.get('/users/:userId/books/:bookId', function (req, res) {
  res.send(req.params)
})

And has the benefit of being concise, and much more recognizable as a router on first-glance.

Things I'd Improve

I'd probably want to do way more clean-up for an actual interview "REAL" router, but it was still a cool thought exercise. Some definite things I'd want to add / handle:

The get-me-all case is handled by checking for an undefined key. This could probably be guarded for better.
There's currently no guard against someone adding in more than a 1st level parameter (i.e. /projects/name/something/else would still get sent to the DB. Thats not great.
THIS IS ALL IN A GIANT IF-ELSE STATEMENT?? That doesn't seem great.
Limitations: There's no way to do middleware, auth, tracing and a bunch of things that you'd be able to do with express-router (and other routers)

Conclusion

Routers are just giant if-else statements? Idk - this was fun tho.

DEV Community: Thilina Ratnayake

Asking Better Questions as a Junior

Preamble

Support Engineering

Escalations

Questions, as Escalations?

5 Tips For Asking Better Questions as a Junior

(Freebie) 0. Imagine Asking Your Question to Yourself.

1. Problem Statement - One Liner

2. Context - Desired End State

3. Steps Taken - Qualify Question

4. Next Steps - Possible Solutions

5. Help Requested - Means for Assistance

Example of a Good Question

Conclusion

Starting a New Job - ✍🏽 Taking Notes

Context

Take Notes

The System

1. Daily Logs

Considerations

Structure

Important

📅 Daily Log (Example)

2. Detailed Notes

Considerations

Structure

The Benefits

Conclusion

"And for this interview, build me a custom REST-API router for a web-application"

T, why were you creating a custom router?

TIRED 😰

WIRED ☕️

INSPIRED ✨

No, we're going to have the API gateway send all (proxy) traffic to a single lambda 1 lambda to rule them all (as a proxy resource), and then the lambda can decide how to handle it.

Well Lambda, I think it's just you (-r event parameters) and me at this point.

V1 - Switch on 1, add more detail inside

V2 - Filter on 2 conditions, add more methods as they arise

Things I'd Improve

Conclusion

Well Lambda, I think it's just you (-r `event` parameters) and me at this point.