(soft music)
- What if you tried to do the right thing
and it still backfires?
Engineers are often so excited to get into
the problem solving that they forget to listen.
In the next scene, Amos is so eager to talk
that he forgets to listen and read the room.
- So, tell me about your favorite engineering project.
- Okay. Well, I changed our architecture
to go from where we had an Apache reverse proxy
and a Java application.
- Okay.
- Then I built an infrastructure behind a load balancer,
a router, a central API connected to several microservices.
- Okay, so..
- And then we had to work with having service tokens
so that our caches were not getting overloaded.
- Okay. So let me stop you there.
Can you tell me maybe what the problem was
you were trying to solve?
Let's set some context for the before and after,
the choices and the trade-offs.
Let's walk through this instead of sprint. Yeah?
- Can, let me just take a step back, okay?
- Now the candidate was trying to describe
a very interesting problem,
but he made a number of mistakes
in how he tried to explain that problem.
So let's start and take a look.
To state of the obvious,
the candidate was way too aggressive
and did not listen and did not read the room.
As the intervention from the interviewer showed,
the candidate also did not explain the problem
that he was trying to solve
and why it was important to solve that problem.
Third, it felt like the interviewer asked a question
that was fairly high level
and the candidate got from 10,000 feet, way over here,
to the technical weeds in a few seconds.
This was an opportunity to demonstrate
how an engineer can apply technical skills
to identify a problem, devise solutions, and then execute.
Instead, the candidates response came across
as a word salad.
There is a gradual nature to solving problems,
coming up with proposals and identifying the best ones.
This involves a bit of back and forth,
suggesting and listening.
This interview felt like a one-way recitation
rather than a collaboration.
This is the biggest risk in getting too tactical.
You miss out on growth,
growing the solution space and growing as an individual.
Additionally, the candidates answer felt like
he confused complexity for impact.
Now I love Italian food,
and I promise I'm going somewhere with this.
The beauty of Italian food is that sometimes
a small number of ingredients makes for a great fragrance
and amazing flavor.
It is not about quantity, it is about chemistry.
Similarly, engineering is not about the number of tools
but how they play together.
Context is how they all fit together,
like the sauce holding the layers of lasagna.
So explain, educate, listen.
Those are the soft skills that are critical
when you go to design interviews,
product prioritizations and technical refactoring meetings.
Technical interviews evaluate these soft skills
as much as they evaluate your actual problem solving skills.
Finally, there was too much use of the word
"I" in the interview.
Engineers often focus on their narrow and focus remit
since they exist in silos way too often.
To build on my earlier analogy,
they are like members of an orchestra
with one instrument to play
and do not understand how everyone else plays together
to make beautiful music.
This engineer was focused on just his instrument
and his notes.
Unfortunately, in an interview that, makes an engineer
seem self-absorbed, disconnected
or worse as if they're trying to claim too much credit.
Remember a technical interview is about two things.
What did you do?
And second, how did you help an overall mission?
Let's do the interview again. Shall we?
Now unlike Amos from the last scene,
Stephanie is a much better listener.
She draws her interviewer into her ideas
and turns the interview into a collaboration session.
Let's take a look.
- So tell me about your favorite engineering project.
(soft laughter)
- Okay.
We had an architecture that was not scaling well,
it had too many single points of failure.
It was creating a lot of downtime at critical moments
and forced us to incur hardware expenses.
But I was part of a team.
- Interesting.
Can you tell me more about the failure modes?
- Yeah, so we had a monolithic database.
It was often overloaded causing downtime
and data inconsistency issues.
And our apps often struggled with latency and availability.
- Ah, You must've had some upset customers.
(soft laughter)
- Yeah.
So we had three different teams actually,
the platform infrastructure, cloud migration and API teams.
They all collaborate on a distributed architecture.
I'm on the API team.
- Okay.
So what does this new infrastructure look like?
- Yeah, so, okay, besides the load balancer,
we set up a cache client.
It's a Java-based library.
And then we configured the infrastructure,
such that the service call first hits the cache.
And then if there's a miss,
we hit the service and we backfill the cache.
- Okay.
Tell me more about reads and writes
and how you prioritized availability versus consistency.
- At this point,
this seems more like a problem solving session
rather than an interview.
Such a difference right?
Now here's a few lessons, like I said before,
content without context is like lasagna without sauce.
Things get cheesy and not in a good way.
In life and at work, progress is the outcome of several
contributions, ideas and changes and random occurrences.
It is hard enough to fit that nuance in an interview.
So starting with too much detail in a rush,
simply exacerbates the problem.
Do not compound the weakness of the interview forum.
Include your collaborators in your solutioning process.
Then even if you slip up,
they are likely to support you before you fall.
People are unlikely to follow you unless you try
and bring them with you.
Finally make the technical solution relevant to a problem.
How did your solution fit into a need?
Was it critical to the business
or was it a crazy idea that you were chasing
in search of a moonshot?
Explain, educate, include.
(soft music)