Hà Nội giữa mùa hè và những cú sốc công nghệ!

Hà Nội giữa mùa hè và những cú sốc công nghệ!

Năm nay giữa tháng Bảy, trời Hà Nội đổ lửa, tôi cùng vợ và hai cậu con trai từ Mỹ về thăm quê. Tưởng là về nghỉ hè cho các con học tiếng mẹ đẻ, ai ngờ chính tôi mới là người “được học” lại từ đầu – học cách sống trong một xã hội Việt Nam phiên bản… update 10.0!

1. QR Code – thần chú mở cửa mọi cõi giới

Chưa kịp hoàn hồn vì cái nắng 39 độ + độ ẩm 100%, tôi đã bị hớp hồn bởi sự “số hóa toàn dân” ở Hà Nội. Mua bát cháo ở vỉa hè? QR nhé em! Mua cốc trà chanh? Scan giùm chị cái! Từ hàng ăn tới hàng cắt tóc, không ai đụng đến tiền mặt – trừ tôi.

Đỉnh điểm là lúc tôi mua bát cháo sườn ở đường sau khu nhà. Tôi lóng ngóng dùng điện thoại để đăng nhập app ngân hàng, rồi quét FaceID, chờ mãi chưa xong thì cô bán hàng quát:

“App đâu? Bấm đi! Biết dùng không? Đưa đây cô bấm hộ!”

Bỗng thấy mình như sinh viên năm nhất thời… 2000 về quê ăn Tết, ngơ ngác trước chiếc máy ATM lần đầu thấy trong đời.

Chưa hết, phòng khám y tế, nha khoa cũng  chuyển hồ sơ, đặt lịch qua nhắn tin Zalo. Tôi đi khám mà như đặt GrabFood: chọn bác sĩ, đặt giờ, xác nhận bằng emoji. Các giấy tờ sổ sách không cần in ra cầm tay mất công như trước…mà là chụp ảnh gửi Zalo (hơi mất an toàn tý nhưng mà nhanh :p)

2. Thương mại điện tử – nhanh như cơn mưa rào Hà Nội

Ở Mỹ tưởng thế nào đặt hàng nhanh còn phải chờ qua đêm, chứ ở Hà Nội bây giờ, đặt hàng online là chuyện “nhanh như chớp” và rẻ như… kẹp tóc 4.000 đồng. Tôi thử mua vài thứ “cho vui” – không ngờ cuối ngày là shipper đã gọi điện thoại í éo dưới nhà ! Mấy anh shipper ấy cắm trại sẵn ở ngã tư, rải các món đồ ra đầy bạt rồi tay nhoay nhoáy bấm điện thoại gọi khách tới nhận hàng. Ấn tượng nhất là khi tôi đặt 20kg dừa, ship nội thành trong vòng 3 tiếng. Ở Mỹ Prime 1-day là nhanh, nhưng mà ship dừa tươi kiểu VN thì vô địch.

Các shipper Hà Nội giờ ngồi tụm năm tụm bảy bên lề đường, tay cầm điện thoại như thể đang bán vé số kỹ thuật số. Thật sự là thương mại điện tử ở đây không còn là “giao hàng nhanh”, mà là “giao hàng như thể vừa nghĩ xong đã tới”.

3. Bệnh viện công – di tích sống và nghịch lý thời đại

Nhưng không phải cái gì cũng hiện đại. Tôi đưa mẹ đi bệnh viện “top đầu” ở Hà Nội, mà cứ ngỡ đang đi thăm… bảo tàng thời Pháp thuộc. Nhà cửa rêu phong, hành lang như mê cung, TV thì có mà bật không lên, giường cho bệnh nhân thì không nâng lên hạ xuống được, còn phải nằm ghép 2 người 1 giường, còn người nhà thì vẫn phải trải chiếu nằm hành lang, may mắn mấy ngày sau thì được nâng cấp…thành trải chiếu nằm sàn nhà cùng phòng bệnh nhân.

Đi khám lúc 11h30 trưa? Xin chào bạn, bác sĩ đi nghỉ trưa đến 1h30 chiều. Bệnh nhân ngồi đợi như đang ở… sân bay chờ delay. Rồi mẹ tôi làm mẫu xét nghiệm, đi đúng cả ngày 12 tiếng.

Cái kỳ lạ là, dịch vụ nào “đắt tiền” thì cực kỳ thần tốc. Cần nội soi? Có lịch chiều nay. Cần mổ? Đăng ký đi, mai mổ luôn. Cần trồng răng? Sáng nhổ, mai qua trồng luôn cũng được. Ở Mỹ, phải đợi 3 tháng mới tới lượt bác sĩ xem qua, rồi có khi chờ 6 tháng mới có kế hoạch implant.

4. Thành phố “lên đời” – nhưng bà con cứ thích chen

Dẫu vậy, tôi vẫn thấy vui. Hà Nội bây giờ khác quá – nhà cao tầng mọc lên như nấm, đường sá sáng sủa, ánh đèn lung linh, người người ăn mặc sang hơn, sành điệu hơn. Tối đến khu chung cư của tôi người đông như đi trẩy hội, mọi người chạy chơi khắp sân, nóng mà vẫn cười. Trẻ con tối đến lôi nhau ra sân chơi, cười đùa í ới. Nhìn mà vui.

Ở Mỹ, chỗ tôi ở ban đêm yên tĩnh đến rợn người – kiểu “phim kinh dị sắp chiếu”.

5. Hạnh phúc nhất – là thấy hai anh bạn nhỏ nói “ạ”

Nhưng điều khiến tôi ấm lòng nhất, là hai anh bạn nhỏ nhà tôi – sau vài tuần tắm mưa và nghịch đất – bắt đầu biết nói tiếng Việt rõ hơn. Mới về còn “Hi Dad”, giờ đã biết “Con chào bố ạ”. Nghe chữ “ạ” mà thấy lòng tan chảy. Rồi anh bạn út 4 tuổi thì biết chẹp miệng  “à à, con hiểu rồi ạ” – nghe ra vẻ hiểu tiếng Việt lắm ý. Anh bạn lớn thì rất thích vì được học vẽ, được học tiếng Việt (chả hiểu học đánh vần gì mà cứ cười khanh khách suốt)! Rồi các anh bạn nhỏ được gặp anh chị em họ, được đi chơi khu vui chơi trẻ con, rồi ăn cả món Mỹ (fries, pizza, spaghetti) lẫn món Việt (canh cá, thịt kho, đậu rán) mà kêu ngon lắm, cứ như chưa bao giờ ăn vậy =))

Tôi cười thầm. Không có app nào dạy trẻ tốt hơn là chính quê hương của chúng. Và chẳng cần khóa học “Culture Immersion” nào đắt tiền – chỉ cần một mùa hè Hà Nội.

Về Hà Nội năm nay là một trải nghiệm đa chiều, từ nóng bức đến ấm lòng, từ sốc công nghệ đến sốc văn hóa. Nhưng tất cả đều khiến tôi thấy gần hơn với quê hương, và thấy Việt Nam mình đang đi rất nhanh – chỉ là đôi khi vẫn kịp giữ lại những điều thân thương nhất.

     
Four important people you should have in your life

Four important people you should have in your life

Have you ever noticed how life’s best recipes always involve a diverse set of ingredients? Much like a deliciously layered cake, your life requires a unique blend of people to achieve that perfect balance of sweetness, inspiration, wisdom, and, yes, even the occasional sprinkle of annoying persistence. Let’s break down the four essential types of people you should absolutely, undeniably, no-questions-asked have in your life:

1. The Lover (Your Personal Cheerleader)

This is your spouse, boyfriend, girlfriend, partner—the person who sees you trip over nothing, spill coffee on your shirt, and still thinks you’re the greatest human being alive. They’re your safe haven, your Netflix-and-chill partner, and your personal cheerleader who insists you’re brilliant, even when you forget how to use your microwave. Trust me, everyone deserves someone who loves them unconditionally—even during their “I haven’t showered in two days” phase.

2. The Role Model (Your Personal Hero)

Remember when you were a kid and wanted to be Superman, Wonder Woman, or maybe just the cool cousin who could ride a skateboard? A role model is basically that—but adult version. They’re living proof that the dreams you scribbled in crayon might actually happen (minus the superhero cape, probably). They inspire you to reach higher, work smarter, and occasionally question if sleep is truly necessary when chasing goals. Spoiler alert: it is, but they’re still worth emulating.

3. The Mentor (Your Personal Yoda)

“Do or do not, there is no try.” While this might sound like a cryptic fortune cookie, a mentor is the human embodiment of this wisdom. They’re the person who has navigated the maze of life successfully—or at least pretends convincingly enough. Mentors dispense insights like candy on Halloween, offering you wisdom, guiding you through tough choices, and occasionally reminding you that instant gratification usually comes with long-term regret (looking at you, midnight pizza).

4. The Nagger (Your Personal Drill Sergeant)

Ah, the unsung hero—the nagger. They text you at 6 AM reminding you about your workout goals. They gently (or not so gently) remind you about deadlines, responsibilities, and the broccoli you promised to eat instead of fries. Naggers are like human alarm clocks you can’t snooze. You might grumble, but deep down, you secretly thank them for holding you accountable—right after you’re done complaining, of course.

So, there you have it. Life’s fabulous foursome: the Lover, the Role Model, the Mentor, and the Nagger. Together, they’re like the Avengers of your personal growth journey—each playing their part to ensure you live your best life, or at least one that isn’t embarrassingly mediocre.

Who fills these roles in your life? And more importantly, are you brave enough to tag your Nagger and admit it publicly? Go ahead—I dare you!

P/S: I’m tagging my wife (even though she’ll never read this blog): Annie, you’re my lover, mentor, role-model, and nagger, thank you for being 4-in-1!

     

Drawing Mercedes Logo With a Single Stroke – And Why You Should Not Sleep in Your Maths Class

The fun

It’s the new year. We had the winter break, and what do you do when your kids are at home for two weeks? They get on their iPads and, of course, watch YouTube Kids (Blippi, Bluey, and oh so many more).

But it’s the new year, so I want to change.

I want to find something fun, such as IQ games. Active entertainment (drawing, creating, solving problems) is better for kids than passive entertainment (watching videos).

So, I found an IQ game app.

The first quiz is: “Draw the Mercedes Benz logo with a single stroke”. Basically, without lifting the pen, draw this shape:

The frustration

So I did it for the kids first. Of course, Daddy can do anything, right?

But I failed at first attempt. Oopsie.

I tried.

Again.

And again.

And again.

Still failed. What? I cannot solve an IQ test from a kid app.  I got annoyed.

The solution

I looked closer: it was a graph with nodes (the red dots) and edges (black lines connecting the nodes). If I want to draw it with a single stroke, I have to find a path that visits each edge exactly once.

So it’s a graph problem. Then my foggy memory recalled what I learned in my Math/Computer Science classes 20 years ago: to find an Eulerian Path (a path that visits all edges exactly once) in a graph, the graph must have exactly zero or two “odd” nodes (an odd node is a node with an odd number of edges connected to it). This problem is similar to the Seven Bridges of Konigsberg problem.

The Mercedes Benz is a graph with 4 “odd” nodes, so according to Euler, there is no Eulierian path.

Voila: it is impossible to draw a Mercedes Benz with a single stroke.

Problem solved (kind of :p).

———————————-

Now, I’m faced with a greater challenge—how to explain it to my five-year-old. :p? I’ll tell you in the next post.

 

     
Hacker Laws Every Software Engineer Should Know

Hacker Laws Every Software Engineer Should Know

One AWS senior principal engineer shared this Github repo with us:  https://github.com/dwmkerr/hacker-laws ([PDF], [Podcast]). The compilation of “Hacker Laws” provides essential guidance distilled from decades of experience. Whether you’re designing a distributed system, optimizing performance, or leading a team, these principles offer valuable frameworks for approaching common challenges.

 

It’s a really good read. Here is the quick summary:

1. Amdahl’s Law

This law emphasizes the diminishing returns of parallel processing. While adding processors may improve system performance, the non-parallelizable portion of your program will limit the overall speedup. For engineers, this serves as a reminder to analyze the structure of the tasks before throwing hardware at the problem.

Key takeaway: Focus on optimizing the bottlenecks before investing in parallelization.

2. Brooks’ Law

The more people you add to a late project, the later it becomes. Brooks’ Law is a cautionary principle that illustrates the inefficiencies created by increased communication overhead and the learning curve of new team members.

Key takeaway: Adding more developers to a problem will not necessarily solve it faster; consider smarter resource allocation.

3. The Broken Windows Theory

This theory suggests that minor issues, like bad code quality or technical debt if left unchecked, will accumulate and eventually cause more significant problems. Treat your codebase like an environment—keep it clean to prevent long-term damage.

Key takeaway: Fix minor issues before they snowball into more significant, harder-to-manage problems.

4. CAP Theorem

The CAP theorem states that distributed systems can only guarantee two out of three properties: Consistency, Availability, and Partition Tolerance. This is critical when designing distributed applications, as you must prioritize based on your system’s needs.

Key takeaway: Understand the trade-offs in distributed systems and decide which aspects are most critical for your use case.

5. Conway’s Law

Organizations design systems that mirror their communication structures. If your company is divided into isolated teams, expect your systems to reflect this disjointed structure.

Key takeaway: Foster inter-team communication to build cohesive and unified system architectures.

6. The Pareto Principle (80/20 Rule)

In software development, 80% of the consequences come from 20% of the causes. The most critical features or bugs are often concentrated in a small portion of the codebase.

Key takeaway: Focus on the 20% of the work that drives 80% of the results—whether it’s features, bugs, or performance issues.

7. KISS (Keep It Simple, Stupid)

KISS advocates simplicity in design. Overcomplicating solutions makes them harder to maintain and scale. Always aim to solve problems with as little complexity as possible.

Key takeaway: Complexity is the enemy of reliability—choose simple, elegant solutions whenever possible.

8. YAGNI (You Aren’t Gonna Need It)

A principle from Extreme Programming, YAGNI advises against implementing features until necessary. Prematurely coding features that might never be used wastes time and resources.

Key takeaway: Build only what you need today, not what you anticipate needing tomorrow.

9. Linus’s Law

This law states, “Given enough eyeballs, all bugs are shallow.” In an open-source or collaborative environment, the more people reviewing the code, the easier it becomes to identify and fix bugs.

Key takeaway: Encourage code reviews and collaboration to uncover issues early.

10. The Law of Leaky Abstractions

Abstractions are necessary to simplify complexity, but every abstraction leaks some underlying complexity at critical moments. Engineers must be cautious about over-relying on abstractions without understanding the systems beneath them.

Key takeaway: Learn the inner workings of your abstractions so you’re prepared when things go wrong.

Final Thoughts: Understanding and applying these laws can elevate your engineering practices. They provide a lens through which to evaluate your design choices, team dynamics, and problem-solving approach. As the software development landscape evolves, these timeless principles remain crucial for success.

     

What make a great contractor, or the story of how I learn to spot an A player

The fastest and cheapest ain’t always the best

Disappointed Cricket Fan Meme" Sticker for Sale by simcass | Redbubble

So, back in December last year, I wanted to choose contractors to renovate my kitchen. I had a lot of bidders and ended up with the earliest – basically, to avoid decision fatigue. Let’s call him Joe.

Joe was responsive initially, offered me the most affordable price, and got back to me very fast.

I was hooked.

Little did I know that being consistent and predictable sets A+ contractors apart.

Two weeks into the project, he decided to disappear for two days. No text. No call. No nothing.

Communication blackout.

He promised to finish the project before Christmas – and as of now, near the end of January, we’re still living without a kitchen.

I regretted hiring him.

The most consistent and predictable player, win.

The Best Handyman Near Me

Enter the story about Jim.

Jim is another contractor I liked and helped me with various projects around the house: bookshelves, closets, you-named-it.

Was he the first? No.

Was he the cheapest? Not likely.

Was he the most consistent and predictable? Boy, oh boy, yes, absolutely yes.

Jim said he’ll be there at 9 am to start working. At 8.55 am, the bell rang, and he was there.

Jim would work continuously for 12 hours to complete the project on time. He told me it would take this much time up front, and he was right to a quarter of the hour. He communicated frequently with me about the progress and consulted me when anything was off.

He delivered the work beautifully.

I’d gladly hire Jim again for any future project. Not Joe.

——–

That’s the consistency and predictability that set A player apart: being the fastest or cheapest might only get you going. You need to be consistent and predictable to win and deliver amazing results.

That’s it. Now is my time to return to my kitchen.

 

     

On Amazon cultures and practices

I joined AWS a while back as an engineering manager. I had fantastic opportunities to learn from Amazon’s unique culture and wanted to write something about it. My first attempt is to share some of the Amazon culture from my onboarding.

  1. Customer Obsession

Every company on earth will say that.

Everyone will say that the customer is central to everything we do.

But Amazon stands out by embedding this leadership principle into everyday work: Want to make a product proposal? Write a PRFAQ, like a press release, describing how customers will use and benefit from this product when it’s released.

In another aspect, I remembered this scenario during my manager onboarding :

What amount can an AWS customer claim back from a $16,700 accidental bill?

a) 50%

b) 65%

c) 80%

d) 100%”

This is a real-life example.  Ans: You got the correct answer, didn’t you? It’s d) – 100%!

  1. Dive Deep

Amazonians circulate this serious joke: “In God we trust; everyone else brings data.” Not that we don’t trust each other, but we value facts as much as beliefs.

One outstanding example is the COE (Correct of Error) review: We list a detailed timeline, the actions we took, and the impact we observed. We ask ourselves five Whys, peeling layers of the onion until we can find the root cause. More often than not, the root cause and the best solution are not trivial, but the effort is worth it.

Here is one example of the importance of asking 5 Whys:

Problem: The Abraham Lincoln monument in Washington, D.C., is deteriorating.

Why #1 – Why is the monument deteriorating?  

    • Because harsh chemicals are frequently used to clean the monument.

Why #2 – Why are harsh chemicals needed?

    • To clean off the large number of bird droppings on the monument.

Why #3 – Why are there many bird droppings on the monument?

    • Because the large population of spiders in and around the monument are a food source for the local birds

Why #4 – Why is there a large population of spiders in and around the monument?

    • Because vast swarms of insects, on which the spiders feed, are drawn to the monument at dusk.

Why #5 – Why are swarms of insects drawn to the monument at dusk?

    • Because the lighting of the monument in the evening attracts the local insects.

The best solution is to change how the monument is illuminated in the evening to prevent the attraction of swarming insects.

3. Peculiarity 

Yes, you read it right. Amazon values peculiarity—doing things differently, sometimes strangely. Amazonians are proud to be different and do things uniquely.

Ever go to large meetings and nod off? Amazonian fixed that with a brilliant, simple idea: use a spin wheel in the meeting to randomly pick one of the audience members to participate. Everyone suddenly stays engaged!

Are you going to a review and unsure what everyone is talking about? Amazonians counter that by spending silent time at the beginning of a meeting to read the materials.

These are indeed peculiar practices. And they work beautifully!

That’s a wrap for now. As I learn more from my journey, I’d love to share more cultural practices.

 

 

     
Leading Through Uncertainty Time

Leading Through Uncertainty Time

This came in my mailbox from Harvard Business Review. It resonated greatly with my current context: dealing with new scopes, zooming in on net new focuses, and tackling greater challenges.

Sharing it here as a way to remind my future self. You can read the whole article on HBR here.

Facing Uncertainty – It’s All About Mindset
Uncertainty is unavoidable. As a manager, you need to be prepared to lead your team through murky waters, but doing so requires getting in the right mindset yourself. Here are six tips to help you shift your perspective:

1. Embrace the discomfort of not knowing. Move from a know-it-all to a learn-it-all mindset. You don’t need to have all the answers.

2. Distinguish between “complicated” and “complex” issues. They require different solutions.

3. Let go of perfectionism. Instead, aim for progress, expect mistakes, and recognize that you have the ability to continually course correct as needed.

4. Resist the urge to oversimplify and come to quick conclusions. Take a disciplined approach to understand both the complexity of the situation and your own biases.

5. Don’t go it alone. Connect with your peers who have their own set of experiences and perspectives to draw from.

6. Zoom out. Taking a broad, systemic view of the issues at hand can reveal unexamined assumptions that would otherwise be invisible
     

12 factors of modern SaaS

TL;DR: it’s a guide with best practices for any engineer who builds & deploys SaaS, based on experience working and scaling many apps on Heroku platform.

Introduction

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language and use any backing services (database, queue, memory cache, etc.).

I. Codebase

One codebase tracked in revision control, many deploys. One app, one codebase. Each component maps to one app (or service) in a distributed system.

One codebase maps to many deploys

II. Dependencies

Explicitly declare and isolate dependencies. Never depends on implicit system-wide packages. Declare all dependencies completely and exactly. Use a dependency isolation tool (virtualenv for Python) to prevent leaks or dirty dependencies.

III. Config

Store config in the environment. Dev, staging, production environment should have different configs. Separate config from code.

IV. Backing services

Treat backing services as attached resources, i.e., local and third-party services can be used interchangeably. Resources can be attached/detached at will.

A production deploy attached to four backing services.

V. Build, release, run

Strictly separate build and run stages. Restrict changes to the code at runtime.

Code becomes a build, which is combined with config to create a release.

VI. Processes

Execute the app as one or more stateless processes. Processes are stateless and share-nothing. This will allow the app to scale horizontally. Any data that needs to persist must be stored in a stateful backing service, typically a database.

VII. Port binding

Export services via port binding. The app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port and listening to requests coming in on that port.

VIII. Concurrency

Scale-out via the process model. In the twelve-factor app, processes are a first-class citizen. Processes in the twelve-factor app take strong cues from the Unix process model for running service daemons. Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to a process type. For example, HTTP requests may be handled by a web process, and a worker process handles long-running background tasks.

Scale is expressed as running processes, workload diversity is expressed as process types.

IX. Disposability

Maximize robustness with fast startup and graceful shutdown. App processes are disposable and can be spun up / spun down easily. App on shutdown should exit gracefully, such as returning job to the queue or closing existing connections upon receiving SIGNTERM.

X. Dev/prod parity

Keep development, staging, and production as similar as possible.

XI. Logs

Treat logs as event streams. The app never concerns itself with routing or storage of its output stream. On localhost, it can be just stdout. On a production system, the streams are captured by a log system.

XII. Admin processes

Run admin/management tasks as one-off processes.

One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.

 

Credit:https://12factor.net/

     

Interviewing tips for interviewers

As a manager, one of the most important tasks is to hire the right talent for the team.

Well, it might be the most important one.

Yet almost everyone dreads interviewing.

How can we avoid asking the type of “tell me about yourself” question out of habit? Or how we can get to the real point instead of asking “tell me about a time you struggle”?

Well, after having two coaches, being mentored by 4 industry veterans, 15 years in this industry, conducting over 110 interviews, I had a few tips for effective interviewing to share.

Technical screening round

The goal of the screening interview round is to ensure we have the right candidate when it comes to onsite interview rounds. The screening interviewer should filter out unqualified candidates as soon as possible. Your time is valuable, and so is everyone on your team.

With that, here are things you should do:

  • Do the homework:
    • Research candidate before the interview: use your 360-degree lens, dig in LinkedIn, scan the CV to find patterns: is she a fast learner? Is she pushing her out of her comfort zone? Was she a team player or a solo? See if she can show her potential to grow in this position. Don’t ask superficial questions such as “tell me about yourself”.
  • Go hard on the technical side with a nice tone:
    • Don’t settle on easy questions. It won’t help. Remember: “A player attracts A player, B player attracts B, C, and even F player”.
    • Push the candidate until she said, “I don’t know”. Great people know their limits, they don’t try to show that they know everything. You need to push to see what her boundaries are to set her up for success if you hire her.
    • Don’t stop at the first solution:  A solid candidate always tries to improve, even if she found a solution. She would find a working solution, lean on that, improve for certain dimensions. Need to trade memory for speed? Or readability over coding speed? Ask the candidate if the algorithm can be further optimized in terms of time & memory usage? Will that work with +100 million items, or with just 1MB of RAM?
    • Provide assistance and support when the candidate is stuck. Give reasonable hints, coachable talents pick up hints very fast.
  • Be open-minded and look for room for improvements
    • A phone interview is not easy for both sides, if the candidate has trouble understanding, offer help. The goal of the screening interview is to measure candidate problem-solving and communication skills.
  • Make it an open conversation: 
    • The interview doesn’t have to be one-way, and ideally, it should be like an intellectual conversation so give open suggestions, listen and give feedback appropriately.  Don’t impose your opinions and knowledge on the answer: if the candidate chooses Python even though we code in .NET / JavaScript, that’s fine. As long as she demonstrates solid data structure and algorithm expertise, the choice of language and style differences can be ignored.
  • How to start a Problem Solving challenge:
    • Start by asking what’s the general algorithm? Does it “sound” like a solution, is it working?
    • Start to draft an optimal algorithm then proceed to implement

Onsite interview round

Firstly, the onsite round is to ensure the candidate will be a good culture fit, with solid communication skills. Secondly, it is to have a broader assessment of the technical skills. It is also about presenting our team, our culture, our people. It is to find a colleague that we’d love to work with on a daily basis.

Onsite interviewing is a chance to leave good impressions on the candidate so that even if she won’t get the job, she will be an ambassador for us. Remember interviewing works both ways: candidates evaluate interviewers at the same time so find your way to create an uplifting experience.

  • Sync up beforehand:
    • Discuss with the hiring committee the type of questions and topics which each interviewer will cover.
    • Try not to have multiple interviewers interviewing on the same topic – unless it is critical for the job. Your hiring committee should be representative so that each person can probe the candidate on a dimension.
  • Ask open-ended questions: 
    • Ask a problem that has multiple solutions so that we can see how the candidate handles ambiguity and unknowns.
    • Aim for the problem that the candidate never solved before but can be solved with additional data and help.
  • Separate well-practiced answers from real ones:
    • 5-whys: keep asking why. A great answer is one that can go deep through multiple layers of that onion.  Sometimes, great people will throw their hands in the air and say “I don’t know why”, but by then you would have enough data to consider.
  • Share feedback as soon as possible: 
    • Ideally, once the hiring committee finishes interviewing, everyone should meet and provide feedback when the memory is still fresh. Every hour passing by, the quality of the feedback degrades.
    • The trick to avoiding herd mentality is to have everyone put down their vote before they meet: it’s either Yes or No – do not accept Maybe! If one needs to switch the vote, there must be really strong reasons.
  • Be professional, move quick
    • In case the hiring committee cannot meet soon, keep the candidate posted about when she can expect the output. If the team can meet and agree this is the right talent, make a case with your decision-makers.

Well, thank you for reading this far.

This post is by no means a complete list, it rather serves as a starting point and hopes it spark your interest in interviewing. And the Aha! feeling when you find that great talent? It’s totally worth it!

Have other opinions? I’d love to hear from you in the comment section.