Just wrapped up a month-long sprint where I interviewed with around 40 companies. The market is definitely tough, but people are hiring if you can actually get past the resume screen.
I wanted to dump everything I learned while it's still fresh in my brain. Hopefully, this saves you guys some time.
The Application Spam I stopped trying to be selective. I just went for volume. Used Simplify Copilot to speed things up (auto-apply bots were trash for me, kept applying to irrelevant roles).
Resume Hack: I added some AI-related keywords to my resume. Even for generic full-stack roles, I swear this triggered the ATS or recruiter attention more often. Everyone wants to "pivot to AI" right now, so play the game.
The Tech Stack Trap One mistake I made early on: I used Python for frontend LeetCode questions because it's faster to write. Don't do this. Unless it's Google/Meta, interviewers got confused why a "Frontend" candidate was writing Python. I switched back to JS/TS and the vibes improved instantly.
The "Basics" that aren't basic: Closures, Event Loop, Promises (async/await), and this binding. If you can't explain these clearly, you fail.
Frameworks: It’s not enough to know how to use React/Vue. They asked how it works. E.g., "How does Angular's dependency injection actually function?" or "React vs Vue performance tradeoffs."
Practical Coding (No LeetCode):
Build a traffic light component (auto switches + manual override).
Fetch data -> Render Table -> Add Pagination/Search.
Implement debounce and throttle from scratch.
Build a nested Modal.
Lazy load a massive list (Virtual scroll).
System Design & Backend I didn't get asked to code a database from scratch, but lots of "How would you scale this?"
Concepts: JWT vs Sessions, Database Indexing, Rate Limiting, Graceful Shutdowns.
Design Prompts: The classics are still popular. URL Shortener, YouTube history, Rate Limiter, Real-time Chat.
My template: Clarify requirements -> Diagram (API+Data flow) -> Deep dive on DB/Caching -> Trade-offs. Always mention trade-offs.
The "Soft" Stuff Matters More Than I Thought I used to think code was king. But after talking to ~30 hiring managers, I realized the "Behavioral" round is where decisions are actually made.
For behavioral questions companies like to asked I was able to find them on Blind, For real technical interview questions I was able to find them on Prachub
If you are senior: Show humility.
If you are junior: Show hunger/potential.
Unblock yourself: The biggest green flag I felt I gave off was describing how I solve problems when I'm stuck without pinging my manager immediately.
You see people posting huge TC offers and it feels bad, but remember you only need one yes. I failed plenty of these interviews before landing offers.
If you’re Googling: Uber system design interview, let me save you 3 hours: Every blog post says the same thing: Design Uber.
They show you a Rider App, a Driver App, and a matching service. Box, arrow, done.
I’m not going to do that. Because I couldn’t make it.
Last month I made it to the final round of Uber’s onsite loop for a Senior SDE role. My system design round was: Design a real-time surge pricing engine.
They wanted me to design the engine, the thing that ingests millions of GPS pings per second, calculates supply vs. demand across an entire city in real-time, and spits out a multiplier that changes every 30 seconds.
I thought I nailed it but I was wrong on my end.
Here’s exactly what happened, every question, every answer, and exactly where I think it fell apart.
Interview Setup
Uber’s onsite loop is 4–5 rounds, each 60 minutes, usually spread across two days. Here’s the breakdown:
Press enter or click to view image in full size
System design round is where Senior candidates are made or broken. You can ace every coding round and still get rejected here.
I used Excalidraw to diagram during the virtual onsite. I recommend having it open before you start.
Question: “Design Uber’s Surge Pricing System”
Here’s exactly how the interviewer framed it:
My first instinct was to start drawing boxes. I stopped myself.
Press enter or click to view image in full size
Step 1: Requirements (The 5 Minutes I Actually Got Right)
I asked clarification questions before touching the whiteboard. I think this is the move that separates L4 from L5. What do you think? Write in comments.
Functional Requirements I Confirmed:
The system must compute surge multipliers per geographic zone.
It must ingest real-time supply (driver GPS pings) and demand (ride requests).
Multipliers should reflect current conditions, not just historical averages.
The output feeds directly into the pricing service shown to riders.
Non-Functional Requirements I Proposed (and the interviewer nodded):
Latency: Multiplier must be recalculated within 60 seconds. (P99 < 5s for the pipeline).
Scale: Support 10M+ active users across 500+ cities globally.
Availability: 99.99% uptime — if surge fails, the fallback is 1.0x (no surge).
Accuracy vs. Speed: We optimize for speed. A slightly stale multiplier is better than no multiplier.
H3 Hex Mapper: Converts raw lat/long into an H3 hex ID. Sub-millisecond operation.
Supply/Demand Counters: Sliding window counters (last 5 minutes) stored in Redis, keyed by hex ID.
Surge Calculator: A streaming job (Apache Flink) that runs every 30–60 seconds, reads both counters, and computes the multiplier.
Pricing Cache: The output is written to a low-latency Redis cluster that the Pricing Service reads from.
Step 3: The Deep Dive (Where the Interview Gets Hard)
The interviewer didn’t let me stay at the high level. They pushed.
“How does the Surge Calculator actually compute the multiplier?”
I proposed a simple formula first: surge_multiplier = max(1.0, demand_count / (supply_count * target_ratio))
Then I immediately said: “But this is the naive version.”
The real version layers in:
Neighbor hex blending: If hex A has 0 drivers but hex B (adjacent) has 10, we shouldn’t show 5x surge in A. We blend supply fromkRing(hex_id, 1), the 6 surrounding hexagons.
Historical baselines: A Friday night in Manhattan always has high demand. The model should distinguish “normal Friday” from “Taylor Swift concert Friday.”
External signals: Weather API data, event calendars, even traffic data from Uber’s own mapping service.
“What happens if the Flink job crashes mid-calculation?”
This was the failure scenario question. I thought I was ready.
My Answer:
Stale Cache Fallback: Redis keys have a TTL of 120 seconds. If no new multiplier is written, the old one stays. Riders see a slightly stale surge (better than no surge or a crash).
Dead Letter Queue: Failed Flink events go to a DLQ (Kafka topic). An alert fires. The on-call engineer investigates.
Circuit Breaker: If the Surge Calculator is down for > 3 minutes, the Pricing Service defaults to 1.0 x no surge. This protects riders from being overcharged by a stale, artificially high multiplier.
The interviewer nodded. But then came the follow-up I wasn’t ready for:
“How do you handle surge pricing across city boundaries where hexagonal zones overlap different regulatory regions?”
I froze. I hadn’t thought about multi-region regulatory compliance i.e different cities have surge caps (NYC caps at 2.5x, some cities ban it entirely). My answer was vague: “We’d add a config per city.” The interviewer pushed: “But your Flink job is processing globally. How does it know which regulatory rules to apply per hex?” I stumbled through something about a lookup table, but I could feel the energy shift. That was the moment I lost it.
Step 4: The Diagram Walkthrough (Narrative Technique)
Instead of just pointing at boxes, I narrated a user journey through my diagram:
This narrative technique turns a static diagram into a living system in the interviewer’s mind.
The Behavioral Round (Where I Thought I Recovered)
After the system design stumble, I walked into the behavioral round rattled. The question:
I told the story of advocating for event-driven architecture over a polling-based system at my last company. I used the STAR-L method:
Situation: Our notification system was polling the database every 5 seconds, causing CPU spikes.
Task: I proposed migrating to a Kafka-based event stream.
Action: I built a proof-of-concept in 3 days, presented the latency data (polling: 5s avg, events: 200ms avg), and addressed concerns about Kafka operational complexity.
Result: The team adopted the event-driven approach. CPU usage dropped 60%.
Learning: I learned that data wins arguments, not opinions. Every technical disagreement should be fought with a prototype and a benchmark, not a slide deck.
I felt good about this one. But in hindsight, one strong behavioral round can’t save a wobbly system design.
The Rejection Email
Three days later:
Six months. That stung.
I asked my recruiter for feedback. She was kind enough to share: “Strong system design fundamentals, but the committee felt the candidate didn’t demonstrate sufficient depth in cross-region system complexity and edge case handling.”
Translation: I knew the happy path. I didn’t know the edge cases well enough.
What I’m Doing Differently (For Next Time)
I’m not done. I’m definitely going to apply again. Here’s my new playbook:
Edge cases: I’m spending 50% of my system design prep on failure modes, regulatory constraints, and multi-region complexity. The happy path diagram gets you a Strong L4. The edge cases get you the L5.
Read the Uber Engineering Blog cover to cover. Uber publishes their actual architecture decisions, H3, Ringpop, Schemaless. It’s free and if you’re interviewing at Uber and haven’t read their blog, you’re leaving points on the table. I read some of it. Next time, I’ll read all of it.
Practice with follow-up pressure. Generic “Design Twitter” didn’t prepare me “…but what about regulatory zones?” kind of questions I need practice and that’s where someone pushes back. I’ve been doing mock interviews on Pramp and studying company-specific follow-up questions on PracHub and Glassdoor.
Record myself. Narrating a diagram to your mirror is not the same as narrating it while someone challenges every arrow. I’m recording mock sessions on Excalidraw and watching myself stumble. It’s painful. It’s working.
Your Uber System Design Cheat Sheet (Learn From My Mistakes)
Press enter or click to view image in full size
Final Thoughts
I’d be lying if I said the rejection doesn’t still sting.
But here’s what I keep telling myself: I now know more about Uber’s system design than 95% of candidates who will interview there this year. I have the diagram. I have the failure modes. And now I have the edge case that cost me the offer.
Next time, I’ll be ready for the follow-up.
If you’re prepping for Uber, don’t just learn the architecture try preparing for the curveballs. Study their actual questions. And for the love of all things engineering, prepare for the question after the question.
Just wrapped up a month-long sprint where I interviewed with around 40 companies. The market is definitely tough, but people are hiring if you can actually get past the resume screen.
I wanted to dump everything I learned while it's still fresh in my brain. Hopefully, this saves you guys some time.
The Application Spam I stopped trying to be selective. I just went for volume. Used Simplify Copilot to speed things up (auto-apply bots were trash for me, kept applying to irrelevant roles).
Resume Hack: I added some AI-related keywords to my resume. Even for generic full-stack roles, I swear this triggered the ATS or recruiter attention more often. Everyone wants to "pivot to AI" right now, so play the game.
The Tech Stack Trap One mistake I made early on: I used Python for frontend LeetCode questions because it's faster to write. Don't do this. Unless it's Google/Meta, interviewers got confused why a "Frontend" candidate was writing Python. I switched back to JS/TS and the vibes improved instantly.
The "Basics" that aren't basic: Closures, Event Loop, Promises (async/await), and this binding. If you can't explain these clearly, you fail.
Frameworks: It’s not enough to know how to use React/Vue. They asked how it works. E.g., "How does Angular's dependency injection actually function?" or "React vs Vue performance tradeoffs."
Practical Coding (No LeetCode):
Build a traffic light component (auto switches + manual override).
Fetch data -> Render Table -> Add Pagination/Search.
Implement debounce and throttle from scratch.
Build a nested Modal.
Lazy load a massive list (Virtual scroll).
System Design & Backend I didn't get asked to code a database from scratch, but lots of "How would you scale this?"
Concepts: JWT vs Sessions, Database Indexing, Rate Limiting, Graceful Shutdowns.
Design Prompts: The classics are still popular. URL Shortener, YouTube history, Rate Limiter, Real-time Chat.
My template: Clarify requirements -> Diagram (API+Data flow) -> Deep dive on DB/Caching -> Trade-offs. Always mention trade-offs.
The "Soft" Stuff Matters More Than I Thought I used to think code was king. But after talking to ~30 hiring managers, I realized the "Behavioral" round is where decisions are actually made.
For behavioral questions companies like to asked I was able to find them on Blind, For real technical interview questions I was able to find them on Prachub
If you are senior: Show humility.
If you are junior: Show hunger/potential.
Unblock yourself: The biggest green flag I felt I gave off was describing how I solve problems when I'm stuck without pinging my manager immediately.
You see people posting huge TC offers and it feels bad, but remember you only need one yes. I failed plenty of these interviews before landing offers.
Hi Guys. looking developer with full stack experience and good with real time data api. This project is for our stocks website. Going to be an ongoing opportunity for years to come. Where can i find the right person for this job? Can anyone make any introductions please.
Hey folks, I’m currently working with a few US clients who are looking to automate parts of their businesses. I already have a small team (5–6 devs), but we’re getting more work than we can handle, so I’m looking to add a few junior developers.
Part-time role (around 3–5 hours/day)
You’ll be guided properly by senior devs
Real client projects (automation, integrations, etc.)
Scope to move to full-time if your work is good
If you’re interested, comment “Portfolio sent” and send your portfolio. I’ll review personally and DM you if it’s a fit.
Next steps are simple: Short interview → then we discuss payout → start working.
This is a bit urgent since new projects are coming in, so I’ll be reviewing quickly.
I know that DSA is important for Java, C++, Python, etc. But, genuine question, is DSA important for Full Stack? If yes, then how much time does it take to actually take?
I recently interviewed with Uber for a Backend SDE-2 role. I didn’t make it through the entire process, but the experience itself was incredibly insightful — and honestly, a great reality check.
Since Uber is a dream company for many engineers, I wanted to write this post to help anyone preparing for similar roles. Hopefully, my experience saves you some surprises and helps you prepare better than I did.
Round 1: Screening (DSA)
The screening round focused purely on data structures and algorithms.
I was asked a graph problem, which turned out to be a variation of Number of Islands II. The trick was to dynamically add nodes and track connected components efficiently.
I optimized the solution using DSU (Disjoint Set Union / Union-Find).
It was a classic Optimal Binary Search Tree (OBST) / Dynamic Programming problem in disguise.
You needed to:
Realize that not all BSTs are equal
Use DP to decide which word should be the root to minimize weighted depth
Think in terms of subproblems over sorted ranges
Key takeaway: Uber tests your ability to:
Identify known problem patterns
Translate problem statements into DP formulations
Reason about cost trade-offs, not just code
Round 3: API + Data Structure Design (Where I Slipped)
This round hurt the most — because I knew I could do better.
Problem
Given employees and managers, design APIs:
get(employee) → return manager
changeManager(employee, oldManager, newManager)
addEmployee(manager, employee)
Constraint: 👉 At least 2 operations must run in O(1) time
What Went Wrong
Instead of focusing on data structure choice, I:
Spent too much time writing LLD-style code
Over-engineered classes and interfaces
Lost sight of the time complexity requirement
The problem was really about:
HashMaps
Reverse mappings
Constant-time lookups
But under pressure, I optimized for clean code instead of correct constraints.
Key takeaway: In interviews, clarity > beauty. Solve the problem first. Refactor later (if time permits).
Round 4: High-Level Design (In-Memory Cache)
The final round was an HLD problem:
Topics discussed:
Key-value storage
Eviction strategies (LRU, TTL)
Concurrency
Read/write optimization
Write Ahead Log
However, this round is also where I made a conceptual mistake that I want to call out explicitly.
Despite the interviewer clearly mentioning that the cache was a single-node, non-distributed system, I kept bringing the discussion back to the CAP theorem — talking about consistency, availability, and partition tolerance.
In hindsight, this was unnecessary and slightly off-track.
CAP theorem becomes relevant when:
The system is distributed
Network partitions are possible
Trade-offs between consistency and availability must be made
In a single-machine, in-memory cache, partition tolerance is simply not a concern. The focus should have stayed on:
DANTAKALI COGNITIVE SYSTEMS LLP: The developer will be dealing with fintech projects (mostly AI infusion in existing banking/insurance systems). The projects will be related to enhancing modules to incorporate AI intelligence, enhance employee and customer interfaces with AI. Most often you will be working on developing an AI layer on top of the current systems. Please apply only if you feel confident and have undetaken high stake fintech projects. The code work should be efficient and highly secure. It will be vetted against different regulatory expectations, including central banks. Contract will be tied per project (module) basis. Strict confidentiality is called for and an NDA will be signed before commencement of any project. A stromg knowledge of AI systems and orchestration models is necessary. Past completed projects will be a big deciding factor. We have multiple projects in pipeline and your long term engegement is preferred.
Hey, we’re looking for a full-stack developer to join us.
Nothing overly corporate or complicated here. If you’ve got at least a year of experience and genuinely enjoy building products that are clean, fast, and reliable, you’ll probably fit in well.
We care a lot about:
• Clean, maintainable code
• Good performance and scalability
• Building products that actually feel good to use
• Paying attention to both frontend and backend quality
Pay is between $36–$46/hour depending on your experience. Fully remote, flexible hours, and both part-time or full-time are fine.
I’m planning to build an open-source WhatsApp-like application and looking for backend developers who are interested in collaborating and learning together.
Tech Stack
* Python + FastAPI
* PostgreSQL
* Redis
* MinIO
* WebSockets
* Kafka
* Microservices architecture
* Database-per-service
* Domain-Driven Design (DDD)
The goal is to build this as a real-world open-source project while learning and improving our skills in backend development, microservices, distributed systems, event-driven architecture, and real-time communication.
Important: This is a completely unpaid project. There is no financial compensation. The purpose is purely educational, learning, collaboration, and growing together as developers.
Everyone who actively contributes to the project can get the **GitHub Collaborator badge/recognition** through their contributions to the repository.
If you’re interested in Python/FastAPI, backend development, microservices, or distributed systems and would like to learn and build together, please DM me.
Let’s build something useful, learn from each other, and grow together! 🚀
I’m a 21-year-old Full Stack Developer, and honestly, something has been bothering me lately.
Whenever I browse Reddit, I keep seeing posts from Full Stack Developers who have been unemployed for months, struggling to get interviews, asking for referrals, or even desperately asking people for job opportunities. It’s honestly disturbing to see so many people struggling this badly to find work.
I have skills in React, JavaScript, Node.js, Express, MongoDB, REST APIs, Git/GitHub, authentication, and deployment. I’ve also built and worked on full-stack projects rather than only following tutorials.
So my question is:
Why is the situation so bad for Full Stack Developers right now?
Is the market genuinely oversaturated?
Are companies hiring fewer junior developers?
Is AI changing the entry-level market?
Or are most candidates simply not meeting the skills companies actually want?
And most importantly, if you were 21 and starting your career today, would you still choose Full Stack Development?
I’d genuinely like to hear from developers and recruiters who are actually working in the industry.
We're hiring a Senior Software Engineer with 4–6 years of experience for a C2H role (4 months, extension based on performance).
📍 Location: Pune
💰 Budget: ₹1.1–1.4 LPM
🧑💻 Tech Stack: TypeScript, Node.js, React, AWS
If you have experience building scalable full-stack applications and are open to new opportunities, drop a comment or DM me. I'll share the application details...
We are building a serious healthcare software platform focused on EMR/EHR, hospital operations, and patient engagement.
The platform is already under active development, and we are looking for 2 strong senior developers or a technical partner who wants to join a small enterprise early and help us finish, secure, optimize, and launch it commercially.
This is not a traditional paid contract at the beginning. I’m specifically looking for someone interested in a long-term partnership and willing to contribute initially without upfront payment in exchange for meaningful upside.
Possible partnership incentives can include:
Equity or ownership participation
Revenue share once the platform begins generating revenue
Technical co-founder / CTO-level opportunity for the right person
Milestone-based equity vesting
Priority for a future salaried technical leadership role after funding/revenue
Long-term participation in future healthcare software products
Potential performance-based bonuses after commercial launch or investment
We'll discuss the exact structure privately and document it properly before any serious work begins.
Healthcare software, EMR/EHR, HIPAA, FHIR/HL7, multi-tenant systems, or Flutter experience is a major plus.
I’m looking for 2 independent developers, not an agency, outsourcing company, recruiter, or development team.
You should be comfortable working with an existing large codebase, solving root causes instead of patching symptoms, documenting your work, and taking real technical ownership.
The company/platform name, repositories, and proprietary details will remain confidential during initial discussions.
If you are interested, DM me with:
Your experience level
GitHub or portfolio
Your strongest backend/full-stack project
Any healthcare or enterprise software experience
Why a partnership/equity arrangement interests you
Do you have over a year of experience building web applications? I’ve got real projects waiting—no busywork. Think creating responsive frontends, robust backends, or seamless API integrations—the kind of work that truly makes an impact.
Role: Full-Stack Developer
Pay: $20–50/hr, depending on your experience and stack
Location: Fully remote
What’s in it for you:
Projects that match your skills and interests
Part-time, flexible work—perfect if you have other commitments
Passionate about full-stack development? Leave a message with your timezone👀
Hey everyone, we're participating in the NASA space apps challenge this year and we could really use someone with good web development/software engineering skills ^^
We're working on a health monitoring software for astronauts on long missions and we'll be working with ML models and lots of data analytics, if you're interested please send me a dm
Hi everyone — Sharing my Amazon SDE-2 (L5) experience, as precisely as I can remember.
Applied directly through the company portal to every SDE-2 opening I could find. A recruiter reached out with a role and sent the OA.
Round 0 — Online Assessment
Three sections — and the format has changed, so heads up:
Section 1: 2 questions. One DSA (counting-based). One AI-assisted code repository question — a repo-style codebase (controller / service / repository layers), 6 failing test cases, find and fix the bugs so they pass. An AI assistant was attached but honestly it wasn't much help — couldn't meaningfully navigate or search the codebase. I ended up finding the issues myself.
Section 2: Order-of-decisions reasoning — given a project state, sequence the right steps (planning, architecture, POC, API dev, etc.) with technical justification.
Section 3: Behavioural — "most like me / least like me" style.
Solved all test cases on the DSA, 5/6 on the AI-assisted repo question. Cleared it — recruiter confirmed May 5 and said the first 2 rounds would gate the rest.
Explained brute force → optimized for each, with complexity. Solved both quickly, so we had extra time — interviewer dug into hashmap and heap internals afterward.
LP:
A time you had to debug a difficult issue — what could you have done better?
A time you gave a simple solution to a complex problem.
Honest note: my LPs here were shaky. I wasn't well-prepared for behavioural going into R1 and I could feel it.
HR verdict (next day): Inclined. They scheduled the HLD round.
You are given a full-stack Movie DB application. Users can log in, create, update, and delete watch lists, and add or remove movies from a watch list.
Several unit tests are failing around watch-list movie operations. Your job is to debug and fix the backend logic so that all of the listed scenarios behave correctly, with the right persistence and the right HTTP responses. This is a debugging exercise: the data model and routing already exist — focus on correcting the handler logic rather than redesigning the system.
Used Strategy + Factory + Singleton. Then follow-ups on extensibility.
LLD tip: once your base design is clean, proactively bring up fault tolerance, resiliency, and scalability. It adds maturity and the interviewer clearly registered it.
LP:
Something you recently learned and applied at work
How you measure the success metrics of a learning journey
Best round of my loop — LPs were solid by now.
HR (next day): Inclined.
Round 3 — HLD + LP (May 26), Engineering Manager
Problem statement, in full: "Design Netflix." That's it. Had to derive requirements myself and diagram on BlueSpace (Excalidraw-style), covering availability, scalability, fault tolerance, and the trade-offs of my approach. Interviewer interjected with constraints to fold in.
Good discussion on movie search via a reverse-index store like OpenSearch, plus a CDC pipeline for keeping it in sync.
LP:
A time you had a conflict with seniors and turned out right
A time you got harsh feedback from your manager and how you incorporated it
Felt strong. Interviewer seemed satisfied.
HR (same day): Inclined. Bar raiser scheduled.
Round 4 — Bar Raiser, Principal TPM
Mostly behavioural/leadership, with one DSA:
Unique permutations of a string (e.g. "xxyy" → each distinct arrangement once). Solved with frequency-map + backtracking to prune duplicates.
Then 2 LP questions with heavy follow-ups:
A time you learned something quickly and applied it
A time you delivered under a tight deadline
I had solid stories + metrics ready, and the interviewer drilled hard into how the metrics were actually gathered. Felt only okay — the bar raiser gave zero signal, which made me nervous.
HR (same day): Selected. Offer 2 days later.
(Will add detailed comp soon.)
Prep notes — what actually moved the needle
PracHub was the single most valuable thing in my DSA prep. The reason I cleared the coding portions fast enough to leave time for the deep-dives — heap/hashmap internals in R1, the bar-raiser follow-ups — is that I'd drilled the underlying patterns there until recognition was instant. Aggressive Cows → binary-search-on-answer, Median-in-a-stream → two-heaps, unique permutations → backtracking with frequency pruning: I didn't derive any of those cold, because I'd worked enough variants on PracHub that the approach surfaced in seconds. That speed is what bought me the room to discuss trade-offs and internals — which is where SDE-2 candidates actually get separated. If your pattern recognition isn't automatic yet, that's the highest-leverage place to put your time.
LP was my weak spot and I felt it in R1. Fixed it hard before R2: 2–3 real STAR stories per principle with genuine success metrics. By the bar raiser I could survive deep follow-ups on how metrics were gathered. Don't treat LP as the soft part — at Amazon it's half the loop.
OA's AI-assisted bug-fix round: practice navigating an unfamiliar codebase in a real framework. The provided AI won't save you.
Takeaways
Solve DSA fast enough to leave time for the internals discussion — that's where the points are.
LPs are not a formality. Especially the bar raiser.
For LLD, layer resiliency/scalability on top of a clean design.
The bar raiser giving no signal is normal. Don't read into it.
I run a construction contracting business in India (NCR) and I’m looking for a fresher / junior full-stack developer who wants hands-on experience building a real internal product.
This can be structured as an internship or a short-term freelance engagement, depending on your availability and preference. (Remote)
Tech stack (preferred, not mandatory)
React / Next.js
Basic backend (Node / APIs)
PostgreSQL
Supabase is a plus
Who this is for
Freshers / junior developers
Comfortable with basic frontend, backend and database concepts
Have built small apps / dashboards (college or personal projects are fine)
Interested in learning how real business workflows are designed
Budget: My budget is limited and suited for a junior / early-career developer.
Timeline
Flexible, but ideally 3–5 weeks.
How to apply: DM me Short intro about you, your tech stack and GitHub or any small project link if available.
I'm building **Taskoora**, a business operations platform starting with restaurants and hospitality.
I'm looking for **2–3 people who want to work closely with me at the early stage**, particularly around:
• Full-stack/backend engineering
• Product, operations, and customer growth
This isn't a conventional full-time salaried role right now. I'm looking for people who are comfortable contributing part-time or collaboratively. I can provide a **small stipend / project-based compensation** depending on the role, contribution, and commitment.
More than credentials, I'm looking for people who enjoy building, taking ownership, solving problems, and figuring things out from zero.
If this sounds interesting, feel free to DM me. I'd rather start with a conversation and work on something small together than go through a formal interview process.
Hi, we are looking for an experienced full-stack next.js developer to build an eyeglasses online store.
Required stack: Next.js, Tailwind CSS, Supabase, and Stripe.
The website should include:
Product pages
Shopping cart
Stripe payment integration
Full admin dashboard
Facebook Pixel and Facebook Conversion API (with Latest best practice)
Responsive mobile and desktop design
Please message me on Facebook and also email [email protected] the following:
Your Portfolio
github profile url
Actual live URL of the storefront you built
Actual live URL of the admin dashboard you built
Admin login details, if available
Similar custom e-commerce projects you have completed
Completion Timeline
Fixed-price bid in USD
Please do not send screenshots, images, or mockups only. We need working website URLs so we can review the actual storefront and dashboard if it suits what we are looking for.
We will prioritize developers who have already completed similar custom e-commerce projects.
No Shopify websites please. We are looking for a custom-built Next.js stack website.
***This is one of several projects we have. If you are highly skilled, reliable, you may have the opportunity to work with us long-term and become a member of our organization.***