Viraj Mavani

The Engineering Behind Serving LLMs at Scale

Wed, 25 Feb 2026 00:00:00 +0000

Training a large language model gets most of the attention. But if you’ve ever tried to serve one in production — handling real traffic, real latency requirements, and real cost constraints — you know that inference is where most of the hard engineering lives. Over the past couple of years, researchers and systems engineers have made remarkable progress in closing the gap between what these models can do and what it actually costs to run them. Having worked on large-scale distributed systems and followed the ML research space closely, I find this intersection of systems thinking and machine learning to be one of the most exciting areas in software engineering right now.

The Core Problem: Autoregressive Generation is Sequential

To understand why LLM serving is hard, you need to understand how text generation works. Models generate tokens one at a time, where each new token depends on all the tokens that came before it. This autoregressive nature means you can’t trivially parallelize generation across a single sequence the way you can parallelize training across samples in a batch.

This creates two distinct phases with very different compute profiles:

Prefill: Processing the entire input prompt in parallel. This is compute-bound and GPU-efficient.
Decode: Generating output tokens one by one. This is memory-bandwidth-bound and notoriously GPU-inefficient.

  PREFILL (parallel, compute-bound)         DECODE (sequential, memory-bound)
  ┌────────────────────────────────┐
  │  [P1]  [P2]  [P3]  [P4]  [P5] │──▶  [T1] ──▶ [T2] ──▶ [T3] ──▶ ...
  │   all prompt tokens at once    │      one new token generated per step
  └────────────────────────────────┘

Naively serving requests — waiting for one to finish before starting the next — wastes enormous amounts of GPU capacity. The challenge is to keep the GPU busy without sacrificing latency.

Continuous Batching

The first major insight is that you don’t need to wait for an entire batch to finish before admitting new requests. Traditional static batching holds a fixed set of requests together until all of them complete. Since requests have wildly different output lengths, this means fast requests sit idle waiting for slow ones.

Continuous batching — also called in-flight batching — solves this by treating generation as a stream of iterations. At each step, finished sequences are immediately evicted from the batch and new requests are slotted in. The GPU is kept continuously busy, and short requests don’t pay a penalty for being grouped with long ones. This single change dramatically improves throughput and is now standard in production inference engines.

Static Batching:
  Step:    1    2    3    4    5    6
  Slot A: [████████][  idle  ][  idle  ]   ← done early, slot wasted
  Slot B: [████████████████████████████]
  Slot C: [████████████████][  idle   ]    ← done mid-way, slot wasted

Continuous Batching:
  Step:    1    2    3    4    5    6
  Slot A: [████████][  Req D ████████ ]   ← D admitted immediately
  Slot B: [████████████████████████████]
  Slot C: [████████████████][  Req E  ]   ← E admitted immediately

PagedAttention and KV Cache Management

Every token the model has seen needs to be stored in a key-value (KV) cache so that attention can be computed efficiently on subsequent steps. For long sequences or large batches, this cache becomes the dominant consumer of GPU memory — and the way it’s managed determines how many requests you can serve concurrently.

The naive approach allocates a contiguous block of memory for each request upfront, sized for the maximum possible sequence length. This leads to severe fragmentation: memory is reserved but unused, and the system can serve far fewer concurrent requests than the hardware should theoretically allow.

PagedAttention, introduced with vLLM, borrows an idea from OS virtual memory. Instead of contiguous allocation, it partitions the KV cache into fixed-size blocks that can be stored non-contiguously and fetched via a block table during attention computation. Requests share physical memory pages when their prefixes are identical — common in applications where many users share the same system prompt. The result is dramatically higher memory utilization and, consequently, much larger effective batch sizes.

Naive (contiguous pre-allocation):        PagedAttention (non-contiguous blocks):

┌──────────────────────────┐             Physical memory:
│ Req A  [████████░░░░░░░░]│             ┌──────┬──────┬──────┬──────┬──────┐
├──────────────────────────┤             │ A[0] │ B[0] │ A[1] │ C[0] │ B[1] │
│ Req B  [█████░░░░░░░░░░░]│             ├──────┼──────┼──────┼──────┼──────┤
├──────────────────────────┤             │ A[2] │ free │ C[1] │ free │ free │
│ Req C  [██░░░░░░░░░░░░░░]│             └──────┴──────┴──────┴──────┴──────┘
└──────────────────────────┘
  ░ = reserved but unused memory           Block table maps logical → physical

Speculative Decoding

The decode phase is memory-bandwidth-bound: the GPU spends most of its time loading model weights for each token, not doing useful compute. Speculative decoding exploits this headroom.

The idea is to use a small, fast draft model to speculatively generate several candidate tokens ahead of the main model. The large model then verifies all candidates in a single forward pass — taking advantage of the fact that verification is parallelizable even if generation is not. If the large model agrees with the draft, all tokens are accepted; if it disagrees at some point, generation falls back from that position.

When speculative decoding works well — which depends on the draft model’s ability to predict what the larger model would generate — it can reduce end-to-end latency significantly without sacrificing output quality. Recent work like Nightjar has pushed this further by dynamically selecting the speculative window length based on real-time batch conditions, achieving up to 20% lower latency compared to static speculative decoding.

Without Speculative Decoding:
  Large Model: ──[T1]──[T2]──[T3]──[T4]──▶   (4 serial forward passes)

With Speculative Decoding:
  Draft Model: ──[d1]──[d2]──[d3]──[d4]──▶   (4 fast serial passes)
                  │     │     │     │
  Large Model: ──[  verify d1, d2, d3, d4  ]──▶   (1 parallel forward pass)
                       ✓     ✓     ✗
                                   └─▶ reject d3, d4 → regenerate from d3

  Net result: 2 accepted tokens from 1 large model pass instead of 1

Why This Matters Beyond LLMs

What I find intellectually satisfying about this space is that none of these ideas are entirely new. Continuous batching is a scheduling problem. PagedAttention is virtual memory. Speculative execution has been in CPUs for decades. What’s happened is that the scale and economics of LLM deployment have made it worth rigorously applying classical systems thinking to a new domain.

The engineers who will do the most interesting work at this intersection aren’t those who know only one side — they’re the ones who understand both the model and the system it runs on. That’s a skill set worth building.

Later.

The Framework Dilemma: Are Frameworks the Death of Software Engineering?

Tue, 12 Sep 2023 00:00:00 +0000

In the ever-evolving landscape of software development, the role of frameworks has become increasingly prominent. We’ve all heard it before — developers proudly declaring themselves as “React Developers,” “Django Developers,” or “Spring Developers.” While there’s nothing inherently wrong with specializing in a particular framework, I believe that excessive framework reliance can hinder the growth of software engineering as a whole.

Let me clarify; I don’t mean to paint all framework enthusiasts with a broad brush. There are certainly skilled engineers among them who understand the core principles of software development. However, my observations have led me to believe that too many developers are falling into the trap of focusing solely on their chosen framework, neglecting the broader knowledge base that makes a well-rounded engineer.

One of the primary culprits behind this phenomenon is the influence of certain experienced engineers who champion their preferred frameworks as if they were divine creations. It’s perfectly acceptable to have strong opinions, but it’s detrimental not to remain open to change. This tunnel vision has resulted in an overabundance of job listings seeking candidates with expertise in specific frameworks, perpetuating the framework-centric mindset.

Frameworks, once introduced, tend to stick around, even in modified forms. They establish practices that endure for generations. I don’t harbor any ill will toward frameworks; they serve an invaluable purpose by expediting development, enhancing maintainability, and facilitating collaboration in teams. Each framework has its unique strengths and “flavor.” However, we must not lose sight of the bigger picture.

As my mentor used to emphasize, a true software engineer isn’t merely someone who churns out code or develops features in large-scale systems. A genuine software engineer is one who identifies and effectively solves problems. Frameworks, while providing structure and efficiency, can inadvertently stifle creative thinking. They impose a predefined structure on thought, potentially becoming shackles for the free thinker.

Historically, the most significant leaps in software development have been made by creating new frameworks rather than relying solely on existing ones. These groundbreaking solutions generated substantial value for their respective businesses.

In conclusion, frameworks have their place and are invaluable tools in the software developer’s arsenal. However, they should not overshadow the importance of developing a well-rounded skill set and embracing a broader perspective. Instead of pigeonholing ourselves into specific frameworks, let’s strive to be true engineers who understand, identify, and genuinely solve problems. In doing so, we can ensure that software engineering continues to evolve and thrive, unburdened by the limitations of any single framework.

Containerization in Distributed Systems

Sun, 14 May 2023 00:00:00 +0000

As a software engineer, I’ve always been interested in finding ways to improve the efficiency and scalability of my applications. When I first learned about containerization, I was immediately intrigued by the potential benefits it could offer.

Containerization is a method of packaging and deploying software applications in isolated environments called containers. Containers share the operating system (OS) of the host machine, but they have their own filesystem, network, and process space. This makes them lightweight and portable, and it allows them to be deployed quickly and easily.

There are many benefits to using containerization for distributed computing. Containers make it easy to deploy and manage applications across multiple machines. They also provide a high level of isolation, which can help to improve security and performance. Additionally, containers can be used to create self-contained environments that are easy to replicate and scale.

In my experience, containerization has been a valuable tool for improving the efficiency and scalability of my applications. I’ve found that it’s easy to deploy and manage containers, and they’ve helped me to improve the security and performance of my applications.

Advantages of Containerization

Efficiency: Containers are like self-contained packages for your applications. They are lightweight and don’t require a full operating system to run. This makes them highly efficient in terms of resource usage. Containers only include the necessary components to run your application, which means they start quickly, use minimal memory, and have a smaller footprint compared to traditional virtual machines.

Scalability: Containers excel in scalability. With containerization, you can easily scale your application up or down based on demand. When your application experiences a spike in traffic or needs more resources, you can effortlessly add more containers to handle the increased load. Similarly, during periods of lower demand, you can scale down by reducing the number of containers. This elasticity ensures your application performs optimally at all times, without wasting resources.

Security: Containers provide a level of isolation that enhances application security. Each container operates in its own isolated environment, ensuring that if one container is compromised, it won’t affect the others. Containers use a combination of kernel-level isolation and resource control mechanisms to keep applications separated, reducing the attack surface and minimizing the potential impact of security breaches.

Portability: One of the key advantages of containers is their portability. Containers encapsulate your application and its dependencies into a single package, making it easy to run the same containerized application across different computing environments. Whether you’re developing on your local machine, testing on a staging server, or deploying in a production environment, the container remains consistent, reducing the chances of compatibility issues and simplifying the deployment process.

Reproducibility: Containers offer reproducibility, ensuring consistent environments for your applications. Containers are built from images, which are like snapshots of a container’s filesystem and configuration. These images capture the exact state of the container at a specific point in time. With the same image, you can easily recreate the exact environment, ensuring consistency across development, testing, and production. This reproducibility makes it easier to share and collaborate on applications and reduces the likelihood of “it works on my machine” scenarios.

Common Containerization Patterns

Single-container applications: This is a simple pattern where each application is deployed in its own container. This makes it easy to manage and update individual applications.

Container orchestration: This pattern uses a container orchestration tool to manage groups of containers. Orchestration tools can help to automate tasks such as deployment, scaling, and load balancing.

Microservices: This pattern breaks down an application into a collection of small, independent services. Each service is deployed in its own container, which makes it easy to scale and manage the application.

Function as a Service (FaaS): This pattern allows developers to deploy individual functions as containers. This makes it easy to build and deploy applications that are composed of small, independent functions.

Challenges of Using Containerization

Security: Yes! It is one of the challenges as well. Containers share the same OS as the host machine, so it is important to take steps to secure them. This includes using secure images and containers, and configuring the host machine securely.

Performance: Containers can add overhead to the host machine, so it is important to choose the right containerization solution for your needs. Some factors to consider include the number of containers that will be deployed, the type of applications that will be deployed, and the host machine’s resources.

Complexity: Containerization can be complex, especially for large-scale deployments. It is important to have a good understanding of containerization before you start deploying applications in containers.

Overall, containerization is a powerful tool that can be used to improve the efficiency and scalability of distributed computing. If you are looking for a way to deploy and manage applications across multiple machines, containerization is a great option to consider.

Cost of building monolithic applications

Sun, 16 Apr 2023 00:00:00 +0000

Almost always, the easy route is not the correct one.

For many years, the standard method for creating software applications has been using a monolithic architecture. It entails developing an application as a solitary, independent unit with tightly integrated UI, data read/writes, and business logic. While this method is useful for smaller projects and kick-starting projects at a fast pace, it presents a number of difficulties when applications get bigger and more sophisticated. We’ll examine the drawbacks of monolithic design in this post and look at the motivations for developers’ shift to alternative paradigms like microservices.

In a dilemma about whether to make the move yourself to microservices? Read on!

Scalability Problems:

The limited scalability of monolithic design is one of its main drawbacks. More resources are needed when applications expand, which can be difficult to accommodate within a single, monolithic codebase. Monolithic applications are often scaled by cloning the entire application, which can be time and resource hungry. Apart from that, using a monolithic architecture makes engineers to scale their systems up vertically which normally results in increased costs associated with infrastructure. In contrast, a microservices design makes horizontal scaling pretty easy and allows for the autonomous scaling of each microservice, resulting in a more resource-effective use of resources.

Increased Complexity:

As a monolithic application gets bigger, its coding inevitably gets more intricate and challenging to manage. As a result, developers may need to spend more time on projects because it takes longer to navigate a complicated codebase and add new features. Additionally, it raises the chance of adding flaws or destroying functionality already in place.

Inflexible Tech Stack:

Monolithic architecture often locks developers into a specific technology stack. This means that if they want to adopt new technologies, they may need to rewrite the entire application, which can be time-consuming and expensive. In contrast, microservices architecture enables developers to use different technology stacks for individual components, making it easier to adopt new technologies or switch between them as needed.

Slow Deployment Process:

The deployment process for monolithic applications can be slow and prone to errors. Since the entire application is bundled together, even small changes require a complete redeployment of the application. This can lead to increased downtime and reduced productivity, particularly in large-scale applications. On the other hand, microservices architecture allows for faster and more targeted deployments, as individual components can be updated independently.

Difficulty in Adopting Agile Development Practices:

Agile development practices, such as continuous integration and continuous deployment, are challenging to implement within a monolithic architecture. The complexity of the codebase, slow deployment process, and inflexible technology stack all contribute to this difficulty. As a result, monolithic applications may struggle to keep pace with the rapid evolution of software development practices and industry standards.

Human Resource:

The biggest cost that most people do not consider is the human cost. When an organization has been maintaining a monolithic service for a long period of time, there eventually arises a unique sort of an engineer called an SME (subject matter expert). The SMEs in software engineering world become a bottleneck in the software development lifecycle as there seems to be no progress made if they are not present leading to inefficiencies.

In conclusion, monolithic architecture has substantial drawbacks in terms of scalability, complexity, technology stack flexibility, deployment speed, and adoption of agile development approaches, even though it may be appropriate for some projects. As a result, many developers are using alternate strategies to create apps that are more effective, scalable, and flexible. The limits of monolithic architecture might help developers choose the strategy that best satisfies their unique demands and requirements.

Later.

Product of Array Except Self - LeetCode #238

Mon, 25 May 2020 00:00:00 +0000

Being one of the most asked questions and also one of the important problem patterns on LeetCode, the product of array except self problem has become a subject of interest for this blog. It uses a modification of a general approach called prefix sum as an optimal solution.

Let’s dive into it!

Problem Statement

You can find the problem statement here: Product of Array except Self - LeetCode

Solution(s)

1. Naive Approach - Brute Force

The brute-force approach to solution is simple. For each index in the the array, we calculate the product of every remaining element.

The python code for it will look like this:

def productExceptSelf(nums):
    n = len(nums)
    result = [0]*n
    for i in range(n):
        product = 1
        for j in range(n):
            if i != j:
                product = product * nums[j]
        result[i] = product
    return result

Time Complexity: O(N²) Space Complexity: O(1) [Not considering the result array]

2. Better Approach - Prefix and postfix products

As we can observe in the brute-force solution, there is a lot of recomputation happening which can be avoided to speed up our code. All we have to do is to precompute all the products from the left side and right side leaving apart the element at their index and have 2 new arrays holding the products. We can do this in two single passes through the array and then we can finally make the result array going through the arrays once more. A more detailed explanation can be seen in the image below:

The time complexity will be reduced to O(N) due to single passes but the space complexity will rise to be O(N) as well.

The python code for this approach is given below:

def productExceptSelf(nums):
    n = len(nums)
    left_prod = [1] * n
    right_prod = [1] * n
    result = [1] * n

    for i in range(1, n):
        left_prod[i] = left_prod[i-1] * nums[i-1]
        
    for i in range(n-2, -1, -1):
        right_prod[i] = right_prod[i+1] * nums[i+1]
    
    for i in range(n):
        result[i] = left_prod[i] * right_prod[i]

    return result

Time Complexity: O(N) Space Complexity: O(N) [Extra space used for Left Product and Right Product arrays]

3. Optimal Approach - Prefix and postfix products without extra space

We can modify the approach discussed above to not use any extra space by simple trickery.

The python code for it is given below:

def productExceptSelf(nums):
    n = len(nums)
    result = [1] * n

    for i in range(1, n):
        result[i] = result[i-1] * nums[i-1]
        
    r_prod = 1

    for i in range(n-1, -1, -1):
        result[i] = r_prod * result[i]
        r_prod *= nums[i]

    return result

Time Complexity: O(N) Space Complexity: O(1) [Extra space not used - Disregarding result array]

Best of Luck! Later.

Contains Duplicate - LeetCode #217

Wed, 22 Apr 2020 00:00:00 +0000

The Contains Duplicate problem on LeetCode is again one of the most asked questions and has the distinction to be on the Blind Community curated 75 questions list and therefore it makes it a subject of this blog’s interest. While it looks simple at first glance, there are a few things that need to be noted and will be helpful further in your journey through LeetCode.

Let’s dive into it!

Problem Statement

Given an array of integers, find if the array contains any duplicates.

Your function should return true if any value appears at least twice in the array, and it should return false if every element is distinct.

Example 1:

Input: [1,2,3,1]
Output: true

Example 2:

Input: [1,2,3,4]
Output: false

Example 3:

Input: [1,1,1,3,3,4,3,2,4,2]
Output: true

Problem Analysis

The problem is to basically to check if the array contains the same element twice or more. Simple enough. Also, note that the array is unsorted. Nothing more to it than this and so we’ll move on to solutions.

Solution(s)

1. Naive Approach - Brute Force (TimeLimitExceeded on LeetCode)

The brute force approach for any problem is probably the easiest to come up with. Here, we need to check for duplicates and in order to do that we will fix one element and try to find it again in the rest of the array.

The python code for it looks something like this:

def containsDuplicate(nums):
    n = len(nums)
    if n < 2:
        return False
    

    for i in range(n):
        for j in range(i):
            if nums[i] == nums[j]:
                return True
    return False

Time Complexity: O(N²) Space Complexity: O(1)

2. Better Approach - Sorting

We could have come up with a better solution only if we knew where to look for the second element after fixing the first in the brute force approach. Well, we can do this by simply sorting the array as after that, the duplicates will always be consecutive. We can then just conduct a linear search and determine if there are any duplicates or not.

The python code for this approach will look like:

def containsDuplicate(nums):
    n = len(nums)
    if n < 2:
        return False
    
    nums.sort() # In-place sorting

    for i in range(1, n):
            if nums[i-1] == nums[i]:
                return True
    return False

Time Complexity: O(N*log(N)) Space Complexity: O(1)

While we reduced the time complexity from O(N²) to O(N*log(N)), we still can do better in terms of the time complexity. But, it comes at a cost.

3. Optimal Approach - Hash Set

The most optimal approach in terms of time complexity does indeed use extra space. But, as discussed before, space is cheap and time invaluable. Therefore, we can simple put all elements in a Hash Set and as it does not allow for duplicates, the size of the resulting Hash Set should be equal to the length of the array if there are no duplicates and less otherwise.

A simple one line code in python looks like:

def containsDuplicate(nums):
    return len(set(nums)) < len(nums)

Beautiful indeed. The computational complexities are:

Time Complexity: O(N) Space Complexity: O(N)

Later.

Two Sum - LeetCode #1

Mon, 20 Apr 2020 00:00:00 +0000

As “Hello, World!” is to Programming, so is the Two Sum problem to LeetCode. Any blog series or YouTube channel targeted towards solving LeetCode problems has to first pay deference to this problem. It is therefore implied that this blog series will be no different.

So let’s just jump right into it.

Problem Statement

Given an array of integers, return indices of the two numbers such that they add up to a specific target.

You may assume that each input would have exactly one solution, and you may not use the same element twice.

Example:

Given nums = [2, 7, 11, 15], target = 9,

Because nums[0] + nums[1] = 2 + 7 = 9,
return [0, 1].

Problem Analysis

Well, the problem statement is clear and to the point enough that we don’t need to do much analysis. The only points to note here are:

We have to return indices
The array is not sorted

Solution(s)

1. Brute Force Approach

First and foremost, we must try to solve the problem using a brute-force approach so as to get more insight into how to further optimize it.

We can simply iterate over each element and for each such element, we can iterate over the rest of the elements in the array to check if they sum up to the target value.

The python code will look something like this:

def two_sum(array, target):
    n = len(array)
    for i in range(n):
        for j in range(i+1, n):
            if array[i] + array[j] == n:
                return [i, j]
    
    return []

Well, that was cute. But really abhorrent if you want to land that FAANG job you are looking for.

We can safely rely on our Algorithms and Data Structures course content and say that the time complexity here is in the order of O(N²) and we are not really using any extra space so the space complexity will be O(1).

Time Complexity: O(N²) Space Complexity: O(1)

2. Optimal Approach - Using Hash Table

I recall that I once was watching a YouTube video on LeetCoding practices and the content creator said that Hash Tables are very over-powered. You can’t come up with a solution, just throw Hash Tables at the problem and you will make some progress. Constant time access IS over-powered.

Same applies to this problem as well and in this case, it is the most optimal approach known to programmers worldwide.

The idea here is that we can use Hash Table to store the elements and keys and their indices as values. While iterating through each element, we can then check if (target - element) is present in the Hash Table or not. The answer will simply then become the iterator index and the index stored in the Hash Table.

The python code looks something like this:

def two_sum(array, target):
    n = len(array)
    htable = {}

    for i in range(n):
        residual = target - array[i]
        if residual in htable:
            return [htable[residual], i]
        htable[array[i]] = i
    
    return []

Isn’t it beautiful? Indeed it is. We have sacrificed some space in order to achieve linear time complexity for the solution. The Hash Table uses O(N) space and the time complexity becomes O(N) as well. But, space is cheap and time invaluable. Therefore, this being the most optimal approach.

Time Complexity: O(N) Space Complexity: O(N)

Alternative Problem Statement - Sorting

Return Elements

When asked to return the elements and not the indices, the following is also one of the approaches. It is not as good as the Hash Table approach, but still is better than brute force.

The approach is called the two pointer approach. It might be difficult to get to it logically, but on knowing it, it is as simple as it can be.

In this problem, we noticed that there have been no comments on the order of the elements in the array making us assume that it is an unsorted one. We can initially sort the array to get ordering introduced in the problem. Once, we have the ordering we can make decisions by trying out different sum of two elements.

For any indices [i, j] (where i < j) in the sorted array, we can safely say that if the sum of the elements at i and j is greater than the target, then we might want to decrement j in order to get to the target. Same applies vice versa, that is, if the sum is less than the target, incrementing i will rbing us closer to the solution.

Basically, we will start with i = 0 and j = n-1 (where n = len(array)) adn increment i or decrement j in accordance with the sum of the elements at i and j.

The python code for this approach looks something like this:

def two_sum(array, target):
    n = len(array)
    i = 0
    j = n-1

    # Sort array in place
    array.sort()

    while i < j:
        curr_sum = array[i] + array[j]
        if curr_sum == target:
            return [array[i], array[j]]
        if curr_sum < target:
            i += 1
        else:
            j -= 1
    
    return []

The computational complexities for this approach are given below:

Time Complexity: O(N*log(N)) Space Complexity: O(1) // as sorting in place

End Note

I know developing intuition for solving LeetCode problems is difficult. Over time, you will understand that there are a few approaches that should first be tried out for each problem. Just try to apply them mentally and think if they would in any way help you in getting to the answer. One such approach that we learned today is the Two Pointer Approach.

Later.

Automatic Post from Java Web Service

Wed, 08 Jan 2020 00:00:00 +0000

Dummy Post made using the Java Web Service

Posted using the Java Web Service which automatically makes updates to the blog and commits on GitHub which is being used to host the website.

My first experience as a Quiz Master!

Thu, 16 Apr 2015 00:00:00 +0000

MIND PALACE’S youngest Quizmaster takes the stage.
Internal Gen Quiz Session
By Viraj Mavani,
Wednesday, 18th March, 2015
3 pm @ Room 3001, Annexe Building
No prior registration required. Just be there and spread the word. 😉

This was how the invite was to majority of the students who share the college with me. Just a few months into the field and here I was conducting “My First Quiz”. It was definitely worth experiencing as no one would have ever had to present one holding a laptop in his hands and raising it so that the crowd could see. Yes. The projector was out-of-order. So, I conducted half of the prelims round(which was converted to a common pounce-bounce round for ease) speaking as loudly as I could and briskly walking around the hall (with the 14″ laptop) so that every one could have a look.

Then, by god’s grace, we moved to the class with the projector, WORKING. And it was then that I started having a good time. I took back a moment as everyone read the question and thought to myself, “Blue Blistering Barnacles! This is really happening!”

We ended The Quiz quite gracefully. Many loved friends attended it while those who didn’t, just got hold of the PPT later on.

That was how it feels to be a Quiz Master. (For the First Time! 😉 )

Mischief Managed.

Share with me your views. Comment below. 😉

Hello World!

Wed, 15 Apr 2015 00:00:00 +0000

This is the first thing that most entities on the internet start with. The Hello World. So here I am, bidding hello to the world and to you.

Viraj Mavani. This is how people know me. An Average Joe. The Muhammed Lee. A student at L. D. College of Engineering pursuing his interests in the bold and huge field of Electronics. As I mentioned, an Average Joe means an average student too. The seven point someone guy. I live in Ahmedabad and roam about just a little even though I want to. When it comes to attending classes, I am regularly irregular. The story of every to-be-engineer.

Apart from being common, I also happen to be an Editor for the College Magazine and that is not so common among the ‘House of Commons’ (literally). The magazine goes by the name Vox Populi (Check it out on FB). I am also a regular quizzer and an occasional Quiz Master for the quizzing club of the college under the name Mind Palace. A free lance photographer too. The blog background you see is credited to me. So, that’s where I am at present, leading a common happening life ;). (That was all too common-common :P)

Thus, the purpose is defined. I will be updating my experiences with the Magazine, the Quiz Club and the Photography. I may go out of the line sometimes and get some creative. You will come to know it then. 😉

So here I am, signing off with a sentence that I adore a lot.

“I solemnly swear that I am up to no good.”

Later.