Easo Thomas Easo Thomas Website

What are the key differences between a Username Password Login and JWT?

30 Apr 2025

One of the interview questions recently was about the differences between a username/password and a JWT token. Even though I answered it correctly and to the interviewer’s satisfaction, I thought to research it further and give myself some more knowledge on the topic.

These are my notes for my own reference. Read some reference documentation for more accurate and up-to-date details.

In case of Username/Password:

  • Key difference is in the way the authentication and authorization is handled.
  • Username/password has to be checked against a secure vault or a database entry - involves a serverside call
  • Once authenticated, a session has to be created and maintained. A session means a state is maintained and passed with every call. Think of Session ID in a cookie passed in each request.
  • The user who was authenticated, has to be now Authorized (on what permissions he has to access what resources). This involves more server side calls.
  • In a microservice architecture, these server calls have to be repeated for all microservices.

JWT avoids all of these issues.

In case of JWT:

  • The user provides their credentials (username and password again) to the server. The first call to the server.
  • Sever checks the validity of the credentials and if valid, issues a JWT token to the user
  • User stores the JWT in the code/local storage or if it is a UI, it will be stored in a cookie in the browser.
  • For every subsequent requests made by the client/browser/Postman/code, an “Authorization” token has to be included which contains the JWT token as the value
  • Server validates the JWT token for every request (signature and expiration) to verify the user’s identity
  • No session of any kind is maintained (hence session stickyness cannot be applied). Also as the token is stateless, any server can serve the request without knowing any prior context about the user.

Advantages of JWT

  • Scalability - No need to store cookies/session information. It will be in the JWT token
  • Stateless - No need to maintain state information
  • Security - JWT token can be signed with a secret key.
  • Fine Grained Control - For knowing what the user can access, user roles and permissions
  • Reduced Server Load - Multiple requests are avoided which checks for authentication and authorization.

Why use JWT if that also involves a username and password?

This has one of the best explanations in this stack overflow post’s accepted answer. Reproduced her for brevity

Suppose there are 2 servers: TRUSTED (e.g Google) and UNTRUSTED (any site that allows ‘Sign in with Google’). I don’t want to send my TRUSTED username and password to UNTRUSTED. I also don’t want to make a separate username and password for UNTRUSTED. So instead I get TRUSTED to authenticate me, and send a signed JWT containing my identity to UNTRUSTED to prove who I am. UNTRUSTED can check if the JWT is really from TRUSTED by verifying the JWT signature using TRUSTED’s public key (if the signing algorithm uses public/private keys, e.g. RS256). JWTs can be stolen in transit, as can usernames and passwords, so this is a real risk (although, as you mentioned, JWTs will expire sooner). HTTPS will minimize the risk by encrypting data in transit. Another major benefit of using JWTs is that verifying a signature is often faster than checking an access token against a database.

https://security.stackexchange.com/a/191897


Followup questions include:

  • How to sign a JWT token using a secret key

References from Internet (not in any order)

  • https://security.stackexchange.com/a/191897
  • https://www.freecodecamp.org/news/how-to-sign-and-validate-json-web-tokens/



Fully written by Easo Thomas, 10% helped by AI tools. SOF link by Google search

Code Review Guidelines

30 Apr 2025

I was recently reading something about code review, and I got some gems from online. Thought of writing my notes and also add those links here for future reference.

🎯 Code Review Guidelines/thoughts to follow

It is better you go through the reference material at the end of this post. But I will put here what I learnt about reviews and what I would look for.

Terms

  • CL: Change List: A self contained change that has been submitted to VCS (see the term definition below), and is made available for reviewers to review. In different companies, these are called PR, Change, Diff, Patch etc.

  • VCS: Version Control System. A locally hosted or cloud hosted code repository. Bitbucket, Github are all good examples of a cloud hosted VCS

  • LGTM: Looks Good To Me. A comment which is prefixed with LGTM is approved by the reviewer and can go to Production as is. In different companies, this has different meanings. For eg. in Meta, this doesn’t mean ready to deploy or ready to go to Prod yet. Also, depends on who/what capacity the reviewer is.

  • Nit: Nit-Picking. Something that is not urgent or important to fix, but to remind the developer to take care of it next time. Again, this means different things in different companies

Code Review Guidelines & Motivations

Below checklist is in random order of my learning. Use the references below for a perfect read

  • Code should be well designed, easy to read and understand
  • Check if the code meets all or some parts of the requirements. Depends on if it is a full-commit or a partial commit of a big change
  • Check for any logic errors, missing best practices or incorrect behavior
  • Check for missing Test Cases, Edge Cases, Security Scan reports, Vulnerability Scan Reports, Code Style report and any AI based code review comments (eg. Github Copilot)
  • Review 200 to 400 lines of code in one sitting. More than that will cause fatigue
  • Always have the ticket/task in front of you for the code you are reviewing for

Code Level Deep Dive Review I used to do

  • Alert when loop inside a loop is coded, Expensive operations inside a loop, multiple method calls in loop, multiple exceptions coming out of a loop etc.
  • Unnecessary Exception throwing or handling
  • Multiple logging statements (may have been put at the time of coding/debugging). Opposite of this is also to be checked - inefficient logging. There should be at least two lines of logs - whats coming in, and what goes out of a method.
  • Excessive allocations of objects. In java, see how many “new” are being called
  • inefficient string concatenations. Overloaded + operator is dangerous in String operation, especially in a loop
  • Code duplication. Check those SonarQube reports

References from Internet (not in any order)

  • https://google.github.io/eng-practices/review/reviewer/
  • https://google.github.io/eng-practices/
  • https://gist.github.com/thcipriani/8dbce9b755c1d74617de34a153c2ecae
  • https://www.reddit.com/r/learnprogramming/comments/n84xru/how_do_you_do_an_actual_code_review/

Fully written by Easo Thomas, 0% helped by AI tools. Reference links are a result of Google Search.

Principal Architect Interview Questions

25 Apr 2025

I was recently in the job market for a senior role, and one of the titles I was chasing was Technical Architect/Principal Architect. I chanced to see this image in Linkedin, and I thought I would go in detail on how would I prepare and explain the scenarios mentioned in this image below.

Image

🎯 Principal Architect Interview Preparation Guide

Personal Introductions & Motivations

Be prepared to answer this part very clearly and succintly. This would be the first 15 seconds the Chief Architect is making an impression on you. Use it wisely.

Also, you need to be a good STORY TELLER. If you are not practice it. Go out to a local fast food restaurant, look at the people coming in and going out and explain it to yourself on your selfie camera and record it on what you saw in the last 15 minutes - in 3 minutes.

Prepare short crisp answers which ranges approx. 2–3 minutes each. If you keep on talking, pause between each and mention you are going to explain the next area. This way, the Chief Architect can interrupt you if they want and take you to another direction or ask a question in between. If the chief architect takes lead, just follow along.

  • Your Career Story: A 3-minute “career walk” that covers major roles, key projects, technologies, and growth into architecture.
  • Motivation for the Role: Why you think you need this role? Your focus should be on scale, impact, architectural leadership, cross-domain influence, or maturing architecture culture.
  • What You Seek in the New Role: For example, “I’m looking for an opportunity where architecture is valued at a strategic level, and where I can influence technical and cultural excellence across domains.”

Team Structure & Maturity (Chief Architect Context)

Be ready to discuss:

  • Experience with hybrid architecture models Explain how you worked with core Enterprise Architecture (EA) team + other embedded architects.
  • Helping teams mature Explain how you brought in architectural practices or how ARB (Architecture Review Board) discussed architectures for various teams.
  • How you contributed to cultural and technical change, What was your role and contribution to everything above. Focus on all areas, not just technical architecture.

Architecture Challenges

The Chief Architect mentioned fragmentation and gaps between business and architecture. Prepare to discuss:

  • How you unified fragmented teams. Explain how you brought in an Architecture Design Patter to unify fragmented teams - For eg. how you used side-car microservice design pattern to unify logging across all services, how you architected it so that each team gets their logging done via a common platform, but can troubleshoot their own logs
  • How you connected business strategy to architecture outcomes. Use examples like driving enterprise-wide standards or a shared technical vision or any such initiatives.

2. Architecture Specific Questions

Use the STAR method (Situation, Task, Action, Result) when answering.

Question What to Prepare
Defining and driving technical direction Prepare two examples: 1 strategic (vision, roadmap) + 1 tactical (critical system decisions).
Ensuring architectural alignment Discuss governance models: Architecture Review Boards, Tech Radars, principles via PR reviews, architecture champions.
Maintaining standards at scale Examples like versioning strategies, microservices patterns, cloud governance, API standards, etc.
Growing and mentoring architects or engineers Mentoring approaches: 1-on-1 coaching, architecture guilds, tech talks, knowledge sharing.
Working with product/business Leading technology roadmaps, tying initiatives to business OKRs or strategic goals.
Resolving conflicts between architecture and product A story where you diplomatically aligned or defended good architecture practices without blocking delivery.

3. Q&A (When You Ask Them)

Prepare smart, strategic questions to flip the interview energy:

  • “What are the biggest pain points you hope a Principal Architect will solve immediately?”
  • “How does success look for this role beyond 6 months?”
  • “What cultural or organizational obstacles should I be aware of?”
Area Tip
Storytelling Use real examples. Name systems, platforms, teams. Mention impact with numbers if possible.
Technical Depth Be ready to whiteboard or discuss architecture stacks: Cloud, Event-Driven Systems, API Gateway setups, Data Platforms, DevOps maturity.
Leadership Voice Speak as a peer to the Chief Architect. Show you’re strategic, not just a solution builder.
Maturity Mindset Talk about building technical cultures: architecture communities, guilds, design reviews.
Conflict Management Show you can diplomatically manage conflicts but advocate for good architecture.
Curiosity Ask questions with genuine enthusiasm. Curious architects are more valued.

Mostly written by Easo Thomas, 30% helped by Chatgpt (especially around markup formatting)

Who is Easo Thomas?

24 Apr 2025

Easo Thomas is another Software Engineer turned Architect turned Engineering Manager, who is trying his best to keep up with the fast paced Technology landscape. Easo Thomas has worked with over 35 different technologies in his 20 year old career, but most of it are either obsolete or never gets asked in the interviews, or don’t help him to the next best opportunity. So he is still trying his best to solve at least 100 Hard Leetcode problems before the end of 2025, to increase his chance of getting hired or stay at the current level.

Easo Thomas wants to be the best communicator in the world. He thinks people have lost the art of communication by sitting in front of the computers which never communicates back to them or talk back to humans. But they only give notifications. Easo Thomas is ecstatic that AI might solve this problem by introducing smart AI agents which can talk to you and communicate with you verbally.

Easo Thomas has attempted to drink his share of startup poison in the past. He has worked with his friends on many a startup, attempting himself to create a dating app for Indians, a neighborhood app for Indians, and also he attempted creating a Resume ATS service in 2018.

Every word in this post was handwritten by Easo Thomas himself, and not by an LLM. If there are mistakes or missing punctuation, thats your proof that it was written by poor him! Easo Thomas does make mistakes, but quickly learns from it, and try my best to not repeat it ever. I also make sure I share the learnings with others. The last mistake he did was when writing this post, and he took 4 commits to make it right!

LinkedIn GitHub