As hiring managers, we may have questions about what to do if the interview candidate uses AI. Is it ethical? Should it be allowed? What does it say about the quality of the candidate?

In my current view (as of writing), AI is a tool. If you allow using other tools in your interview loop and the usage of those tools does not raise concerns about candidates' ability to perform the job, then AI should be allowed, and in fact encouraged, and made part of the interview loop.

What are some other tools we use in Interview today? Code collaborators, IDEs, syntax/regex checker, formatting, etc. So why not Ai?

Some may say that AI can actually give the answer, but other tools can't.

That's a fair point. But this means that we need to change the interview format and how interviews are conducted in the world of AI rather than blocking AI.

How do we conduct interviews in the world of AI?

One way to think about this is to merge coding and system design into a single interview. At the end of the day, in technical interviews, we are trying to figure out if the candidate can build a system that solves our business problem and code it up. Today, we do that in two separate interviews; with AI, we can do it in one. Here's how.

Instead of asking someone to share how they would code up a binary tree or design an automated cron system on a whiteboard, we ask them to build the live working app.

Imagine this new interview format.

"Hey, candidate. Welcome to the Interview. We have 1 hour. I want you to build a working and live website to collect leads for an event that signups drivers for Lyft. You can use whatever AI tools you want, such as Replit, Cursor, ChatGPT, Claude, etc., and use whatever language you want. We want to understand how you can quickly go from problem to prototype solution. In the end, we will review the design together, understand the tradeoffs you made, your understanding of code that your collaborator Ai wrote, and the system you built."

As a hiring manager, this will give you far better signals in far less time on the candidates' ability to:

• If they know and can use AI in their workflow because that's what your company is using.

• How they think about system design as thats what their prompts will be.

• How do they debug the issue when Ai doesn't do what they expect it to do?

• Can they explain what AI did at a high level?

• Do they understand the end-to-end lifecycle of what it takes to ship a product?

• Based on questions they asked about the system, were they able to reduce the problem's scope to complete the project in 1 hour?

• How close did they get to shipping the app?

• Where do they think the current system bottlenecks are?

• How would they change the design if this were across US and international markets?

• Did they think about observability (as in, did they ask the AI in the prompt?)

• And so much more

In my view, companies and hiring managers are needlessly worrying if AI is breaking the interview process. We all know that the interview process is NOT perfect. We need to update it.

I personally would like to spend more time understanding whether candidates are a culture fit, how they think about their growth, why they believe this company is the right company to support them in their career, etc., and less time identifying whether they can code and build systems.

Yes, being able to code and build systems is a critical part of software engineering. However, I have never managed an IC because they could not code or build systems. However, I have managed ICs/EMs that were not a cultural/team/org/company fit.

If this was helpful, I'm happy to chat about what other people think on this topic.

• Don't do interviews. Do discussions.

Subscribe now

We have an illusion of multi-cloud providers. From the customer's point of view, there is only one cloud. When it's down, there is a disruption of service. CrowdStrike (July 2024) is a perfect example; there will be many more. CrowdStrike outage impacted Microsoft, which impacted businesses that had Microsoft cloud exposure.

Subscribe now

Software companies have combined in-house tech with external SaaS providers for the last decade.

When deploying in-house tech, companies can pick their favorite cloud provider from 13 prominent cloud providers available to deploy their applications. 

However, the moment a company buys a SaaS service, it becomes exposed to the risks associated with the cloud provider on which the SaaS service runs.

Today, building any application requires integrating multiple SaaS applications. For example, an AI startup today will use Google Suite for business, Zoom for Meetings, AWS for deploying applications, OpenAI for LLMs, and Stripe for billing. This is a lean stack, but now the AI startup is exposed to GCloud, AWS, Azure, and OCI.

For the customer of AI Startup, they can expect an outage if any one of these cloud providers goes down. So, from the customer's point of view, there is a cloud outage, and it doesn't matter which cloud provider has it.

Now, an engineering solution to this is to do a multi-cloud strategy. This sounds good on paper, but unless you decide to build every SaaS service in-house and then deploy them on multi-cloud for redundancy, it won't work. And even if it did, the cost will eat your business alive.

In reality, 99.9% of startups, small, mid-size, and some large companies don't have the option of using a multi-cloud. It's just an illusion.

Can you build an application that is multi-cloud and resilient?

It's hard and honestly an overkill for most applications. 

All cloud providers have exceptional SLAs, and outages like this are far apart and few enough to justify any multi-cloud strategy.

There are exceptions to the above. Any life-critical tech deployed in hospitals, airplanes, etc., must have a proper multi-cloud strategy. And in those cases, the cost is worth it.

While I haven't had an opportunity to work on such critical projects yet, I designed a resilient multi-cloud strategy as a thought exercise. Maybe I will write a post about it someday. Please reach out if you have done so or would like to exchange notes.

The reason for writing this post is to remind us that we live in a connected world. In the future, if you are designing cloud applications with a multi-cloud strategy, be aware that it may be overkill and not serve its purpose, as there is only one cloud as far as the customer is concerned.

If you find this post interesting, you may be interested in others posts:

• Build vs Buy: One Aspect That No One Talks About

• Build Vs. Buy: Vendor Contract Shenanigans

• Ensuring Vendor QoS & Setting the Right Type of SLAs When Buying Service From a Vendor

Subscribe now

In the US, every leader has an open-door policy, i.e., come anytime and ask any questions. Open-door policies are meant to encourage openness and transparency for the employees. While the idea is excellent, it only sometimes works, especially for immigrant individuals. Let's understand why and how to fix it.

For an individual to take advantage of an open-door policy, two things have to be true:

• They must have enough self-confidence, &

• They must feel psychologically safe.

  Thanks for reading Thinking Through! Subscribe for free to receive new posts and support my work.

Most immigrants lack self-confidence when they first enter new workspace. The language and work environment is new. Understanding cultural nuances also takes time.

Over time, people build enough self-confidence. But that's only half the battle.

The other significant aspect of the open-door policy is psychological safety. This is something that the employee doesn't control. It's up to the organization's leaders to create a psychologically safe environment for everyone on the team. It's essential when the team has diverse employees of different nationalities.

IMO, leaders must go the extra mile to make the team feel psychologically safe.

However, and this may come as a surprise, but many immigrant employees don't know what psychological safety is. Many have not experienced it in their country of origin. Some didn't experience it at home. And it may be worse for females and LGBTQ+.

So, before discussing how to create a psychologically safe environment for teams, let's consider its definition.

What is Psychological safety?

That's a fantastic definition.

As an immigrant myself, I remember when I first experienced psychological safety, it seemed so foreign and new. Yet, it felt great. 

But feeling psychologically safe is not a one-time thing. You have experienced it consistently. Over time, you develop the sense of belonging. And once you have enough self-confidence, you get a individuals that can take advantage of the open-door policy.

How do we build psychological safe environment?

Many books have been written on the topic of psychological safety. I won’t attempt to summarize them here.

However, I will share how I practice creating a psychologically safe environment for my team members.

• Be candid.

• Share your true self.

• Share your mistakes and what you've learned from them.

• If someone makes a mistake, don't seclude or isolate them. Use inclusive language and share the ownership of the mistake.

• Encourage each team member to share their input.

• Help them grow and teach them the ropes.

And, practice these everyday.

It's amazing what people bring to the table when they feel they belong. Remember, great leaders build great companies, that build great products and that requires great people. The character of a product is the summation of the characters of the people who built it. Inclusive people build inclusive products. And inclusive products are what this world need.

Couple psychological safety with confidence and you get a fantastic team that can scale any mountain and run through any wall together. And in the meantime, they will use your open-door policy to tell how we should succeed next and what problems we should solve.

Till next post, happy building great and inclusive teams!

Many managers need help with delegation. That's because delegation is a complex skill, but like any skill, we can learn and master it. And this post is going to explain how.

Delegation is tricky because it seems simple, but if done incorrectly, it can severely impact the delegated task, the delegatee (who gets the task), and the delegator (who delegates the task).

Over the years, I have encountered, debugged, and solved many delegation problems for myself and my team of managers/individual contributors.

Based on the insight so far, I feel confident in categorizing all delegation-related problems into the following 3 categories:

• Delegating too little

• Delegating too much

• Delegating to incorrect team member

Isn’t it simple? And that's the trap, the bad news.

The good news is that all three can be corrected, starting with coaching/mentoring the delegator.

The first two problems are easy to identify and fix. In fact, most new managers can self-diagnose them. The third one is the complicated one. It's a mix of art and science.

So, let's look at each of them closely and understand why they occur and how to self-identify and correct them.

Subscribe now

Delegating Too Little

New managers are often the ones who need to delegate more. If you are one and feel like you delegate too little, don't worry. Your leadership expected it. This is a new skill that all new managers have to develop. This is not the worst place to be in.

Why it occurs:

The most common reasons are:

• Small team size (less than 4 reports) so manager feels like they are helping the team by not overloading them.

• Manager switching from individual contributor to new manager role. In previous role, the task ownership solely relied on them as individual contributors. Rarely they had to delegate, and even then, very little. It's a continuation of a behavior that has to be unlearned.

• Lack of trust in the team to deliver at the same high level.

How to (self-)diagnose:

As a manager (delegator):

• You feel overwhelmed all the time.

• You and your team members feel the team skills could be utilized more.

• Things pile up on your plate, and working long hours doesn't lessen the load.

Managers can usually self-diagnose this when team size grows beyond 4-5 team members or after feeling overwhelmed for a long enough time. That's when things become unsustainable, and delegation becomes critical.

If you are managing a manager who is delegated too little, wait a few months. Give them the opportunity to self-diagnose, but do drop hints here and there.

How to correct it:

• Develop trust in the team's ability to deliver.

• Delegate small tasks. Start with delegating the tasks that you (as a manager) can do with your eyes closed. This makes it easier to set expectations and monitor the progress/quality of the work.

• Delegate consciously and intentionally.

Be patient and rise and repeat. Always remember that delegation is a skill you are trying to get good at.

Delegating Too Much

In this case, the pendulum swings in the other direction. The manager delegates almost everything, including project tracking and team scope expansion.

This is the worst-case. It's almost equivalent to not having a manager.

Why it occurs:

The most common reasons are:

• The manager is burned out/doesn't care.

• The team scope of ownership is significantly smaller than the team size.

• The manager leaves the team or the team moves to a manager who has yet to learn what the team does.

How to (self-)diagnose:

• The team feels overwhelmed and overworked.

• The team needs more direction, i.e., what to do next, the priority of the current task, and why.

• As a manager, you feel replaceable, or as a manager of manager, you ask, " "What is that manager doing?"

This is more common in big organizations. Not surprisingly, these managers were impacted during the recent layoff cycles when companies decided to reduce the hierarchy, a.k.a. cut the fat.

How to correct it:

• Be more involved.

• Take back work, especially that is around project tracking and stakeholder discussions.

• If you are burnt out, leave the role.

Finally, let's look at the most complex category.

Delegating to the incorrect team member

This is most complex because it's a mix of art and science.

To delegate effectively, we need to understand the complexity of the task and match it with the right delegate who has 70-80 percent of the skills needed to get the task done. The remaining skills are what they will learn when they do the task.

And this is why it's a mix of art & science. The art part is identifying the right delegate, and the science part is knowing the complexity of the task.

It takes a lot of work to get this exactly right all the time. And honestly, we don't need to.

Why it occurs:

• The manager needs to gain the skill to estimate the delegated task complexity.

• The manager needs to gain knowledge of delegate skills and the skill gap.

• Managers are delegating something that they don't understand.

How to (self-)diagnose:

• Task making no progress.

• The delegate seems to need help with tasks, making incorrect or insufficient progress and has no idea why.

• Delegates are unaware that they own it.

How to solve it:

• Learn the necessary skills to understand the task and team.

• Coach the delegatee:

  • When the complexity of the task is more than anticipated, which results in a more significant skill gap, help them break it down to the right level so it matches 70-80 percent.

  • When the task complexity is less, change other dimensions, such as pulling in the timeline, adding more use cases, or simply delegating some more tasks.

• Make it clear and explicit to the delegate that this task is their responsibility.

As I mentioned above, getting this exactly right can always be challenging. The goal is to be something other than an exceptional delegator. The goal is to:

• Make progress on the task and deliver impact for the organization.

• Grow the skills of the delegate.

• Grow yourself in the role by delivering more with the team's help.

If you find this insightful, please consider subscribing. If you have a delegation story or a problem, feel free to share that in comments.

When working on a project, you must create one file before doing anything else, even before you compile the boilerplate code for the first time. That single file could help you ship your project. It’s been a lifesaver for me. That file is called  changelog.txt. And here's why you should create one now.

Building projects is hard. Even MVP or POC can take weeks to months. And that's the best case, assuming you don't get demotivated, have another idea, or end in a perfection loop of building all features before shipping it.

During the early phase of the project, there is no progress to show. Nothing has shipped and it can feel demotivating. So much so that after the initial excitement of the building a project wean off, the motivation to grind on the project to get to a shippable state is sometimes impossible to find.

That's where changelog can help.

Starting from day 1 of the project, write what you completed that day in the changelog file. Here is a sample of how my project changelog file looks like:

changelog.txt
--------------------------------
2023.1.22 - Changing timer class to handle timer issue better and keeping it siloed
2023.1.20 - Started debugging the stupid countdown timer issue that was getting reset
2023.1.15 - Configured CoreData and CloudKit
2023.1.14 - Added the registration logic and login screen
2023.1.12 - Completed the first load screen and design.
2023.1.11 - Created the main view and list of skeleton views of app
2023.1.10 - Setup the project and swift environment

While I may not be shipping stuff for a while, I do make progress. Keeping changelog helps visualize that saves me from falling off the rails when project is in lull. Every day, when I update the changelog, I see progress.

Now, before you say, "use git. It acts as a changelog", let me say, "you are right." While Git works for software projects, changelog works for all types of projects like woodworking, art, content creation, etc. Think changelog as a system to track and visialise progress.

Moreover, even for software projects, a local changelog file is faster than scrolling Git commit history.

Another thing to note is that this local project changelog file is private. The changelog we see on SaaS products or apps, is written by a technical writer and is very polished.

The changelog.txt I am talking about is raw and for personal use only. As you can see above.

Finally, if multiple people are working on the same project, find a way to identify each one contribution uniquely. In the past, I have used my initials [MV] as prefixes/suffixes.

Bonus Tip:

Once you are done writing the day's progress in the changelog, write the next task you want to complete on the top. The changelog can double up as mini-todo list as well and can help you get in the zone fast.

Next time you come to the project, you don't have to think about what to do next. Here is a sample

changelog.txt
--------------------------------
next - Create a background thread to continue running counter

2023.1.22 - Changing timer class to handle timer issue better and keeping it siloed
...
...

Caution: Don't add a laundry list of everything you need to do on top of the changelog file. Only add 1 or 2 immediate next tasks. Adding too many tasks will defeat the purpose of the changelog file (see the progress so far) and make it into all things you are yet to complete.

If you need to create a to-do list of all tasks, create another file, todo.txt, and add them there.

I hope this helps. Happy building!!

I love building stuff, especially side projects. But we live in a world where every side project must or should have the potential to be converted into a startup. I don’t buy that notion. I argue that because of this expectation, we, as a community, are building far fewer side projects (that are not startups) than we should.

In the last post, I presented an idea that 99.999% of our ideas are side-project ideas and not startup ideas, but we should still build them. The collective feedback I received was, why bother building them at all? I guess, the sole reason presented, “Just for the fun of it,” seemed too abstract. So here are my other reasons why we should build more side-projects:

• Solve your repeatable problem fast: Small recurring problems can be solved with some bash, TCL, or python scrapped together in an hour1, for yourself. I say “for yourself” because the initial version of the project will be gnarly, and only you can understand them. That’s not something you can distribute to others. But it will solve the problem FAST.

  

• Learn a new language: People often ask where I get time to learn new programming languages/tech. I tell them, not at work. Today, choosing boring technology is the mantra for building reliable software at big companies. The opportunity to explore new programming languages or tech can come from side projects. If you are not strapped for time but have a idea for side-project, try solving it with a new language. I have built a calculator in Swift because I wanted to learn Swift and macOS app development.

  

• Save money: If you like software/tools you want to use, but they are paid, build your own. It’s going to be free, and you’ll love it. Why pay for a subscription or an annual license2? Bonus, you can build features you like and skip the bells and whistles.

  

• Miscellaneous: Side projects boost creativity, act as proof of work, make you better at your current job if you use the same stack, and even boost your GitHub followers. If they motivate you, use them.

• And, my favorite, Just for the fun of it!: As I said, I love building them. They are fun (for me) and scratch my creative itch. Following gif perfectly captures how I feel if my side-project was a duckling.

  

And that’s all. It’s simple. Have fun building.