DEV Community: Igor Afonov

Interview Preparation Notes

Igor Afonov — Mon, 29 Jul 2019 18:52:25 +0000

Interview Preparation Notes

These are the edited notes that I used during preparing for CS-101-style whiteboard interview (a.k.a Google/FB/Leetcode style interview).

Whiteboard style interviews have a mixed attitude - some people like them; some people hate them. My strategy is pretty straightforward - you can whine about the world being an unfair place, or you can push yourself and learn how to invert that binary tree instead 😉

The benefit for me and the biggest drawback for many people - these interviews seem to 'invalidate' previous experience with particular technologies and test basics. Experience of setting up k8s on OpenBSD doesn't matter much, however understanding of how various tech works under the hood matters a lot. The generic process opens the ability to switch technology stack entirely and try something new without being anchored by a particular experience.

An unexpected thing that I noticed while going through coding interview preparation - I feel that it has made me a better programmer. I started to think faster and code cleaner from the first pass. System design pushed me into learning a bunch of things that I used in practice but never bothered to learn how they work under the hood. The behavioral part involved quite a bit of self-reflection and thinking about past experiences and what I want from my future career (and life).

I broke my notes into a few parts:

A bit about about psychology
Behavioral
Coding
System design
Questions for interviewers
Offer Negotiation

Psychology

I feel that anchoring on getting a job in a particular company and position is flawed. Interviewing is a lottery (for both parties to be fair). Internalizing your goal helps a lot. My goal was to teach myself algorithms, improve my coding skills, and learn the internals of databases and large scale architectures.

There was no goal to get that job at FAANG. Always optimize for learning, and results come as a byproduct.

Behavioural

Behavioral or leadership interview is the most important part of the whole process. Coding and System Design are mostly pass/fail stages, and behavioral interview matter most when the time comes for leveling or offer.

My take away:

Be yourself
Be kind
Do not lie and make up stories (even unconsciously)
Spend time on self-reflection and thinking about the past
Think about the future and what you want from your career

I didn't found STAR and other 'smart' frameworks helpful. Maybe they work if you don't have much experience - if you have stories to tell - you're good to go.

Coding

I prepared for a classic whiteboard style interview. I trained myself to write code on the piece of paper or whiteboard without being able to run or debug the code. I invested time into training myself to write clean and readable code from the first pass.

Communication is a crucial part. You should be able to explain what you're going to do before writing code and surprisingly sometimes it's the hardest part. When I'm doing 'normal' programming, I experiment a lot and sometimes start writing code with the idea that I'll refactor or rewrite it on the go or later. It doesn't work if you have 45 minutes, whiteboard and pair of eyes staring at you.

You have to push yourself into thinking first, explaining your thoughts, and only then starting to write the code.

The thing that helped me with all of these parts is formalizing algorithm for solving algorithmic problems. I think this is a bit personal thing and I suggest trying various approaches yourself before settling in. But after you settle - always push yourself to follow it.

My Algorithm for Solving an Algorithmic problem

All these steps are essential, and even if I feel that I can skip one - I always push myself and avoid doing that.

There were a handful of situations when I skipped step only to realize a few steps later into solving the problem that I was wrong and need to go back and start from the skipped step.

Repeat the question in your own words and confirm that you understood it correctly
Build 2-3 regular flow examples - write them
Outline corner cases and ask the interviewer what's expected (and feel free to make it up yourself but mention to the interviewer)
Outline approach and think loudly about its time and space complexity
- If you can't come up with approach try to solve the problem by hand
Confirm with the interviewer (or yourself) that approach is a good starting point. Repeat previous steps if not.
Very slowly write code
Debug manually by using your examples. If you can execute the code - use your examples as unit tests
Optimize (In 80% of situations stick Hash/Set to simplify the algorithm and trade time for space 😉)
Repeat

If all goes right - you're good, if you can't figure out the solution - push yourself. Carefully listen for direct and indirect hints. Do not give up.

Mock inteviews

Mock interviews help with anxiety management, timing, and communication. I used interviewing.io and got a few practice interviews there. You can use friends or hire somebody to do it.

You can also try to interview in companies that you're less interested in. I don't feel bad about it. The company interviews you, and in return, it's getting a chance to hire you.

The Book

I've read Cracking the Coding Interview, but I didn't like it. It's bad. It's too simple, high-level, it's writing is weird and creates a false feeling of this thing being easy. It's not.

I recommend getting good CS 101 or classic algorithms textbook, read it, and spend some time coding basic stuff.

The book that worked for me is Jeff Erickson - Algorithms. It's excellent - it's concise, it uses pseudocode for explaining the coding parts, and it's easy to read (it's for students at the end of the day).

Skienna's The Algorithm Design Manual is excellent too, but it's a bit harder to read, and you'll probably need to pick certain relevant parts yourself. It can work great if you have plenty of time.

The Basics - My Favourites

These are my favorite fundamental problems. They are building blocks for harder problems, so it makes sense to make sure that you can consciously, with full understanding, code them as fast as you can write on a board or type on a laptop.

My usual routine was solving 2-3 of those as a warm-up before doing something more sophisticated.

A lot of these problems are used during screens/actual interviews.

Array: Binary search, Search Insert Position, 2Sum, 3Sum, Non-decreasing Array, First Bad Version, Maximum Subarray, Subarray Sum Equals K, Rotate Array, Search in Rotated Array, Remove Duplicates from Sorted Array
Matrix: Rotate Image
String: Palindrome, Anagram, K-Palindrome, Sliding Window, Balanced Parenthesis
Graph*: DFS, BFS, Dijkstra
Tree: DFS, BFS, LCA, Level Order Traversal, Binary Tree Maximum Path Sum, Sum From Root to Leaf, Convert Tree To Linked List, Serialize/Deserialize Tree
Linked List: Reverse, Find Middle Element, Remove Element
Heap: Build one yourself and understand how it works, Kth Largest Element in Array
Combinatorics: Permutations, Subsets
Dynamic Programming**: Coin change, Generate Parentheses, Increasing subsequence, Buy and Sell Stock
Misc: Binary addition, Meeting rooms

* The hardest part with graph problems is seeing that it's a graph problem. If you see that it's a graph problem, you're 90% done

** Dynamic programming problems make the worst interview questions. They are useless. You're either know the trick or don't. There is little chance somebody can come up with an optimal solution under interview pressure. However, basic understanding helps a lot.

Misc

Buy an actual whiteboard and ultra-fine marker to have 4k resolution.
Look into it as a sport - do practice often. Rest when you need. You can call it competitive interviewing.

System design

The best advice is to find a way to get experience designing systems in real life.

I cheated here - I worked as DevOps for a significant part of my career and have a pretty good understanding of how to build web applications infra. Still, I needed time to systematize knowledge and build my approach. Again communication is the most critical part. If you can't explain your approach - it doesn't matter whether it's right or wrong.

I recommend avoiding mentioning particular technologies if you didn't use them in practice and use generic tools instead. So if you need distributed queue and you never used one - name component "distributed queue" don't dig yourself into details.

My Approach

Understand the goal of the system. Repeat it in your own words
Ask good questions. Define MVP. Think about features and requirements
Establish the scope of the system
Figure out what parts are interesting to interviewer
Make up numbers and drive requirements yourself
Start at the very very high level
Dig deeper and refine
Repeat
Keep going until time is up

My Favorites

These are my favorite problems. I learned a lot while practicing them and doing research.

Atomic counter
Rate Limiter
Distributed Queue
Video upload/serving infrastructure
Full-text search
Real-time messaging (with or without persistence)
Distributed log collector
Your favorite social network
Your favorite search engine

Practice on paper or whiteboard.

Reading and links

The holy grail - Designing Data-Intensive Applications, the book is outstanding. I recommend reading it even you are not preparing for an interview or you're not going to work with data. This is one of the best technical books from recent times.

Surprisingly I found really useful reading through Redis documentation. It's easy to read it, it has a lot of examples and reads more like a book on general storage systems than documentation for DB.

Questions for interviewers

I think these questions part during the interview is useless for both parties. The best time to ask questions is between the offer is made, and the offer is accepted. If you've been made an offer, you can always ask for 30-45 minutes with one of the interviewers and do a "reverse interview" - have a meeting fully devoted to asking questions about the company. Prepare for this meeting and listen very carefully, pay attention to small details - at the end you're at the sales pitch.

As for customary 5 minutes (in the best case) prepare 1 set of generic, but smart, questions and ask them to fill the time.

Offer Negotiation

Have a good alternative (a.k.a BATNA - Best alternative to a negotiated agreement). The best and a bit counter-intuitive alternative is to do great and be happy at your current job.

The End

YMMV 😉

Engineering to Product Management - Learnings and Observations

Igor Afonov — Thu, 20 Jun 2019 11:57:49 +0000

After working as an engineer for 10 years, I experimented with my career and worked as a product owner (a fancy title for a product manager) for 3 years. I worked on projects that had direct business impact. It was fun, stressful, and intense. No regrets 😉

I’ve sorted my observations and learnings by their (subjective) importance:

People manager first

This is the thing that I started to realize when I was at least one year into product management. If you’re running a team, maintaining team health is an essential part of your job.

In theory, you’ll have an engineering manager who is responsible for that, but in reality, you should be laser focused on it yourself. At the end - even if you have an excellent backlog, full of brilliant ideas - if the team is not feeling well or you don’t have team trust - you won’t be able to execute, and everything will inevitably fall apart.

Do 1-1s with engineers and designers. Make sure that they are happy and motivated. Build trust.

Invest in yourself and learn a few bits about psychology, building relationships with people, and engineering management.

You are in charge

You’re responsible for project outcomes. Listen to your team, your boss, boss of your boss, friends, family, that random person from a coffee shop - be informed and process information, but never forget that you are in charge and you are making decisions.

Be bold, make decisions yourself, and be prepared to carry responsibility.

Democracy and business do not blend.

Conserve energy (part 1 - you)

Management is a 24/7 job. Even if you show up in the office for a few hours, you’ll inevitably think about the project 24/7. It’s exhausting and exhausted people aren’t good at making decisions.

Consider your job a marathon, not a sprint. Don’t work in the evenings. Don’t work on the weekends. Re-charge. Take vacations often. Fully disconnect during vacations/weekends/time off.

Conserve energy (part 2 - team)

This thing applies both to you and your team - it’s ok to be idle. Make sure that team understands that and comfortable with that. If you don’t know what to work on - let the team know. Do not try to keep the team busy. Let people work on whatever they want to work on, take time to learn something new, refactor that annoying piece of tech debt from the past or just rest and re-charge.

Do not work on low priority stuff or 10-year-old bugs to fill the time - in the long run, it’s counterproductive and lowers team morale.

And never say no to vacation requests. Even if they are coming at the worst time. Think long term.

Stay on the maker schedule

Avoid meetings congestion - skip meetings if you don’t see the value. Find a polite way to skip and avoid meetings that don’t bring value to you or your team. Provide feedback to meeting owners.

1-1s are for everything. 1-1s are the most important and productive meetings. Take as much value from them as you can. Prepare the agenda in advance. Never skip them (it can send the wrong message). Have them scheduled for the same time always. Make them a habit. (I usually schedule them close to each other and block 2-4 hours every week for them)

Write > Talk. Unless it’s bad news or something that could be interpreted wrong (because it will always be).

Delegate everything (and grow your team)

It is part of - people manager first thing - grow your team, let team members be in charge. Create safety nets, let people make mistakes and be wrong.

A few techniques that worked for me:

One of the team members is a scrum master. This role is not only an accountant or meeting moderator. The scrum master should be able to answer questions during standups and be your ambassador. Invest time in training. Rotate every quarter/year.
When you’re off by any reason (vacation, sick, etc.) ask one of the team members to assume product owner role instead of you. They should drop engineering/design and pretend that it’s a full-time job. Let this person plan, change backlog, attend all meetings instead of you and be in charge. (Safety net - if you’ll drive in a wrong direction we’ll fix it)
Team members do demos - let people show off their work in front of the audience. Stakeholders must be present at this meeting. Invest time into training and making sure that people understand what’s the purpose of the demo and how to do it.
Always ask for input on backlog or roadmap during 1-1s. I don’t see much value in doing it during group meetings because people tend to be more closed and less sincere. 1-1 is a perfect time. If you do it every week, it gets into the habit, and people inevitably think about it before 1-1s.

Always be in the planning mode

Do not put it off for an official “planning meeting” or “backlog grooming.” Planning is a vital part of your job - groom and review your backlog every day - if something changed or you learned something new - adjust immediately.

As a bonus, you’ll recover time by combining staying in planning mode and discussing product future with the team during 1-1s. You’ll be able to drop “official” plannings. These meetings tend to be long and exhausting. Many times they end up in a format where 2 persons argue about a small thing and the rest of the team just listening and thinking about what they could do better with their time.

Data

Data informs everything. Do it yourself (or delegate within your team). Learn SQL and Statistics 101. Do not depend on other teams. Data is your job.

Start every project with data infrastructure. If you can’t measure improvement - there is no improvement.

I always set aside 5-10 minutes between demo and retrospective to do data demo for stakeholders. Walk through metrics and tell what we are going to do next sprint to drive team metrics. I find that it forces me to dig deeper into the data and avoid working on things that do not drive metrics.

Pursue the big thing

Distractions creep into the backlog. Review and purge often. Skip bugs unless they are that bad. Bugs tend to eat 90% of the time in return of 10% improvement.

Focus on one metric and drop anything that doesn’t affect it.

Get thing out of the door ASAP

Make it run, make it right, make it fast transfers perfectly to product management.

Release the product as soon as it looks like something usable, and then iterate on the live product. Perfection is the enemy of good.

Constant cadence of iteration helps a lot with meeting deadlines (and predicting misses).

The Process

Pick your processes and stick to it.

Adjust by doing retrospectives and carefully listening during 1-1s.

Long meetings are the worst - avoid them at all cost. Always moderate. Ask people to follow-up 1-1. If there is a meeting that needs more than 30 minutes - refactor it by splitting, canceling, changing participants.

Cross team communication (a.k.a The Politics)

Politics and cross-team dynamics are very fluid and company depending.

A few things I learned:

“No” is the default answer. (But never say “no” be a polite and diplomatic person). People around are asking for random things that are important to them around your area of ownership. Use it as an input and consider it but do not jump into it or you are risking saturating your backlog with random things and impeding work on The Big Thing.
Ask for help or advice very carefully. You’re sharing responsibility when asking for help. People will (unconsciously) expect you to follow their advice and become sad if you don't. If you are not going to follow their advice — it’s better to avoid asking.

Reading recommendations

I didn't found anything that stand out as the only source of truth.

Hovewer there were a few reads that I enjoyed.

37 Signals - Getting Real ★★★★★
Michael Lopp - Managing humans ★★★★★
Michael Lopp - Blog ★★★★★
Joel Spolsky - Blog ★★★★★
Paul Gragham - Blog ★★★★
Ryan Holiday - The Daily Stoic: ★★★★
Malcolm Gladwell - Blink: The Power of Thinking Without Thinking ★★★★
Allan Pease - The Definitive Book of Body Language ★★★
Robert Greene - 48 Laws of Power ★★★

The End

YMMV 😉

DEV Community: Igor Afonov

Interview Preparation Notes

Interview Preparation Notes

Psychology

Behavioural

Coding

My Algorithm for Solving an Algorithmic problem

Mock inteviews

The Book

The Basics - My Favourites

Misc

Links

System design

My Approach

My Favorites

Reading and links

Questions for interviewers

Offer Negotiation

The End

Engineering to Product Management - Learnings and Observations

People manager first

You are in charge

Conserve energy (part 1 - you)

Conserve energy (part 2 - team)

Stay on the maker schedule

Delegate everything (and grow your team)

Always be in the planning mode

Data

Pursue the big thing

Get thing out of the door ASAP

The Process

Cross team communication (a.k.a The Politics)

Reading recommendations

The End