DEV Community: Syed Muhammad Ali Raza

Fine-Tuning Explained (And When You Actually Need It Instead of RAG)

Syed Muhammad Ali Raza — Wed, 29 Jul 2026 21:05:00 +0000

Fine-Tuning Explained (And When You Actually Need It Instead of RAG)

After I wrote about RAG, a bunch of comments asked some version of the same question. "Okay but what if I want the model to actually behave differently, not just answer using my documents." Good question, and the honest answer is that's a different problem with a different tool. That tool is fine-tuning.

I put off learning this properly for a long time because it sounded expensive and complicated, something only big companies with server farms do. Turns out a basic understanding of it is way more approachable than I expected, and knowing when NOT to use it is honestly the more valuable lesson. So let's get into it properly, real example first, then actual code.

A real life example to set the stage

Think about training a new employee at a customer support job.

If you hand them a manual and tell them "look things up in here whenever you're unsure," that's RAG. They still talk and think like themselves, they just consult reference material when they need specific facts. Their personality, tone, and general way of communicating hasn't changed at all, they've just got a good reference book next to them.

Now imagine instead you actually trained that person for months, had them shadow senior staff, corrected their tone repeatedly, drilled them on your company's specific way of phrasing things until it became second nature. After that training, they don't need to look anything up for common situations, it's just baked into how they naturally respond now. That's fine-tuning. You're not handing the model a reference book, you're actually reshaping how it responds by showing it enough examples that the new behavior becomes part of it.

Both approaches can get you a good employee. But they solve different problems. If your issue is "the person doesn't know our specific product details," a manual fixes that instantly and cheaply. If your issue is "the person's tone and style just isn't matching what we need no matter how much reference material we give them," training is what actually fixes that.

What fine-tuning actually is, technically

An LLM, underneath everything, is a giant pile of numbers called parameters, sometimes billions of them, that got adjusted during training to make the model good at predicting text. Fine-tuning means taking a model that's already been trained once, and training it a bit further on a smaller, specific set of examples so its parameters shift slightly toward behaving the way you want in that specific area.

You're not starting from scratch. You're not building a new model from nothing, that's what the original training already did and it costs an amount of money most of us will never personally spend. Fine-tuning is more like giving an already capable model some focused extra practice on exactly the kind of task or tone you care about.

When fine-tuning is genuinely the right call

I used to think fine-tuning was just "the more advanced version of RAG," like a level up. That's wrong and it cost me some wasted time. They solve different kinds of problems.

Fine-tuning makes sense when you need consistent style or tone across every single response, like a brand voice that has to be exactly right every time. It also helps with teaching the model a specific format or structure it doesn't naturally produce, or teaching it a narrow skill, like classifying support tickets into your company's exact categories, or writing code in a very specific internal style your team uses. It's also useful when you need the model to reliably follow a particular behavior pattern that's hard to fully explain in a prompt every single time.

Fine-tuning does not make sense as the fix when your actual problem is that the model doesn't know specific facts or up to date information. That's what RAG solves, and it solves it far more cheaply and it updates instantly when your source data changes. A lot of people reach for fine-tuning to "teach the model our documentation" and end up frustrated, expensive, and still not getting current information reliably, when what they actually needed was retrieval the whole time.

A decent rule of thumb I settled on, if the problem is about knowledge, reach for RAG first. If the problem is about behavior, tone, or format, fine-tuning is worth considering.

The data problem nobody warns you about

Here's the part that actually matters more than the code, and I learned this the hard way. Fine-tuning is entirely dependent on the quality of your example data. Feed it fifty inconsistent, messy examples and you'll get a model that's inconsistently, messily different from before, not better.

The examples need to actually represent the behavior you want, consistently, and there needs to be enough of them to establish a real pattern rather than a fluke. I've seen people try to fine-tune on twenty examples and wonder why nothing changed. The model needs enough repetition of the pattern to actually shift its behavior, not just see the idea once.

Let's actually do this with code

I'll walk through two versions. First, using a hosted fine-tuning API, which is the easier route and what most people should start with. Then a quick look at what's happening if you were to do it yourself locally, so you understand what the hosted version is doing for you behind the scenes.

Version one, using a hosted fine-tuning API

Most major providers offer fine-tuning as an API service where you upload your examples and they handle the actual training infrastructure for you. The general shape looks like this, using OpenAI's fine-tuning setup as the example since it's widely used and well documented.

First, you prepare your training data in a specific format, usually a JSONL file, which just means one JSON object per line, each one representing a single example conversation.

import json

training_examples = [
    {
        "messages": [
            {"role": "system", "content": "You are a support assistant for a software company. Always respond in a friendly, concise tone and end with an offer to help further."},
            {"role": "user", "content": "My app keeps crashing on startup."},
            {"role": "assistant", "content": "Sorry about that! Try clearing the app cache first, that fixes it most of the time. Let me know if it's still crashing after that and we'll dig deeper together."}
        ]
    },
    {
        "messages": [
            {"role": "system", "content": "You are a support assistant for a software company. Always respond in a friendly, concise tone and end with an offer to help further."},
            {"role": "user", "content": "How do I export my data?"},
            {"role": "assistant", "content": "Easy, head to Settings then Export Data, pick CSV or JSON, and it'll download right away. Want a hand finding where to import it afterward?"}
        ]
    }
    # in a real project, you'd want at least fifty to a few hundred
    # examples like this, all consistently following the tone and
    # format you actually want
]

# write it out as JSONL, one example per line
with open("training_data.jsonl", "w") as f:
    for example in training_examples:
        f.write(json.dumps(example) + "\n")

Once you have that file, you upload it and kick off the fine-tuning job.

from openai import OpenAI

client = OpenAI(api_key="your-api-key-here")

# upload the training file
uploaded_file = client.files.create(
    file=open("training_data.jsonl", "rb"),
    purpose="fine-tune"
)

# start the fine-tuning job using that file
job = client.fine_tuning.jobs.create(
    training_file=uploaded_file.id,
    model="gpt-4o-mini-2024-07-18"
)

print(job.id)
# this runs in the background on their servers, could take
# anywhere from minutes to a couple hours depending on data size

You can check on it while it trains.

status = client.fine_tuning.jobs.retrieve(job.id)
print(status.status)
# will show something like "running" then eventually "succeeded"

Once it's done, you get back a custom model name, and from then on you just call it exactly like you'd call any other model.

response = client.chat.completions.create(
    model=status.fine_tuned_model,
    messages=[
        {"role": "user", "content": "The app won't let me log in."}
    ]
)

print(response.choices[0].message.content)

And that's genuinely the whole hosted workflow. Prepare consistent examples, upload them, start a job, wait, then use the resulting model name like normal.

Version two, a peek at what's happening underneath, using LoRA locally

If you're curious what the hosted service is actually doing for you, or you want to fine-tune an open source model yourself instead of a closed one, this is roughly what it looks like using a technique called LoRA, which stands for Low Rank Adaptation. Instead of updating all of a model's billions of parameters, which would need a serious amount of computing power, LoRA only trains a small set of additional parameters that get layered on top of the original model. It's dramatically cheaper and faster while still getting you most of the benefit.

# this example uses the Hugging Face ecosystem, a common
# open source setup for this kind of thing
# pip install transformers peft datasets torch

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model
from datasets import Dataset

model_name = "meta-llama/Llama-3.2-1B"  # a small open model as an example

tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

# LoRA config, this defines how much extra "adjustable" capacity
# we're adding on top of the frozen original model
lora_config = LoraConfig(
    r=8,                 # rank, basically how much extra capacity to add
    lora_alpha=16,
    target_modules=["q_proj", "v_proj"],  # which parts of the model to adapt
    lora_dropout=0.05,
    task_type="CAUSAL_LM"
)

model = get_peft_model(model, lora_config)

# your training examples, formatted as plain text
training_texts = [
    "User: My app keeps crashing.\nAssistant: Sorry about that! Try clearing the app cache first, that fixes it most of the time. Let me know if it's still crashing after that and we'll dig deeper together.",
    "User: How do I export my data?\nAssistant: Easy, head to Settings then Export Data, pick CSV or JSON, and it'll download right away. Want a hand finding where to import it afterward?"
]

dataset = Dataset.from_dict({"text": training_texts})

def tokenize(example):
    return tokenizer(example["text"], truncation=True, padding="max_length", max_length=256)

tokenized_dataset = dataset.map(tokenize)

# from here you'd hand this off to a Trainer object and call .train()
# the important conceptual point is just this, the model's original
# weights stay frozen, only these small LoRA layers get updated,
# which is why this is so much cheaper than training everything

I won't pretend that second example is copy paste ready for a beginner, actually running local fine-tuning involves GPU setup, dependency management, and enough moving parts to fill its own article. The point of showing it is just so the hosted API from version one stops feeling like a black box. Underneath, it's the same basic idea, feed it consistent examples, adjust a manageable number of parameters, get a model that's shifted toward your examples.

Mistakes I made so you don't have to

I fine-tuned on way too few examples the first time and got confused why nothing meaningfully changed. Consistency and volume both matter, a handful of examples isn't enough to establish a real pattern.

I tried to fine-tune my way out of a knowledge problem, feeding the model our internal documentation as training examples hoping it would "learn our product." It kind of half worked and was way more expensive and slower to update than just building a small RAG setup would have been. Lesson learned the hard way, painfully.

I didn't keep a solid evaluation set aside. I trained, tried a few examples, thought it looked good, and moved on, only to find out later it had gotten noticeably worse at some other unrelated task I hadn't tested. Always hold out some real test cases you didn't train on, and check the model against those before assuming a fine-tune actually helped.

The honest summary

If you remember one thing from this, remember the employee example. A manual next to someone's desk fixes a knowledge gap instantly and cheaply, and that's RAG. Months of training reshapes how someone naturally behaves, and that's fine-tuning. Most problems people bring to fine-tuning are actually knowledge problems in disguise, and RAG would've solved them faster and cheaper. But for the real behavior and consistency problems, fine-tuning genuinely is the right tool, and now you've actually seen what's happening inside it instead of just hearing the word thrown around.

If you try fine-tuning your own small model on something, I'd genuinely like to hear what you built it for, drop it in the comments.

RAG Explained Like You're Five (With Real Code You Can Actually Run)

Syed Muhammad Ali Raza — Wed, 29 Jul 2026 03:15:00 +0000

RAG Explained Like You're Five (With Real Code You Can Actually Run)

Okay so last time I wrote about RAG and a bunch of people messaged me saying "cool but I still don't get what's actually happening behind the scenes." Fair. I threw around words like embeddings and vector search without really slowing down to explain them properly. So this time I'm doing it differently.

No jargon dump. Real life example first. Then a real, working, copy paste code example you can run on your own laptop today, even if you've never touched AI stuff before. By the end of this you should actually understand what's happening, not just be able to repeat the word "RAG" at a job interview.

Grab a coffee, this one's long.

First, a real life example that has nothing to do with computers

Imagine you're taking an exam. Two versions of the exam exist.

In version one, it's closed book. You have to answer everything purely from memory. If you forgot something you studied three months ago, tough luck, you're guessing now. And when you guess, you don't say "I'm not sure." You just write something that sounds confident because that's what gets you marks in a normal exam.

In version two, it's open book. You're allowed to bring your notes. When a question comes up, you flip to the right page, read the relevant paragraph, and write your answer based on what's actually written there.

A regular LLM like plain ChatGPT answering your question is basically doing the closed book exam. It's answering from whatever it memorized during training, which happened at some point in the past and doesn't include your personal documents, your company's internal wiki, or anything private.

RAG is what happens when you hand the model an open book exam instead. Before it answers, you go find the right page from your own documents and put it in front of the model. Then you ask the question. The model reads what's in front of it and answers based on that, instead of guessing from memory.

That's genuinely the whole idea. RAG stands for Retrieval Augmented Generation, which is just a fancy way of saying "look stuff up, then generate an answer using what you looked up."

A second real life example, this time with a librarian

Picture walking into a massive library and asking the librarian a question like "what does our company's return policy say about opened electronics."

A librarian who just answers off the top of their head, without checking anything, might get it roughly right or might completely make it up based on what return policies usually look like at other stores. That's your plain LLM.

A good librarian instead says "let me check" and walks over to the right shelf, pulls out the specific policy document, flips to the relevant page, reads that paragraph, and then answers you using what's actually written there. That "walking over to the shelf and finding the right page" part is retrieval. The "reading it and giving you an answer in plain English" part is generation. Put those two together and you get Retrieval Augmented Generation.

Why can't the model just memorize everything

Good question, and it's the one that trips people up. A few reasons.

The model was trained at some point in the past on a giant pile of public text from the internet. Anything private, like your own notes, your company's internal docs, your codebase, or anything created after training happened, it simply never saw. There's no way for it to know that stuff exists.

Even if you tried to train the model on your own data specifically (this is called fine tuning), that process is slow, expensive, and annoying to redo every single time your documents change. If your company policy gets updated tomorrow, you don't want to retrain a whole model. You just want the system to pick up the new document.

RAG sidesteps all of that. Your documents live wherever they normally live. When someone asks a question, you search those documents on the spot, grab the relevant bit, and hand it to the model fresh every single time. Update a document, and the very next question automatically benefits from the update. No retraining needed.

Okay but how does the computer know which part of the document is "relevant"

This is the part everyone glosses over, so let's actually slow down here because this is the heart of the whole system.

Computers are bad at understanding meaning the way we do. If you search a document for the exact words "cancel my subscription" using basic search, and the document actually says "how to terminate your membership," a simple keyword search will completely miss it, even though to a human those two phrases obviously mean almost the same thing.

To fix this, we use something called an embedding model. Its whole job is to take a piece of text and turn it into a list of numbers, something like [0.12, -0.87, 0.44, ... ] with maybe a few hundred or a thousand numbers in the list. This list of numbers is called a vector.

Here's the important bit. The embedding model is trained in such a way that texts with similar meaning end up with similar lists of numbers, even if the actual words are totally different. So "cancel my subscription" and "terminate my membership" end up with vectors that are close to each other in this numerical space, while something totally unrelated like "recipe for banana bread" ends up far away.

Once everything, both your documents and the user's question, gets converted into these number lists, finding "relevant" text becomes a math problem. You're just measuring which document vectors sit closest to the question's vector. That's it. That's the secret. It's not understanding in the human sense, it's just very clever math on numbers that happen to represent meaning.

The full pipeline, step by step, in plain English before we touch code

Here's the order things actually happen in, and I'll walk through each piece with the librarian example still in your head.

Step one, you take your documents and chop them into smaller pieces. This is called chunking. You wouldn't hand someone an entire 300 page manual to find one paragraph, you'd hand them the specific page. Same idea here.

Step two, you run every chunk through the embedding model and get back a list of numbers for each one. You save all these number lists somewhere, this storage is usually called a vector store or vector database.

Step three, this all happens once, ahead of time, before anyone even asks a question. Think of it as pre organizing the library shelves.

Step four, when someone actually asks a question, you run their question through the same embedding model to get its number list.

Step five, you compare the question's numbers against every chunk's numbers and pull out the closest matches. This comparison usually uses something called cosine similarity, which is just a mathematical way of measuring how similar two lists of numbers are, kind of like measuring the angle between two arrows.

Step six, you take those closest matching chunks and paste them into a prompt along with the original question, then send that whole thing to the LLM.

Step seven, the LLM reads the chunks you gave it and answers the question using that information, instead of guessing from memory.

That's the entire system. Now let's actually build one.

Let's build a tiny working version, for real

I'm going to keep the tools boring on purpose so you can actually follow what's happening instead of getting lost in library documentation. We'll use plain Python, a small free embedding model that runs locally on your own computer (no API key needed for this part), and basic math with numpy.

First, install what we need.

pip install sentence-transformers numpy

The sentence-transformers library gives us a ready made embedding model we can use for free, and it downloads automatically the first time you run it.

Step 1, our tiny "documents"

In a real system these would come from actual files, a database, or a website. To keep things simple and easy to follow, I'm just going to write them directly as text in the code.

documents = [
    "Our return policy allows customers to return unopened electronics within 30 days for a full refund.",
    "Opened electronics can only be exchanged for the same item if there is a manufacturing defect.",
    "Software products and digital downloads are non refundable once purchased.",
    "Shipping costs are non refundable, only the product price is refunded.",
    "To start a return, log into your account and click on Order History, then select Request Return."
]

Step 2, chunking

In this example each sentence is already a nice small chunk, so we don't need to split them further. In a real project, you'd usually break long documents into pieces of a few hundred words each, often with a bit of overlap between chunks so you don't accidentally cut a sentence in half at a chunk boundary. For our tiny example, each line above is already one clean chunk.

Step 3, turning our documents into number lists (embeddings)

from sentence_transformers import SentenceTransformer

# this loads a small, free embedding model onto your computer
model = SentenceTransformer('all-MiniLM-L6-v2')

# this turns every document into a list of numbers
document_embeddings = model.encode(documents)

print(document_embeddings.shape)
# output looks something like: (5, 384)
# 5 documents, each turned into a list of 384 numbers

If you print document_embeddings[0], you'll literally see a long list of decimal numbers. That's the "meaning" of the first sentence, expressed as math instead of words.

Step 4, turning the user's question into a number list too

question = "Can I get money back for a game I bought online?"

question_embedding = model.encode([question])

Notice the question doesn't use the words "refund" or "software" directly, it says "money back" and "game I bought online." A basic keyword search would probably miss the right document entirely. Let's see if our embedding based approach does better.

Step 5, finding the closest matching documents using math

import numpy as np

def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

# compare the question against every document
similarities = []
for i, doc_embedding in enumerate(document_embeddings):
    score = cosine_similarity(question_embedding[0], doc_embedding)
    similarities.append((score, documents[i]))

# sort so the best matches come first
similarities.sort(key=lambda x: x[0], reverse=True)

# grab the top 2 most relevant chunks
top_matches = similarities[:2]

for score, text in top_matches:
    print(round(score, 3), "-", text)

When I run this, the top result is the sentence about software products and digital downloads being non refundable, even though the question never uses the word "software" or "refundable." That's the embedding model catching the meaning of "game bought online" and "money back," not just the literal words. This is genuinely the moment RAG clicked for me the first time I saw it work.

Step 6, building the prompt with the retrieved chunks

Now we take those top matching chunks and hand them to the LLM along with clear instructions.

retrieved_text = "\n".join([text for score, text in top_matches])

prompt = f"""
You are a helpful customer support assistant.
Only answer using the information given in the context below.
If the answer isn't in the context, say you don't know, do not guess.

Context:
{retrieved_text}

Question: {question}
"""

print(prompt)

That instruction telling it not to guess matters a lot more than it looks like at first glance. Without it, the model tends to blend its own general knowledge in with your retrieved context, and you lose the whole point of grounding the answer in your actual documents.

Step 7, sending it to an actual LLM

This last part depends on which AI provider you're using, but the shape of it is always the same, you send the prompt, you get text back. Here's what it looks like using a typical API setup.

import anthropic

client = anthropic.Anthropic(api_key="your-api-key-here")

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=300,
    messages=[
        {"role": "user", "content": prompt}
    ]
)

print(response.content[0].text)

And that's it. That's a full, real, working RAG pipeline from raw text documents all the way to a grounded answer. Everything above this line is the entire concept. Everything real world RAG systems add on top is just making these same seven steps faster, cheaper, and more accurate at a bigger scale.

What changes when you go from this toy example to a real project

The core idea never changes, but a few things get more serious once you're dealing with thousands of documents instead of five sentences.

Instead of storing embeddings in a plain Python list, you'd use an actual vector database like Chroma, Pinecone, or Weaviate, which are built to search through millions of these number lists quickly.

Instead of writing your documents directly in the code, you'd load them from PDFs, websites, or a database, and you'd need a proper chunking strategy, usually a few hundred words per chunk with some overlap between chunks.

You'd also want to handle the case where nothing relevant gets found at all, and make sure the model actually says "I don't know" instead of making something up, which is why that instruction in the prompt matters so much.

And you'd probably want to periodically re run the embedding step whenever your source documents change, otherwise you end up answering questions using outdated information without any warning that something's wrong.

None of that changes the underlying idea though. It's still just search, then answer using what you found. Everything else is refinement.

Where you'll actually run into this in daily life

Once you understand this, you start noticing it everywhere. That chatbot on a company's website that somehow knows details specific to your account and their exact policies, probably running some version of this. Tools that let you upload a PDF and "chat" with it, same idea, your PDF gets chunked and embedded, then your questions get matched against those chunks. Even code editors that can answer questions about your specific codebase are usually doing something similar, searching your actual files for relevant code before answering, instead of relying purely on what the model happened to learn during training.

Once you see the pattern, these products stop feeling like unexplainable magic and start feeling like something you could genuinely build yourself over a weekend, because now you actually have.

A small challenge if you want to actually learn this properly

Reading code is fine but it won't stick the way building something does. Try this, take ten notes or documents about anything you actually care about, your recipes, your class notes, your journal entries, whatever, and run them through the code above. Ask questions and watch what gets retrieved. Try asking things using totally different words than what's in your notes and see if it still finds the right chunk. Then try breaking it on purpose, ask something that isn't covered in your notes at all and see if your prompt instruction actually makes it say "I don't know" instead of guessing.

I Built a "Chat With Your Docs" Tool and Finally Understood RAG

Syed Muhammad Ali Raza — Tue, 28 Jul 2026 05:58:21 +0000

I Built a "Chat With Your Docs" Tool and Finally Understood RAG

There's a specific kind of frustration that comes from asking an LLM a question about your own codebase, or your own company's internal docs, and watching it confidently make something up. Not because it's broken because it genuinely has no way of knowing what's in a folder on your laptop, or a Notion page behind your company's login wall. It was trained on a giant snapshot of public text a while ago, and that's the entire universe it has access to unless you feed it something else.

The first time I tried to fix this, my instinct was "fine tuning must be the answer I'll just train it on my data." That turned out to be the wrong tool for the job, and expensive, and slow to iterate on. What I actually wanted has a name: RetrievalAugmented Generation, or RAG. And once I built a small version of it myself, the concept stopped feeling like a buzzword and started feeling almost embarrassingly simple.

Here's what I learned building one, including the parts that tripped me up.

The Idea, Stripped of Jargon

RAG boils down to one sentence: before you ask the model a question, go find the relevant text yourself, and hand it to the model along with the question.

That's the whole trick. Instead of hoping the model "knows" the answer from training, you do the lookup search your documents, pull out the parts that seem relevant and paste those chunks into the prompt. The model then answers based on what's sitting right in front of it, not what it vaguely remembers from training data that might be a year out of date or might not include your content at all.

It's the AI equivalent of an openbook exam. You're not testing what the model memorized. You're handing it the book, open to the right page, and asking it to read and answer.

The reason this works so well in practice is that LLMs are genuinely excellent at synthesizing and summarizing text that's directly in front of them that's much closer to their core strength than recalling obscure facts from training. RAG plays to that strength instead of fighting it.

Why Not Just Paste Everything Into the Prompt?

My first "implementation" of RAG, before I knew what I was doing, was literally copypasting an entire document into the chat window before asking my question. That works fine for a fivepage PDF. It falls apart fast once you're dealing with hundreds of documents, a large codebase, or a knowledge base that doesn't fit in any context window no matter how generous.

Even when things technically fit, there's a cost problem you're paying (in tokens, in latency) to feed the model a bunch of irrelevant text alongside the two paragraphs that actually matter. So the real engineering problem RAG solves isn't "how do I give the model my data," it's "how do I automatically find and hand it only the small slice of my data that's actually relevant to this specific question."

That's where the interesting part starts.

The Pieces That Actually Make It Work

Chunking

You can't search a giant document as one blob effectively, so the first step is breaking it into smaller pieces a paragraph, a few sentences, a section. I underestimated how much this step matters. Chunk too large, and you dilute the relevant bit with a bunch of noise. Chunk too small, and you lose context a sentence pulled out of its surrounding paragraph can be almost meaningless on its own.

I ended up landing on chunks of a few hundred words with a bit of overlap between consecutive chunks, so a sentence that happens to sit right at a chunk boundary doesn't get orphaned from its context. This isn't some universal magic number it took a fair amount of trial and error looking at what actually got retrieved for real questions before it felt right.

Embeddings

This was the part that felt like magic until I sat down and actually understood it. An embedding model takes a piece of text and converts it into a list of numbers a vector positioned in a highdimensional space such that texts with similar meaning end up close together in that space, and unrelated texts end up far apart.

So "the cat sat on the mat" and "a feline rested on the rug" very different words, similar meaning would land near each other in this space. That's the property that makes semantic search possible: you're not matching keywords, you're matching meaning.

You run every chunk of your documents through this embedding model once, ahead of time, and store the resulting vectors. When a user asks a question, you embed the question the same way, then look for the stored chunks whose vectors are closest to it.

Vector Storage and Search

Those embeddings need to live somewhere you can search efficiently. For a side project, something lightweight is genuinely enough I started with a simple local vector store and only reached for something like Pinecone or a managed vector database once I actually had a scale problem, not before. A common mistake I see (and made myself) is reaching for heavy infrastructure before confirming the basic approach even works on a small scale.

The search step itself is just "find the k chunks whose vectors are closest to the question's vector" usually using cosine similarity. In practice, retrieving somewhere around three to eight chunks worked well for me; too few and you risk missing the answer, too many and you're back to diluting the prompt with noise.

Assembling the Prompt

This is the step that's easy to gloss over but matters a lot. Once you have your retrieved chunks, you don't just dump them in you construct a prompt that makes it explicit what the model should do with them. Something along the lines of:

You are answering questions using only the context provided below.
If the answer isn't in the context, say you don't know  don't guess.

Context:
[retrieved chunk 1]
[retrieved chunk 2]
[retrieved chunk 3]

Question: {user's question}

That instruction to say "I don't know" rather than guess turned out to be one of the highest-leverage lines in the whole system. Without it, the model will happily blend its own background knowledge with your retrieved context, and you lose the whole point of grounding it in your actual data. With it, you get much more honest "the docs don't cover this" responses instead of confident nonsense.

Where Mine Broke (And What That Taught Me)

The first version I built worked shockingly well on obvious test questions and then fell over on real ones. A few lessons from debugging it:

Retrieval quality matters more than prompt cleverness. I spent an embarrassing amount of time tweaking my prompt template before realizing the actual problem was upstream the wrong chunks were being retrieved in the first place. No prompt engineering fixes bad retrieval. If the right information never makes it into the context, the model has no chance.

Questions phrased differently than the source text can miss. Semantic search is good, not psychic. A question asking "how do I cancel my plan" might not retrieve a doc chunk titled "Subscription Termination Process" as strongly as you'd hope, depending on the embedding model. This pushed me toward also trying a hybrid approach combining semantic search with old-fashioned keyword search which noticeably improved recall on edge cases.

Stale data is a silent failure mode. If your source documents change and you don't re-run the embedding step on the updated content, you'll keep serving confidently wrong answers based on outdated chunks, and nothing in the system will warn you. This is an unglamorous but very real operational concern once you're running one of these for real.

Evaluating "is this a good answer" is genuinely hard. Unlike a typical software bug, there's no clean pass/fail. I ended up building a small set of test questions with known correct answers and periodically eyeballing whether changes to chunking or retrieval helped or hurt, which is a pretty manual process but better than flying blind.

Where This Fits Into the Bigger Picture

Once I understood RAG at this level, a lot of AI products I'd used casually suddenly made more sense. "Chat with your PDF" tools, internal company knowledge bots, customer support assistants that somehow know your specific order history most of these aren't relying on some enormous finetuned model that magically knows everything. They're running some version of the retrievethengenerate loop described above, often with a fair amount of extra plumbing around chunking strategy, reranking, and prompt construction.

It also reframed how I think about "does the model know X." The more useful question, most of the time, isn't whether the model was trained on something it's whether you can retrieve the right information and hand it over at the moment it's needed. That shift in thinking has been more useful to me day to day than any specific prompting trick.

If you're looking for a genuinely good weekend project to understand this stuff at a level deeper than reading about it, building a small RAG pipeline over your own notes or a folder of PDFs is a great one. It's small enough to finish in a weekend, and it touches almost every practical concept that shows up in production AI systems embeddings, search, prompt construction, and the very real gap between "works on my test question" and "works reliably."

What's Actually Going On Inside an LLM (And Why Your Prompts Keep Failing)

Syed Muhammad Ali Raza — Mon, 27 Jul 2026 06:04:59 +0000

A few months into using ChatGPT and Claude daily for work, I hit a wall. Some days the model felt like magic it would write exactly the function I needed, catch a bug I'd missed, explain a concept better than any textbook. Other days, the same tool would confidently give me garbage. Wrong API names. Made-up library functions. Code that looked right but silently did the wrong thing.

For a while I chalked this up to "the AI being inconsistent." Eventually I realized the inconsistency was mostly on my end. I didn't actually understand what these models were doing under the hood, so I had no framework for knowing when to trust them, when to double-check them, or how to ask for what I actually wanted. Once I started treating prompting as an actual skill instead of "just typing a question," the quality of what I got back changed dramatically.

This is the article I wish someone had handed me back then.

Forget "AI." Think "Autocomplete on Steroids."

The most useful mental shift I made was dropping the sci-fi framing entirely. An LLM is not a mind. It's not reasoning about the world the way you or I do. At its core, it's a system trained on an enormous pile of text to do one job: given everything written so far, predict what token comes next.

A token isn't quite a word — it's more like a chunk of a word. "Understanding" might get split into "under," "stand," and "ing," for example. The model doesn't see letters or meaning directly. It sees these chunks, converts them into number patterns, and repeatedly asks itself "given this pattern so far, what's statistically likely to come next?" It does this one token at a time, feeding its own output back in as it goes.

That's genuinely it. There's no internal database being queried, no fact-checker running in the background, no persistent understanding of your codebase sitting there waiting. Everything the model "knows" is baked into billions of parameters shaped during training, and everything it produces is a very sophisticated guess based on patterns.

Once that clicked for me, a lot of weird behavior stopped being mysterious. Of course it confidently invents a library function that doesn't exist somewhere in its training data, that pattern of "here's a plausible-sounding function name for this task" was common enough to reproduce. It's not lying. It doesn't know the difference between "real" and "plausible." Prompting well is largely about closing that gap.

The Memory Problem Nobody Warns You About

Here's something that tripped me up constantly early on: the model doesn't remember your last conversation unless the product you're using specifically layers memory on top (and even then, it's usually a summarized version, not the full transcript).

Every single time you start a new chat, you're talking to a version of the model with zero knowledge of anything you've discussed before. It doesn't know your codebase, your company's conventions, your past preferences, or that you already told it three times not to use a particular library. You have to re-establish all of that context, every time, unless you're deliberately carrying it forward yourself.

This also applies within a single long conversation. There's a limit the "context window" to how much text the model can actively hold in view at once. Modern models have gotten genuinely good at handling long contexts, but I've still noticed that details buried in the middle of a very long conversation get "forgotten" more easily than things stated near the beginning or end. If something is important, it's worth restating it rather than assuming the model still has it front of mind.

Why the Same Question Gets You Different Answers

If you've ever asked an LLM the exact same question twice and gotten two different answers, that's not a bug. These models generate text probabilistically — at each step, there's a distribution of plausible next tokens, and the model samples from that distribution rather than always picking the single most likely one. This is actually intentional; picking the "safest" token every single time tends to produce dull, repetitive text.

The practical takeaway: don't treat a single response as ground truth, especially for anything factual or high-stakes. If accuracy matters, ask again, ask it to double-check itself, or verify independently. I've caught real mistakes just by asking "are you sure about that?" not because the model has some hidden self-awareness, but because the follow-up prompt gives it another shot at generating a better-calibrated answer.

The Prompting Habits That Actually Moved the Needle for Me

I went through the usual phase of collecting "magic prompt" lists from Twitter threads. Most of it was noise. What actually helped was much less exotic than I expected.

Writing the prompt like I'm briefing a smart contractor who's never seen my project. Not a genius who can read my mind — a competent person who needs the actual context. What's the tech stack? What have I already tried? What does "good" look like here? The lazier my prompt, the lazier and more generic the output.

Giving examples instead of describing what I want in the abstract. This one surprised me with how much of a difference it makes. If I want text reformatted a certain way, showing the model one or two input/output pairs almost always beats three paragraphs explaining the rules. It's the difference between describing a chair to someone versus just pointing at one.

Asking for reasoning before the answer, on anything nontrivial. For simple lookups this doesn't matter. But for debugging, architecture decisions, or anything involving multiple steps, explicitly asking the model to "think through this step by step before giving your final answer" noticeably reduces sloppy mistakes. It's forcing the model to lay out its own logic where it and I can spot errors, instead of jumping straight to a confident-sounding conclusion.

Telling it what NOT to do. I underestimated this for a long time. "Don't use any external dependencies," "avoid marketing language," "don't just restate the question" negative constraints cut out a huge amount of the generic filler these models default to.

Treating it as a back-and-forth, not a vending machine. My first prompt is rarely my best one. I've stopped expecting a perfect answer on the first try and started treating the process more like pairing with someone: get a draft, point out specifically what's off, iterate. This alone probably improved my results more than any specific technique.

Where This Gets Genuinely More Advanced

Once basic prompting stops being the bottleneck, there's a whole layer of stuff worth knowing about, even if you're not building AI products yourself:

Retrieval-augmented generation (RAG) is the fancy term for something intuitive: instead of relying on what the model memorized during training, you fetch relevant documents or data at request time and stuff them into the prompt. This is how a lot of "chat with your docs" tools work, and it's a big part of why some AI products feel much more accurate than raw ChatGPT they're not relying purely on the model's internal knowledge.

Tool use / function calling lets a model call external code hit an API, run a calculation, query a database instead of just generating text and hoping it's right. This is a huge deal in practice because it moves things like arithmetic, live data lookups, and factual retrieval away from "the model's best guess" and toward "an actual deterministic system."

Agents are essentially LLMs given a loop: take an action, observe the result, decide the next action, repeat, usually with some memory of what's happened so far. This is what's behind coding assistants that can browse a codebase, run tests, and fix their own mistakes rather than just producing a single response.

I'd hold off on diving deep into any of these until basic prompting feels comfortable. It's a bit like learning to debug before you learn a framework the fundamentals compound.

The One Thing I'd Tell Past Me

Stop treating the model like it either "knows" or "doesn't know" things, full stop. Treat it like a very well-read collaborator who's fast, tireless, occasionally brilliant, and prone to confidently bluffing when it's out of its depth much like a smart intern who hasn't yet learned to say "I'm not sure." Once you internalize that, you stop being surprised by the failures and start getting a lot more consistent value out of the successes.

If you're just starting to work with these tools seriously, don't expect to be good at this after one afternoon of playing with ChatGPT. It took me actively paying attention to what worked and what didn't over weeks of daily use before it clicked. But it does click and once it does, it's hard to go back to writing vague one-line prompts and hoping for the best.

How to Start a Career in AI/ML: A Complete Roadmap for Beginners

Syed Muhammad Ali Raza — Fri, 24 Jul 2026 06:41:33 +0000

How to Start a Career in AI/ML: A Complete Roadmap for Beginners

Artificial Intelligence and Machine Learning are no longer "future" skills they're already reshaping how software is built, how businesses make decisions, and how products are designed. If you're a developer, student, or career-switcher wondering how to break into this field, the good news is: you don't need a PhD or a decade of math courses to get started. You need a clear path and consistent effort.

This article lays out a practical, no-fluff roadmap to help you go from "complete beginner" to "job-ready AI/ML practitioner."

Why AI/ML Is Worth Learning Right Now

Before diving into the "how," it's worth understanding the "why":

Demand is exploding. Companies across every industry healthcare, finance, retail, logistics are hiring for ML engineers, data scientists, and AI application developers.
The barrier to entry is lower than ever. Tools like scikit-learn, PyTorch, and high-level APIs (OpenAI, Anthropic, Hugging Face) let you build real things without writing algorithms from scratch.
It's not just for "math geniuses." Applied AI/ML roles today lean heavily on engineering, problem-solving, and communication — not just theoretical math.

Step 1: Get Comfortable with the Fundamentals

You don't need to master everything before you start building, but a working foundation will save you a lot of confusion later.

Math (the practical minimum)

Linear algebra vectors, matrices, dot products (used constantly in ML models)
Probability & statistics distributions, mean/variance, Bayes' theorem
Calculus basics derivatives and gradients (enough to understand gradient descent)

You don't need to be a math expert. Aim for intuitive understanding, not textbook mastery.

Programming

Python is the standard language for AI/ML. Learn it well before moving forward.
Get comfortable with NumPy, Pandas, and Matplotlib the everyday toolkit for data manipulation and visualization.

Core ML Concepts

Understand these before touching frameworks:

Supervised vs. unsupervised vs. reinforcement learning
Training, validation, and test sets
Overfitting vs. underfitting
Bias-variance tradeoff
Common algorithms: linear/logistic regression, decision trees, k-means, k-NN

Step 2: Learn the Tools of the Trade

Once fundamentals click, move into hands-on tools:

scikit-learn the best starting point for classical ML (regression, classification, clustering)
TensorFlow or PyTorch for deep learning; PyTorch is currently the most popular in research and increasingly in industry
Jupyter Notebooks for experimenting and visualizing as you learn
Hugging Face for working with pretrained models (NLP, vision, and beyond)
Git/GitHub non-negotiable for any developer role; you'll use it to showcase projects

Step 3: Build Real Projects (This Is Where Learning Sticks)

Tutorials teach you syntax. Projects teach you how to think. Don't skip this step.

Start simple and increase complexity over time:

Beginner: Predict house prices with linear regression, classify iris flowers, build a spam detector
Intermediate: Image classifier with CNNs, sentiment analysis on tweets, a recommendation system
Advanced: Fine-tune a pretrained transformer model, build an end-to-end ML pipeline with deployment, create a small LLM-powered app using an API

For each project:

Push the code to GitHub
Write a clear README explaining the problem, approach, and results
Reflect on what you learned and what you'd improve

This portfolio becomes your proof of skill often more valuable than a certificate.

Step 4: Learn to Think Like an ML Engineer, Not Just a Modeler

A common beginner trap is obsessing over model accuracy while ignoring everything else that matters in real-world AI/ML work:

Data quality garbage in, garbage out. Learn data cleaning and feature engineering deeply.
Evaluation metrics know when to use precision/recall vs. accuracy vs. F1-score, and why it matters.
Deployment basics learn how models go from notebook to production (Flask/FastAPI, Docker, basic cloud deployment).
MLOps awareness even a basic understanding of model monitoring, versioning, and retraining will set you apart.

Step 5: Specialize (Eventually)

AI/ML is broad. Once you have the basics down, pick a direction that excites you:

NLP chatbots, language models, text analysis
Computer Vision image/video recognition, object detection
Recommender Systems personalization engines
MLOps/Infrastructure deploying and scaling ML systems
Applied AI / LLM Engineering building products on top of foundation models (a fast-growing niche right now)

You don't need to pick immediately explore first, specialize once something clicks.

Step 6: Build Your Presence and Network

Technical skill alone doesn't guarantee a job visibility helps a lot.

Write about what you learn. Explaining a concept (like you're doing by reading this!) solidifies your understanding and builds credibility. Platforms like dev.to are great for this.
Contribute to open source. Even small contributions to ML libraries or projects show initiative.
Join communities. Kaggle, Hugging Face forums, and AI-focused Discord/Slack groups are great for learning and networking.
Enter competitions. Kaggle competitions are a fantastic way to test your skills against real problems and see how others approach them.

Step 7: Prepare for the Job Search

When you're ready to apply:

Tailor your resume to highlight projects, not just courses.
Practice explaining your projects clearly interviewers care as much about your thought process as your results.
Study common interview topics: ML fundamentals, coding (data structures/algorithms), SQL, and case studies ("how would you approach building X system?").
Consider internships or freelance work if full-time roles feel out of reach initially — real-world experience, even small, compounds quickly.

A Realistic Timeline

Everyone's pace differs, but a reasonable roadmap looks like:

Phase	Focus	Duration
Foundations	Python, math basics, core ML concepts	2–3 months
Tools & Projects	scikit-learn, PyTorch/TensorFlow, portfolio projects	3–4 months
Specialization	Deep dive into a chosen niche	2–3 months
Job Prep	Networking, interviews, applications	Ongoing

Total: roughly 6–12 months of consistent effort to become job-ready, depending on your starting point and time commitment.

Final Thoughts

Breaking into AI/ML isn't about consuming endless courses it's about building, iterating, and sharing what you learn along the way. Focus on fundamentals, get your hands dirty with real projects, and don't wait until you "know everything" to start applying or writing about your journey.

The field moves fast, but that also means there's room for newcomers who are willing to learn in public and keep building. Start today your future self (and your GitHub contribution graph) will thank you.

If you found this useful, feel free to follow @syedmuhammadaliraza for more beginner-friendly content on AI/ML, software engineering, and career growth in tech.

Multi Language Support in Your React & Next JS App

Syed Muhammad Ali Raza — Fri, 17 Jul 2026 06:00:53 +0000

How to Add Multi Language Support to Your React App Using react i18next

As a frontend developer there comes a time when your React app needs to speak than one language. Whether you are building for an audience or planning ahead internationalization is a must have.

In this guide I will walk you through setting up react i18next. The popular internationalization library for React with over 6.3 million weekly downloads.

What Is Internationalization. Why Do You Need It?

Internationalization means designing your app so it can support languages without rewriting code. Think of it as laying the foundation. Localization is what comes after. Actually translating the content.

With react i18next you can:

Move all user facing text into JSON translation files
Switch languages dynamically without page reloads
Handle plurals, variables and even HTML inside translations
Load the translations your user needs

Step 1: Installation

First install the core packages. You need both i18next. React i18next.


npm install react-i18next i18next --save

You need both because i18next does the lifting. Managing languages, pluralization, formatting. React i18next gives you React tools like the useTranslation hook and Trans component.

For production apps you will likely want two packages:


npm install i18next-http-backend i18next-browser-languagedetector --save

i18next-http-backend: Loads translation JSON files from your public folder
i18next-browser-languagedetector: Automatically detects the users preferred language from browser settings, cookies or localStorage

Step 2: Set Up the Configuration

Create a file called i18n.js in your src folder.


import i18n from 'i18next';

import { initReactI18next } from 'react-i18next';

import Backend from 'i18next-http-backend';

import LanguageDetector from 'i18next-browser-languagedetector';

i18n

.use(Backend)

.use(LanguageDetector)

.use(initReactI18next)

.init({

fallbackLng: 'en'

debug:

interpolation: {

escapeValue: false,

}

});

export default i18n;

The escapeValue is set to false because React already handles XSS protection.

Step 3: Connect to Your React App

Import the i18n configuration in your entry file before rendering your app.


import React from 'react';

import { createRoot } from 'react-dom/client';

import './i18n';

import App from './App';

const root = createRoot(document.getElementById('root'));

root.render(<App />);

Step 4: Create Your Translation Files

By default i18next looks for translation files in public/locales/[language]/translation.json.

Create this folder structure:


public/

locales/

en/

translation.json

fr/

translation.json

es/

translation.json

translation file:


{

"welcome": "Welcome to my app"

"greeting": "Hello, {{name}}!"

"itemCount": "You have {{count}} item"

"itemCount_plural": "You have {{count}} items"

}

translation file:


{

"welcome": "Bienvenue sur mon app"

"greeting": "Bonjour, {{name}} !"

"itemCount": "Vous avez {{count}} article"

"itemCount_plural": "Vous avez {{count}} articles"

}

Keep your JSON keys consistent across all languages. Use. Group related strings into namespaces.

Step 5: Use Translations in Your Components

The useTranslation Hook

The way to translate in functional components:


import React from 'react';

import { useTranslation } from 'react-i18next';

function WelcomeMessage() {

const { t } = useTranslation();

return (

<div>

<h1>{t('welcome')}</h1>

<p>{t('greeting' { name: 'Alex' })}</p>

<p>{t('itemCount' { count: 5 })}</p>

</div>

);

}

export default WelcomeMessage;

When the language changes, everything re-renders automatically. No page reload needed.

Handling Plurals

i18next follows CLDR rules so it handles complex pluralization across languages. Just define _ keys in your JSON:


{

"message": "{{count}} item"

"message_plural": "{{count}} items"

}


const { t } = useTranslation();

t('message' { count: 0 });

t('message' { count: 1 });

t('message' { count: 3 });

The Trans Component for HTML and JSX

When your translation includes links, bold text or React components use the Trans component instead of concatenating strings.


import { Trans } from 'react-i18next';

function Message() {

return (

<Trans>

Hello <strong>world</strong> check out our <a href="/docs">docs</a>.

</Trans>

);

}

In your translation file use numbered tags to match the JSX structure:


{

"Hello <1>world</1> check out our <3>docs</3>.": "Bonjour <1>le monde</1>, consultez notre <3>documentation</3>."

}

The Trans component maps <1> to the child element <2> to the second and so on.

Step 6: Add a Language Switcher

Let users change languages on the fly:


import React from 'react';

import { useTranslation } from 'react-i18next';

function LanguageSwitcher() {

const { i18n } = useTranslation();

const changeLanguage = (lang) => {

i18n.changeLanguage(lang);

};

return (

<div>

<button onClick={() => changeLanguage('en')}>English</button>

<button onClick={() => changeLanguage('fr')}>Français</button>

<button onClick={() => changeLanguage('es)}>Español</button>

</div>

);

}

export default LanguageSwitcher;

When you call i18n.changeLanguage() i18next loads the translation file and triggers a re-render of all components using useTranslation.

Step 7: Organize with Namespaces

As your app grows putting everything in one translation.json becomes messy. Namespaces let you split translations by feature.

Folder structure:


/locales/en/

common.json

dashboard.json

profile.json


// Load only what you need

const { t } = useTranslation('dashboard');

//. Load multiple

const { t } = useTranslation(['dashboard' 'common']);

Using namespaces improves performance by loading only the translations needed for the current view.

Project Structure Recap

Here's what a organized internationalization setup looks like:


src/

├── i18n.js          # i18next configuration

├── index.js         # Import i18n.js here

├── components/

│   ├── Welcome.jsx

│   └── LanguageSwitcher.jsx

└── App.jsx

public/

└── locales/

├── en/

│   ├── translation.json

│   └── dashboard.json

└── fr/

├── translation.json

└── dashboard.json

React Interview Prep: 50+ Problems Every Frontend Dev Should Know

Syed Muhammad Ali Raza — Fri, 31 Oct 2025 09:48:49 +0000

If I’m testing your React knowledge in a Frontend interview, I’m definitely going to ask 1–2 questions out of these 50+ problems (collected over my 12+ years of exp.)

These cover everything :
→ Component design and reusability
→ State management and hooks
→ Handling user interactions and events
→ Accessibility and ARIA roles
→ Optimizing rendering and performance
→ Working with external data and APIs

➥UI/Component Building

Memory Game
Image Carousel
Image Carousel II (smooth transitions)
Digital Clock
Analog Clock
Whack-A-Mole
Tic-tac-toe
Tic-tac-toe II (N x N, variable win condition)
Connect Four
Modal Dialog
Modal Dialog II (ARIA roles, semi-accessible)
Modal Dialog III (common close methods, moderately accessible)
Accordion II (accessible, ARIA support)
Accordion III (full keyboard support, ARIA)
Tabs
Tabs II (semi-accessible)
Tabs III (keyboard/ARIA spec)
Star Rating
Like Button
Progress Bars III (multiple concurrent, pause/resume)
Progress Bars II (sequential fill, one at a time)
Grid Lights
Traffic Light
Data Table
Data Table II (sorting)
Data Table III (pagination, sorting)
Data Table IV (pagination, sorting, filtering)
Nested Checkboxes (parent-child selection logic)
File Explorer
File Explorer II (ARIA roles, semi-accessible)
File Explorer III (flat DOM)
Table of Contents (HTML parsing, tree)
Selectable Cells (drag-select grid)
Auth Code Input (6-digit entry)
Modal Dialog IV (fully accessible, keyboard support)
Undoable Counter (undo/redo)
Pixel Art (drawing grid)
Todo List

➥Logic/Algorithmic & Data Handling

Birth Year Histogram (API + plotting)
Job Board (API data + rendering)
Transfer List
Transfer List II (bulk select, add, transfer)
Users Database (CRUD)
Dice Roller
Backbone Model (custom object store)
Data Selection (filtering)
getElementsByTagNameHierarchy (DOM queries)
Curry III (JS currying logic)
Classnames II (join/dedupe classnames)
Heap (implement data structure)
Heap Operations
End of Array Reachable (jump game)
Find the Longest Palindromic Substring
Find Words in Grid
Find Word in Grid (existence check)
Shortest Substring Containing Characters
Disjoint Intervals (remove overlaps)
Minimum Meeting Rooms Needed
Graph Clone (deep copy graph)
Binary Tree Serialization and Deserialization
Binary Tree Maximum Total Path
Binary Tree Rebuilding from Preorder/Inorder
Graph Count Connected Components
Number Stream Median
Linked Lists Combine K Sorted

➥Custom Hooks

useDebounce
useEventListener
useHover
useInterval
useKeyPress
useMap
useObject
useSet
useStep
useThrottle
useTimeout
useWindowSize
useIdle
useInputControl
useMediaQuery
useMediatedState
useQuery
useArray
useBreakpoint
useClickOutside
useCountdown

If you can build, debug, and explain at least half of these, you’re already ahead of 90% of candidates.

Frontend Challenge - Halloween Edition

Syed Muhammad Ali Raza — Fri, 31 Oct 2025 06:55:40 +0000

This is a submission for Frontend Challenge - Halloween Edition, Perfect Landing

What I Built

I built the Spooky Heritage Museum landing page—an interactive experience that takes visitors through Halloween’s history. The page includes:
Animated Hero Section: Full-screen intro with a glowing moon, twinkling stars, floating ghosts, and bats flying across. Typography uses the "Creepster" font.

Interactive Timeline: A vertical timeline showing Halloween’s evolution from ancient Celtic Samhain to modern trick-or-treating. Timeline items animate into view on scroll and alternate left/right.
Exhibit Showcase: Four featured exhibits with hover lift/glow effects. Clicking opens modal dialogs (replacing alerts).
Events Section: Calendar-style event cards for upcoming activities like midnight ghost tours and pumpkin carving workshops.
Reservation System: A validated form with real-time email, date, and guest limit checks, plus clear error messages.

The design uses a purple-to-orange gradient with dark backgrounds that make orange accents pop, plus yellow highlights for a warm, candlelit feel.

Demo

Demo Link
https://github.com/Syed-Muhammad-Ali-Raza/Halloween-Landing-Challenge-

Journey

The Concept

I started with the museum theme because museums are about discovery, and Halloween has a rich, often untold history. I wanted storytelling and education, not just scares.

Challenges & Solutions

Smooth animations: The floating ghosts and bats needed randomness. I varied animation durations and delays per element and used transforms for organic arcs instead of straight lines.
Timeline layout: Alternating left/right on desktop, stacking on mobile took careful positioning. CSS Grid and Flexbox handled it, but getting margins right required multiple iterations.
Form validation: HTML5 validation wasn’t enough. I added real-time validation with inline error messages, ARIA attributes, and visual states (green for valid, red for errors). The date picker sets today as the minimum automatically.

What I'm Proud Of

Accessibility: Skip links, ARIA labels, keyboard navigation, focus indicators, and prefers-reduced-motion support.
Mobile menu: Hamburger-to-X transition with staggered menu item animations.
Modals: Replaced alerts with accessible modals that fade in, trap focus, and close on Escape or outside click.
Performance: Vanilla JavaScript with IntersectionObserver for scroll animations—fast and smooth.

Tech Stack

Pure HTML, CSS, and vanilla JavaScript—no build process. CSS Custom Properties make theme tweaks easy, and Grid/Flexbox handle layouts. backdrop-filter adds frosted glass effects with graceful degradation.

Frontend Challenge - Halloween Edition

Syed Muhammad Ali Raza — Fri, 31 Oct 2025 06:08:03 +0000

This is a submission for Frontend Challenge - Halloween Edition, CSS Art.

Inspiration

Classic Halloween imagery inspired this scene:

Haunted Victorian houses with flickering candlelit windows
Jack-o-lanterns with glowing faces
Bats in the night sky
Floating ghosts
Graveyards with tombstones
Moonlit nights

Demo

https://codepen.io/Syed-Muhammad-Ali-Raza/pen/YPwOMbP
For complete code you can check out this Github repo
https://github.com/Syed-Muhammad-Ali-Raza/Halloween-Challenge

Journey

Started with a layout plan, then built elements from back to front:

sky
house
pumpkin
ghost
bats
tombstones

Using clip-path for complex shapes (pumpkin face features)
Layering gradients and radial gradients for lighting
Coordinating multiple animations with different delays
and durations Pseudo-elements (::before, ::after)
for details Transform and animation keyframes for movement

GitHub repos that will make you a 10x software engineer: 1 Vision agent https://lnkd.in/e-ZHJTqc 2 System design https://lnkd.in/e7SUQ3ei 3 Public APIs https://lnkd.in/epWSyzqs 4 Tech interview handbook https://lnkd.in/e7EjsJNF

Syed Muhammad Ali Raza — Thu, 23 Oct 2025 13:38:04 +0000

This link will take you to a page that’s not on LinkedIn

lnkd.in

This link will take you to a page that’s not on LinkedIn

lnkd.in

This link will take you to a page that’s not on LinkedIn

lnkd.in

This link will take you to a page that’s not on LinkedIn

lnkd.in

JavaScript feels tricky until you master its language. Once you truly understand these core words, the rest becomes 10x easier. Strong concepts = Clean code = Confident developer. What was the one JavaScript term that finally clicked for you?

Syed Muhammad Ali Raza — Thu, 18 Sep 2025 13:08:33 +0000

Frontend Developer Roadmap for Junior & Senior Developer's

Syed Muhammad Ali Raza — Mon, 16 Dec 2024 17:04:29 +0000

♣ Frontend Developer Roadmap For Junior Developers:

🧩 Phase 1: Foundations of Frontend Development

HTML, CSS, JavaScript
- Semantic HTML
- Modern CSS (Flexbox, Grid, Variables)
- JavaScript ES6+ features (let/const, classes, async/await)
DOM Manipulation
- Event handling and propagation
- Working with the DOM API
- Basic performance considerations
Version Control
- Git basics (branching, merging, pull requests)
- Working with GitHub/GitLab/Bitbucket

🧩 Phase 2: UI Development and Design

CSS Frameworks & Preprocessors
- TailwindCSS, Bootstrap, SASS/SCSS
Responsive Design
- Media queries
- Mobile-first vs Desktop-first design
Component-Based Architecture
- Introduction to React, Vue, or Angular
- Building reusable components
- State and props management

🧩 Phase 3: Data Fetching and APIs

HTTP Basics
- REST APIs, GraphQL basics
- Fetch API and Axios for API requests
State Management
- Local state (useState, Vue's data)
- Context API for global state
Error Handling
- Basic error handling and retries
- Loading and error states in the UI

🧩Phase 4: Performance Optimization

Web Performance Metrics
- Core Web Vitals (LCP, FID, CLS)
Asset Optimization
- Image compression and lazy loading
- Minification of CSS/JS
Rendering Basics
- Client-Side Rendering (CSR)
- Understanding rendering lifecycle in React/Vue

🧩Phase 5: Security Basics

Common Vulnerabilities
- XSS (Cross-Site Scripting)
- CSRF (Cross-Site Request Forgery)
- CORS (Cross-Origin Resource Sharing)
Best Practices
- Secure cookies and basic HTTP headers
- Sanitizing user input

🧩Phase 6: Testing and Debugging

Debugging Tools
- Chrome DevTools basics
Unit Testing
- Introduction to Jest, Mocha, or Jasmine
Basic Monitoring
- Browser console logs
- Simple crash/error reports

🧩 Phase 7: Build Tools and Deployment

Tooling
- NPM/Yarn package managers
- Introduction to bundlers like Webpack, Vite, or Parcel
Deployment
- Hosting with Vercel, Netlify, or GitHub Pages
- CI/CD basics
Junior Engineers: Focus on mastering the basics, frameworks, and deployments. Build confidence in delivering small to medium features.
Senior Engineers: Dive deep into architecture, testing, performance optimization, and scalability while mentoring others.

🔥 Roadmap For Senior Frontend Engineers

🧩 Phase 1: Advanced JavaScript and Frameworks

Deep Dive into JavaScript
- Closures, hoisting, event loop, and prototypes
- Performance optimization (Debouncing, Throttling)
Advanced Framework Knowledge
- React: Advanced hooks, memoization, error boundaries
- Vue: Vuex/Pinia state management
- Angular: Dependency Injection and RxJS
Server-Side Rendering (SSR)
- Next.js for React
- Nuxt.js for Vue

🧩 Phase 2: Architecture and State Management

State Management at Scale
- Redux, Zustand, Recoil (React)
- Pinia/Vuex (Vue)
- Understanding global vs local state
Component Architecture
- Container vs Presentational components
- Design Systems and reusable libraries
API Handling
- GraphQL basics and Apollo Client
- Error boundaries, retries, and fallbacks

🧩 Phase 3: Performance Optimization

Core Web Vitals
- LCP, FID, CLS
- Code splitting and lazy loading
Optimization Techniques
- Bundle analysis and tree shaking
- Server-Side Rendering and pre-rendering
Advanced Rendering Concepts
- Virtual DOM, reconciliation
- Concurrent rendering in React

🧩Phase 4: Testing and Debugging

Advanced Testing
- Unit testing: Jest, Mocha
- Integration testing with React Testing Library or Cypress
- Snapshot testing
Error Monitoring and Debugging
- Tools: Sentry, LogRocket, or Datadog

🧩 Phase 5: Security and Best Practices

Web Security
- XSS, CSRF, CORS
- Content Security Policies (CSP)
Secure Cookies and Storage
- HttpOnly, Secure flags
- Handling tokens (JWTs) safely

🧩Phase 6: Advanced Tooling and CI/CD

Tooling
- Webpack, Rollup, or Vite for advanced bundling
- ESLint, Prettier for code consistency
CI/CD
- Integrate pipelines for automated builds and deployments
Code Review and Collaboration
- PR best practices and design discussions

🧩Phase 7: Scalability and Architecture

Micro-Frontend Architecture
- Breaking apps into smaller parts for maintainability
Monorepos
- Managing large-scale codebases with tools like Turborepo or Nx
Progressive Web Apps (PWA)
- Service workers, offline caching