Hi there! I’m a full-stack software engineer at Shopback who recently concluded my job search. This post contains all my tips to stand out and secure good offers from companies like Shopback, Tiktok, Shopee, Grab, StashAway, etc.
I hope this’d be helpful to anyone who’s preparing for their (graduate) technical interview (:
Check out my previous post on preparation resources to complement the tips in this article (:
TLDR
- Baseline requirements must be met. (ie. solve the DS&Algo question.)
- Think from the perspective of interviewers and optimise your answers and delivery accordingly. (What are the key indicators they’d use to differentiate between candidates?)
- There are tradeoffs (technical and practical) for everything, strive to give a nuanced answer based on situation, requirements and constraints.
- Fundamentally understand the stuff that you are learning, so you can inch towards the correct answer even when you’re stuck.
- Probing questions is a good way to display nuance and situational understanding, so don’t be too quick to answer.
- Lastly, treat every interview as an opportunity to learn and test your understanding. Be humble and curious not intimidated.
Disclaimer: If you’re aiming for the MANGA league, algorithmic efficiency will probably be of utmost importance. Hopefully this would still be an interesting read nonetheless 😛
How you answer “What happens when I type a URL into a web browser?” can make a lot of difference. Stay tuned(:
Content
- Typical Format of Interviews
- Baseline Requirements to get an offer
- **Tips on how to stand out at every part of the process.
- Salary Negotiations
- Conclusion
Typical Format (1 hr)
- Introduction (5 min)
- Verbal Technical Questioning (15–20 min)
- DS&Algo Question(s)/System Design (35–30 min)
- QnA (5 min)
Baseline Requirements
Verbal Questions
- Awareness of concepts, definitions, and tradeoffs.
DS&Algo Question
- Solve the task with compilable and bug free code
- Identify the correct time and space complexities
Tips 🚀
General
- If the company has a technical blog, go through it to get context on the type of system/stack/architecture in the company. — bring it up during Verbal Questioning/QnA when the opportunity arise
- Focus on the structure and approach to solving/answering questions so that even if you can’t deliver an answer, you can display coherence and structure in your thought process.
- Ask good questions at the end of the interview, not only does it leave a good impression but it displays growth mindset.
- Don’t underestimate communication skills. A significant portion of my positive feedback was on my ability to communicate coherently and collaboratively + enthusiasm for learning and growth.
Interviewers are also looking to see if YOU would fit into their team/company.
Introduction
- Your introduction has to be short and sweet. State relevant experience and the stacks/languages that you’re familiar with.
- The key here is to directly address minimum technical requirements from the Job Description and set the tone for the interview.
- [IMPT] Use this to steer the conversation in the next segment of the interview, by emphasising on stacks/languages/experience that you are confident in elaborating on.
Verbal Technical Questioning (Crucial)
- This is arguably the most important section (imo) to set yourself apart. There will be “textbook” definitions for most of the questions but that is average at best.
- Be prepared to talk about your past project/experience here
- Giving a nuanced (situation based) answer will allow you to stand out because it demonstrates your ability to apply concepts on realistic situations.
Eg. How to decide between Sql and noSql? “Depends” — is this an evergreen project? what type of data am I storing, are they related? how much data? how do I plan to query the data? what are the current and potential use cases?
Eg. Why not transition to microservices? — how big is my team? do I have resources to handle SRE? **Have I exhausted all other possibilities of optimisation? What problem am I trying to solve?
- Since these questions are generally open-ended, you are able to elaborate on concepts that shows deeper understanding even if questions were not asked directly.
Eg. “What happens when I type a URL into a web browser”
- You can go as simple as “Your server (source) will be sending a GET request for resources from the (destination) server that the domain name is pointed to”- or as deep as going into DNS lookup, TCP 3 way handshake, HTTPs encryption (*asymmetric to symmetric), before finally reaching to that GET request for the resource to display the webpage in your browser. Could even throw in knowledge on OSI model.
- BUT, always check in with the interviewer if it’s okay before you jump into any rabbit hole lol. After all, they have their agenda too.
Popular Questions
- [General] Explain SOLID principles
- [General] What is REST? + Pros & Cons
- [General] What are Microservices? + Pros & Cons
- [Backend] What are database indexes?+ Pros & Cons
- [Backend] What is TDD and Unit vs Integration Tests?
- [Backend] Explain HTTPs
- [Backend] TCP vs UDP
- [Backend] SQL vs NoSQL
- [Backend] Process vs Thread
- [Frontend] SSR vs CSR
- [Javascript] Callback vs Promises, Hoisting
- [Javascript] Single Threaded, Blocking or Non Blocking? -> Event Loop
- [React] What is the Virtual Dom? How can I store state in a React application?
Test your understanding on Microservices: Are you operating on a microservice architecture If you split your code into different repos?
DS&Algo
- Use a programming language that does not require you to specify types for everything (eg. Javascript, Python). This is personal preference but I rather spend all my time solving the problem than having to bother with boilerplate code.
Tip: you can verbally demonstrate your understanding of types.
- Focus on questions that can be “Copy and Pasted”. (Eg. String/Array Manipulation, DP, Recursion, Data structure implementation).
- Questions might be very vague. You are expected to clarify edge cases and probe further. **Something that Leetcode does not prepare you for.
- Make sure there are no extended periods of silence. You should keep interviewers engaged.
- Mention the time and space complexity of your approach BEFORE coding your solution. Ask and take cues from theinterviewer if you’re on the right track.
Remember that the basic requirement is to compile your code, so don’t spend too much time verbalising. At ~7min mark you should be asking to implement.
Think of optimisation in the next order of magnitude. Eg. if you’re at a O(n²) solution, next order of magnitude is O(nlgn). So can you possibly sort the values to improve?
Standard Intuition (time complexity)
O(2^n) — “visiting every node in a binary tree 😩, am I doing repeated work? — if so, cache it”
O(n²) — “nested loops, will sorting help?”
O(nlgn) — “sorting.. can I use pointers or other techniques (sliding window/ greedy) to improve?”
O(n) — “visiting every element once… do I really need to visit every element?”
O(lgn) — “problem set is reduced by half on every iteration, good place to be(:”
O(1) — “Hash map/set ftw, or maybe doubly linked-list / a custom data structure is needed” (but then again, will hashing always be O(1))?
Data structures you HAVE to implement at least once
- LinkedList (singly and doubly)
- HashMap
- LRU cache
- (optional but good) Basic Rate Limiter
System Design
- The interviewer can provide answers on system or requirements, but make no mistake that you HAVE to lead the conversation by asking questions.
- Fundamental: API design (REST), CAP theorem, Microservice architecture and techniques to scale databases — relational and non-relational (super important).
- Secondary: Load Balancers (+ types of balancing) , Pub/Sub, Queues, Web Sockets, In-memory Cache.
- Stand Out: Actual services (eg. AWS, Kafka, Redis, ElasticSearch, Cassandra, etc), alternatives to REST (eg. Grpc) + Apply concepts based on requirements.
Standard Flow of System Design Interviews
System Design interviews should be collaborative
- Clarify Functional Requirements
- What are the main functionalities/use cases? what data needs to be present? what APIs do I need to call? If users are interacting on the go, do I need a mobile interface?
- Will this system be interacting with any other third-party service?
2. Clarify Non-Functional Requirements
- Consistency Or Availability? How many users at any point? what regions will requests be coming from? What is the read-write ratio? What is the scale of read/writes?
3. Design APIs
- Usually can default to REST but it would be nice to explain why and bring up the fact that there are other options too.
4. Schema (Db tables/collection and fields)
- Relational or Non-Relational?
- If Relational, please make sure you understand data types, primary key/foreign key, database normalisation.
Eg. What data type should you use to store $$ in postgres? and Why?
Spoiler alert: it’s Numeric, but why not float?
5. Craft Overall Architecture
Premature optimization is the root of all evil. It is much better (and realistic) to start with a simple architecture and expand from there.
- I suggest you use Whimsical flow charts for this
- Start with a simple architecture: Client (mobile/web)-> Server -> DB
If you haven’t already, you could mention tradeoffs of transiting to microservices before proceeding
- Scale your database (Vertical/Horizontal) and justify why Horizontal > Vertical.
- Scale Backend, split up application into their own services and add in the APIs that will be used for them to communicate.
- Add a Load Balancer/PubSub/Queue/Cache to manage load.
- Do you need a CDN to serve static content across different regions?
6. Replace Architecture with real world services
- Being familiar with AWS services should be sufficient, but it is useful to know alternatives and why you want/not want to use a managed service vs self-hosting.
Check out my previous post for resources to learn AWS
QnA
- Please don’t underestimate this segment.
This is the time when you have absolute control of the conversation.
- This is the chance for you to show interviewers what you care about as an engineer, so use questions to display your understanding of their system, and your eagerness to learn.
- For me personally, I am a product-minded engineer so apart from asking about engineering culture and processes, I ask questions relating to how product and engineering teams interact, and how involved are engineers in product discussions.Finally, ask for feedback. This is firstly for you to improve and secondly, to gauge your likelihood of progressing.
Being aware of your interview performance and feedback is very useful during salary negotiations.
Salary Negotiations
- Don’t reveal expected or current salary during the first few rounds. I’d rather use competing offers as a benchmark.
Because why not let the market decide your fair value?
- Amongst the companies you’ve applied for, you should have strong preference for a few. Ideally by the time they offer you a role, you should already have competing offers.
- It is all about momentum. Once you’ve secured an offer, you have to push everyone along the pipeline to create a sense of urgency and demand.
Why are competing offers so effective?
- After all, a company only has ~3hrs of interaction time with you and if everyone performs well, how else would they justify you over others?
- With competing offers come counteroffers 😛.
Conclusion
In many ways, techniques to stand out in interviews are aligned with techniques to become a better software engineer. So appreciate the learning process and approach questions like how you would realistically solve them.
There is no silver bullet in software engineering. Every decision you make as a software engineer will have its repercussions and what makes you a valuable engineer is being able to recognise these trade-offs and make decisions based on situation + (practical and technical) requirements and constraints.
It is definitely still a learning process for me but I’m sure having this awareness will steer you in the right direction.
Once again, thank you so much for reading till the end of this post, Feel free to hit me up for any other advice or help with your interviews, and all the best!
