Sangri sabji

 Sangri.   Raat.  Ko. Bija.  Do.   Usma. Kismis.  Karia.  Jo.  Bhi.  Dalna.   H.   Woh.   Bhi.   Raat.   Ko.  Bhija.   Do.  Namak.  Haldi.   Dalkar.  Phir.  Subah.   Sab.  Saman.  Boil.   Kar.  Lo.  1,,siti.  Phir.   Kadai. M.   Sarso.  Ka.  Oil.     Dalna.   H.  Phir.    Sangri.  Dal.   Do.  Phir.    Namak.  Haldi.   Amchur.   Rai.   Pis.  Kar.  Dalna.  H

Diwali festival celebration

Dhanteras: 

Yam. diya ki puja hoti hai. 

Aata ka chomukhi diya banta hai. Put haldi. Batti, Sarso oil , Kodi put and do Puja.

Diya keep it outside house.

Choti  Diwali: 

5/7 diya puja after eating.

Baddi.   Diwali.  Ko.   11.  Diya.  Puj.  Lana.    Pehla.   Thali.   M.   Swastik.   Bana.   Kar.   Diya.   Rakhna.   Dono.   Din

 Gañesh.  Ji.  Laksmi. Ji.   Ko.   Betha. Kar.  Puja. Karna.   H.  Halwa.  Ka.  Bhog.  Laga.  Dana

 Phool.  Ho.   To.  Rakh.  Dana.   Bhagwan.  Ji.  Ka.  Pass.   Tilak.   Kar.  Dana

 Puri.  Aloo.  Ki.  Sabji.  Sangri.   Bana.   Lana.   Atta.   Ka.  Halwa.  Bana.  Lana.  2papad.   Tal.   Lana.   Chips.  Tal.   Lana.   Urad.  Dal.  Ka.  Pakora.   Bana.   Laña.   Dahi.   Ka

 Pujà.   Kar.  K.   Khana.  Khana.   H.

Dhokla recipe

Soak 3 cup rice ,1 cup urad dal,1/4cup chana dal and 1/4  cup yellow moong daal for 5-6 hour.

Then grind it with some curd.keep it in warm place for 7-8 hours.

Whenever you want to make dhokla  take some batter and add salt ,chilli and some oil mix it properly.then add grated vegetables (lauki/beetroot/carrot) whatever you want.mix add 1/2 tsp eno add some water on it and mix it properly.then pour it in a plate a steam it for 10-15 mins.steamer must be ready before adding eno.

Linkedln

 Reflecting on how LLM‑powered tools are reshaping not just technology, but the way we work, think, and create, a few themes stand out.

1. This shift is bigger than productivity. Yes, the immediate gains are obvious—faster drafting, summarizing, coding, debugging, searching, prototyping, and analysis. But the deeper value is in attention. As routine cognitive tasks become lighter, we reclaim mental space for higher‑quality thinking: better judgment, clearer prioritization, stronger collaboration, and more intentional leadership.

The question is no longer “How fast can we move?” It becomes “What do we do with the attention these tools give back?”

2. LLMs democratize access to intelligence. Large organizations have traditionally held advantages through data, infrastructure, and scale. Those still matter, but the baseline is shifting. Today, an individual with curiosity, context, and sharp questions can learn, prototype, communicate, and build at a pace that was previously unimaginable.

Expertise doesn’t disappear—it becomes more valuable. Those who understand their domain, ask better questions, validate outputs, and connect ideas across systems will have disproportionate leverage.

3. The new paradigm demands better questions. As answers become abundant, the quality of our questions—and the quality of our judgment—becomes the differentiator.

Maybe this next phase of technology isn’t only about speed. Maybe it’s about clarity: clarity in our work, our values, and how we use technology to elevate individuals, teams, and society.

#LLMs #AI #Technology #Leadership #FutureOfWork

The role of a Forward Deployed Engineer sits at a unique intersection of engineering, problem‑solving, and customer partnership. It’s one of the few positions where technical depth and real‑world context meet in real time, and that blend reveals a few important truths about modern engineering work.

1. Proximity to the customer changes everything. When you’re embedded directly with users, you see constraints, workflows, and pain points that never surface in traditional product cycles. This proximity sharpens judgment, accelerates iteration, and builds a deeper understanding of what “value” actually means in practice.

It’s not just about deploying solutions — it’s about elevating outcomes.

2. FDEs turn ambiguity into clarity. Forward Deployed Engineers often operate where requirements are fluid, environments are complex, and stakes are high. The ability to ask sharp questions, map problems across systems, and translate context into actionable engineering decisions becomes a superpower.

In many ways, the role is less about code and more about clarity.

3. The leverage comes from connecting systems, people, and insights. FDEs bridge the gap between product teams, customers, and real‑world constraints. They validate assumptions, uncover edge cases, and ensure that solutions scale not just technically, but operationally.

This is where engineering meets empathy — and where great products become indispensable.

As technology evolves, roles like Forward Deployed Engineering remind us that impact isn’t created solely in codebases or architectures. It’s created in the space where understanding meets execution.

#ForwardDeployedEngineer #EngineeringLeadership #CustomerDrivenEngineering #TechExecution #ProductDevelopment

Spec‑Driven Development

 

🔵 What Spec‑Driven Development actually is

Spec‑Driven Development is a development methodology where:

• You write a detailed spec first

• The spec defines behavior, interfaces, and acceptance criteria

• Implementation strictly follows the spec

• Tests are derived from the spec

• The spec becomes the contract

It’s closer to:

• TDD (Test‑Driven Development)

• BDD (Behavior‑Driven Development)

• API‑first development

But with more emphasis on formal specification.

Here’s exactly how we use it.

⭐ 1. We start with a spec, not code

Every feature, improvement, or change begins with a spec document — not a PR, not a prototype, not a meeting.

Our spec includes:

• Problem statement

• Customer scenario

• Constraints (latency, cost, reliability, compliance)

• Success metrics

• Failure modes

• Open questions

• Design options

• Recommended approach

This ensures everyone understands why we’re building something before discussing how.

⭐ 2. AI helps generate the first-pass spec

This is where your team is ahead of most engineering orgs.

Instead of starting from a blank page, we use AI to produce a first-pass spec draft based on:

• Product requirements

• Customer feedback

• Existing architecture

• Known constraints

• Historical issues

Example from our workflow:

We fed AI a requirement like:

“Improve search latency for new users.”

AI generated a structured spec draft including:

• Hot paths to investigate

• Suggested caching strategies

• Proposed SLO targets

• Integration points

• Edge cases

• Risks and trade-offs

We didn’t accept it blindly — but it gave us a strong starting point.

⭐ 3. We refine the spec collaboratively

Engineers, PMs, and sometimes designers refine the AI-generated spec.

We clarify:

• What’s in scope

• What’s out of scope

• What assumptions are wrong

• What constraints matter most

• What trade-offs we’re willing to accept

This step transforms the spec from “AI-generated text” into a team-owned engineering contract.

⭐ 4. We break the spec into structured tasks 

Once the spec is approved, we convert it into structured, atomic tasks inside the repo.

Each task includes:

• Description

• Acceptance criteria

• Dependencies

• Priority

• Due date

• Owner

• Links back to the spec

Example:

From the search latency spec, AI helped generate tasks like:

• Add tracing to search pipeline

• Identify slowest percentile queries

• Propose caching layer for onboarding flow

• Add metrics for cold-start latency

• Validate improvements against SLO targets

This is where Spec‑Driven Development becomes execution-ready.

⭐ 5. AI assists with implementation scaffolding

AI doesn’t write the final code — but it accelerates the boring parts.

Examples from your team:

• Generating test scaffolding

• Drafting PR descriptions

• Suggesting integration test cases

• Creating initial API contract stubs

• Summarizing large diffs for reviewers

This keeps engineers focused on architecture, correctness, and reliability.

⭐ 6. The spec becomes the single source of truth

During implementation, the spec is the reference for:

• Design decisions

• Edge-case handling

• Testing strategy

• Acceptance criteria

• Cross-team alignment

If something changes, we update the spec — not just the code.

This prevents “tribal knowledge” and keeps the project maintainable.

⭐ 7. We validate the implementation against the spec

Before closing a feature, we check:

• Did we meet the constraints?

• Did we solve the customer problem?

• Did we hit the success metrics?

• Did we address failure modes?

• Did we follow the recommended design?

This is the “spec-driven” part — the spec guides the validation, not just the code.

⭐ 8. We use the spec for retros, onboarding, and future work

Specs become:

• Documentation

• Onboarding material

• Architecture references

• Future iteration guides

• Lessons learned

This is why your team moves fast without losing clarity — the spec is a living artifact.

🔵 Why Spec‑Driven Development works so well for our team

✔ It reduces ambiguity

No more “What exactly are we building?”

✔ It aligns engineering + product

Everyone sees the same blueprint.

✔ It accelerates design

AI gives us a strong starting point.

✔ It improves execution

Tasks are structured, scoped, and measurable.

✔ It increases reliability

Failure modes and constraints are defined early.

✔ It scales across teams

Specs are readable, shareable, and reviewable.

My linkedln posts

 

1. Distributed systems lessons I wish I learned earlier

There are a few distributed systems lessons I wish I learned much earlier in my career. They would’ve saved me countless outages, late‑night incidents, and “why is this happening” moments.

Here are the big ones:

1. The network is always the bottleneck. 2. Everything fails eventually. 3. Consistency is a tax. 4. Latency is a feature. 5. Observability is not optional.

Distributed systems aren’t about complexity. They’re about humility.

The sooner you accept that the system will misbehave, the better you’ll design it.

Primary hashtags: #DistributedSystems #SystemDesign #SoftwareEngineering #Scalability #TechLeadership

Boost hashtags: #CloudNative #BackendEngineering #HighAvailability #SRE #TechCareers

🔥 2. How to design systems that survive failure

The real test of a system isn’t how it behaves when things go right — it’s how it behaves when everything goes wrong.

Here’s how I design systems that survive failure:

1. Assume every dependency will fail. 2. Build graceful degradation paths. 3. Add timeouts everywhere. 4. Retry with backoff, not brute force. 5. Make failure visible.

Resilience isn’t an add‑on. It’s a mindset.

Systems don’t need to be perfect. They need to be prepared.

Primary hashtags: #ResilienceEngineering #SystemDesign #SRE #DistributedSystems #TechLeadership

Boost hashtags: #CloudArchitecture #DevOpsCulture #HighAvailability #EngineeringBestPractices

🔥 3. Why simplicity is the ultimate architecture

The longer I’ve been an engineer, the more I’ve realized one truth:

Simplicity is the ultimate architecture.

Simple systems:

• Fail less

• Scale better

• Are easier to debug

• Age gracefully

Complex systems:

• Fail in weird ways

• Require tribal knowledge

• Slow teams down

The best architects weren’t the ones who drew the most boxes — they were the ones who removed the most.

Simplicity isn’t the absence of features. It’s the absence of unnecessary friction.

Primary hashtags: #Architecture #EngineeringLeadership #SoftwareEngineering #Simplicity #TechCulture

Boost hashtags: #CleanCode #DesignPrinciples #TechStrategy #DeveloperExperience

🔥 4. How to scale a service from 1k to 1M users

Scaling from 1k to 1M users isn’t magic — it’s discipline.

1. Measure everything. 2. Cache aggressively. 3. Reduce synchronous calls. 4. Split hot paths from cold paths. 5. Optimize for the 99th percentile. 6. Automate recovery.

Scaling isn’t about servers. It’s about strategy.

Primary hashtags: #Scalability #HighPerformanceSystems #CloudNative #DistributedSystems #BackendEngineering

Boost hashtags: #SystemDesign #TechLeadership #PerformanceEngineering #DevOps

🔥 5. The trade-offs behind microservices nobody talks about

Microservices are powerful — but the trade-offs are real.

1. You trade simplicity for autonomy. 2. You trade local bugs for distributed bugs. 3. You trade single deployments for orchestration complexity. 4. You trade monolithic performance for network latency. 5. You trade shared ownership for fragmented accountability.

Microservices aren’t bad. They’re just expensive. Choose them intentionally.

Primary hashtags: #Microservices #Architecture #SystemDesign #SoftwareEngineering #TechLeadership

Boost hashtags: #CloudArchitecture #DistributedSystems #DevOpsCulture #EngineeringBestPractices

🔥 6. Caching strategies that actually work in production

Caching looks simple until you run it in production.

1. Cache the result, not the object. 2. Use TTLs that match business reality. 3. Cache at the edge whenever possible. 4. Bust caches intentionally. 5. Monitor cache hit ratios.

Caching isn’t a performance hack. It’s a design decision.

Primary hashtags: #Caching #PerformanceEngineering #BackendEngineering #DistributedSystems #Scalability

Boost hashtags: #SystemDesign #CloudNative #HighPerformanceSystems #TechLeadership

🔥 7. What I learned after applying to 100+ roles

After applying to 100+ roles, here’s what I learned:

1. Your resume matters less than your narrative. 2. Recruiters respond to momentum. 3. Referrals outperform applications by 10x. 4. You need a system, not hope. 5. Rejection is not feedback — conversations are.

Job searching is a skill. And like any skill, it gets better with structure.

Primary hashtags: #JobSearch #CareerGrowth #TechCareers #SoftwareEngineering #JobHunt

Boost hashtags: #CareerAdvice #InterviewTips #LinkedInTips #VancouverTech

🔥 8. The truth about technical interviews in 2026

Technical interviews in 2026 have changed.

1. AI hasn’t replaced interviews — it’s raised the bar. 2. System design is now the real differentiator. 3. Communication matters more than correctness. 4. Companies want engineers who can reason. 5. Collaboration beats performance.

Interviews aren’t harder. They’re just different.

Primary hashtags: #TechInterviews #SoftwareEngineering #CareerGrowth #SystemDesign #TechCareers

Boost hashtags: #InterviewPreparation #EngineeringLeadership #AIInTech #VancouverTech

🔥 9. How I track my job applications (with a custom dashboard)

One of the biggest unlocks in my job search was building my own job application dashboard.

It tracks:

• Stage

• Due date

• Next action

• Recruiter

• Follow-ups

• Notes

Why it works:

• It removes chaos

• It creates momentum

• It makes follow-ups effortless

• It turns job searching into a system

If you’re job searching, build a dashboard. Your future self will thank you.

Primary hashtags: #JobSearch #Productivity #CareerGrowth #TechCareers #SoftwareEngineering

Boost hashtags: #DashboardDesign #OrganizationTips #VancouverTech #LinkedInTips

🔥 10. Why rejection is data, not failure

Rejection used to feel personal. Now it feels like data.

1. Every rejection tells you something about the market. 2. Every rejection sharpens your narrative. 3. Every rejection improves your targeting. 4. Every rejection builds resilience.

Rejection isn’t failure. It’s feedback. And feedback is fuel.

Primary hashtags: #CareerGrowth #Mindset #JobSearch #TechCareers #Resilience

Boost hashtags: #Motivation #ProfessionalDevelopment #VancouverTech #CareerAdvice

One of the most meaningful engineering shifts I’ve experienced recently was integrating AI directly into our GSD (Get Stuff Done) project. Not as a bolt‑on feature. Not as a “cool demo.” But as a core engineering capability.

Here’s what AI actually enabled for us:

1. Turning vague requirements into actionable tasks We used AI to break down high‑level product ideas into structured, prioritized work items. No more guessing. No more misalignment. Just clarity.

2. Automating the “glue work” engineers usually hate AI handled:

• Drafting PR descriptions

• Generating test scaffolding

• Suggesting edge cases

• Creating initial API contracts This freed us to focus on architecture, reliability, and customer impact.

3. Making system design faster — and better We used AI to explore alternative designs, compare trade-offs, and validate assumptions. It didn’t replace our judgment. It amplified it.

4. Improving developer experience inside the repo AI became part of the workflow:

• Inline code suggestions

• Automated documentation updates

• Intelligent linting

• Real-time reasoning about code changes The repo became a place where engineers could move faster without sacrificing quality.

5. Creating a feedback loop between engineering and product AI helped us map customer pain → engineering tasks → measurable outcomes. It made the team more customer‑obsessed, not less.

The biggest lesson?

AI didn’t make us better engineers. It made us more effective engineers.

The GSD repo wasn’t an AI experiment. It was proof that AI can be a force multiplier when it’s embedded into the engineering process — not slapped on top of it.

And this is just the beginning.

#AI #SoftwareEngineering #DeveloperExperience #SystemDesign #TechLeadership #Productivity #VancouverTech #EngineeringCulture In our GSD workflow, AI didn’t replace any engineer — but it did replace hours of repetitive work. For example, instead of manually drafting PR descriptions or writing boilerplate tests, AI generated the first pass. We still reviewed everything, but the time savings were massive. It let us focus on architecture, reliability, and customer impact — the things AI can’t do. 
Once we started writing prompts like design docs — with constraints, context, and trade-offs — the quality jumped.“Latency must be under 200ms.”“Cost must stay under X.”“No new dependencies.”AI thrives when the boundaries are clear.Constraint thinking is the new engineering superpower. AI generated scaffolding, tests, documentation, and alternative designs. It felt less like automation and more like having a junior engineer who works at superhuman speed

One of the most meaningful engineering shifts I’ve experienced recently was integrating AI directly into our GSD (Get Stuff Done) project. Not as a bolt‑on feature. Not as a “cool demo.” But as a core engineering capability that changed how we design, plan, and execute work.

Here’s what AI actually enabled for us — with real examples from the repo:

1. Turning vague requirements into actionable tasks

We often start with high‑level product ideas like: “Improve onboarding flow” or “Optimize search relevance.”

Before GSD, this meant long meetings, clarifications, and manual breakdowns.

With AI, we fed the requirement into our workflow and got back a structured task breakdown:

• User scenarios

• Edge cases

• Dependencies

• API touchpoints

• Suggested acceptance criteria

Example: AI took a vague requirement — “Improve search latency” — and produced a first-pass breakdown including:

• Identify slowest query paths

• Add tracing to search pipeline

• Propose caching layer options

• Suggest percentile-based SLO targets

We still refined it, but the clarity boost was huge.

2. Automating the “glue work” engineers usually hate

AI handled the repetitive but necessary engineering tasks that slow teams down.

Examples from GSD:

• Drafting PR descriptions based on diffs

• Generating initial unit test scaffolding

• Suggesting integration test cases

• Creating API contract stubs

• Writing first-pass documentation updates

This wasn’t about replacing engineers — it was about removing friction.

3. Making system design faster — and better

When we explored new features, AI generated multiple architecture options for us to evaluate.

Example: For a new service integration, AI proposed three designs:

• A synchronous API call path

• An event-driven queue-based path

• A hybrid model with caching + async fallback

We didn’t blindly accept any of them. But reviewing them helped us surface trade-offs faster.

AI didn’t design the system. It accelerated our thinking.

4. Improving developer experience inside the repo

AI became part of the repo’s workflow itself.

Examples:

• Inline suggestions for refactoring

• Auto-generated comments explaining complex logic

• Intelligent linting based on project patterns

• Summaries of large PRs for faster reviews

Engineers spent less time deciphering context and more time making decisions.

5. Creating a feedback loop between engineering and product

AI helped us map customer pain → engineering tasks → measurable outcomes.

Example: For onboarding friction, AI analyzed user feedback and produced:

• A list of top pain points

• Suggested UX improvements

• Technical tasks tied to each pain point

• Metrics to track improvement

This made our team more customer‑obsessed, not less.

🔵 The biggest lesson?

AI didn’t make us better engineers. It made us more effective engineers.

The GSD repo wasn’t an AI experiment. It was proof that AI can be a force multiplier when it’s embedded into the engineering process — not slapped on top of it.

And this is just the beginning.

#AI #SoftwareEngineering #DeveloperExperience #SystemDesign #TechLeadership #Productivity #VancouverTech #EngineeringCulture

Spec‑Driven Development is a development methodology where:

• You write a detailed spec first

• The spec defines behavior, interfaces, and acceptance criteria

• Implementation strictly follows the spec

• Tests are derived from the spec

• The spec becomes the contract

It’s closer to:

• TDD (Test‑Driven Development)

• BDD (Behavior‑Driven Development)

• API‑first development

But with more emphasis on formal specification.

Structured Design Docs — a Microsoft‑style engineering practice focused on:

• Customer problem definition

• Constraints

• Multiple design options

• Trade‑off analysis

• Failure modes

• North Star outcomes

• Alignment across PM + Eng + Leadership

It’s essentially a thinking framework that forces clarity before implementation.

Interview Preparation

 1️⃣ NeetCode (https://neetcode.io) – The Ultimate DSA Question Bank

Recognizing problem-solving patterns is key to acing interviews. NeetCode nails it with well-structured topics and video solutions.

2️⃣ Aditya Verma (YouTube) – The Dynamic Programming Guru
If DP feels like a black box, his playlists are your flashlight:
🔹 Dynamic Programming: https://lnkd.in/dWPNDCze
🔹 Recursion: https://lnkd.in/dHtZvKmm
🔹 Stacks: https://lnkd.in/dntYkAxV
🔹 Binary Search: https://lnkd.in/dGUB644J
🔹 Sliding Window: https://lnkd.in/dkbPtXmQ


3️⃣ Striver’s Graph Series – FAANG-Level Graphs, Demystified
🎥 Graph Playlist: https://lnkd.in/dWS93mNq
One of the best visual breakdowns of graph concepts I’ve ever seen.


4️⃣ FreeCodeCamp (https://lnkd.in/drE_WNxx) – For Dev Skills on Demand
Anytime I wanted to explore a new dev topic in detail, FreeCodeCamp had my back.


5️⃣ C++ Basics
For language fundamentals:
• W3Schools: https://lnkd.in/dh4rC78h
• GeeksforGeeks: https://lnkd.in/dnYcn5Fh


6️⃣ System Design (ByteByteGo) – Next-Level Prep
Check out this gem: https://lnkd.in/djX6_tHm


7️⃣ Core CS Topics – InterviewBit Sheets
These were my go-to for last-minute prep:
OOPS: https://lnkd.in/dC7nzATy
DBMS: https://lnkd.in/dp8F_X42
CN: https://lnkd.in/dwkgz4mz
OS: https://lnkd.in/dvCtEXMw