STAR Method Interview Answers: 20 Examples for Indian Freshers

Situation: In my final year at VIT Vellore, our capstone project was a hospital management system built with React and Node.js. Our team had 5 members, but two of them were focused entirely on their GRE preparation and were barely contributing to the codebase.

Task: As the team lead, I needed to ensure we delivered a working product for our end-semester evaluation in 8 weeks — without creating conflict or escalating to the faculty, which would hurt everyone's grades.

Action: I called a team meeting and had an honest conversation about workloads. Instead of blaming anyone, I restructured the tasks: I assigned the two GRE-focused members to documentation, UI mockups in Figma, and testing — work that was genuinely useful but could be done in shorter bursts around their study schedule. I paired the remaining three of us for the core backend and frontend development, holding 30-minute daily standups on Google Meet to track progress. I also created a shared Notion board so everyone could see the project status in real time.

Result: We submitted the project on time and scored 9.1 out of 10 in the evaluation. Our faculty specifically praised the quality of our documentation and test coverage. Both the GRE-focused members thanked me later for accommodating their situation without drama, and one of them recommended me for a referral at his company after placement.

Situation: I was part of the sponsorship team for Techfest at NIT Trichy. Our team of 8 included students from mechanical, civil, CS, and electronics branches — most of us had never worked together before. We needed to raise Rs 3 lakh in sponsorship money within 6 weeks to fund the event.

Task: I was responsible for the corporate outreach vertical — specifically targeting mid-size IT companies and ed-tech startups in Chennai and Bangalore.

Action: I created a sponsorship deck using Canva that clearly showed footfall numbers, social media reach, and branding opportunities. I divided my target companies into three tiers based on sponsorship amount and personalized each pitch email. I coordinated with the design team (from mechanical branch) to prepare physical banners and stall layouts that sponsors could visualize. When two team members from civil engineering felt unsure about calling companies, I paired them with more confident callers for the first few outreach calls so they could learn by observing.

Result: My vertical alone secured Rs 1.2 lakh from 4 sponsors, including a Rs 50,000 deal with a Bangalore-based ed-tech startup. The overall team raised Rs 3.8 lakh, exceeding our target by 27%. The fest organizers used our sponsorship template for the next two years.

Situation: During Smart India Hackathon (SIH) 2025, I was teamed up with 5 students from different colleges and branches — including a design student from NID who approached problems very differently from us engineering students. While we jumped straight into coding, she insisted on spending hours on user research and wireframing first.

Task: We had 36 hours to build a working prototype for a government problem statement on rural healthcare access. I needed to find a way to bridge the design-first and code-first approaches so we didn't waste precious hours on internal friction.

Action: I suggested a compromise: we would spend the first 3 hours on her user flow and wireframes while the backend developers (including me) set up the database schema and API structure simultaneously. This way, the design work informed our frontend development without blocking backend progress. I also set up a shared Figma-to-code handoff process so the frontend developers could start building components as soon as each screen was finalized, rather than waiting for all screens to be done.

Result: Our prototype was praised by the judges specifically for its user-centric design — something most hackathon teams neglect. We finished in the top 5 nationally and received a Rs 25,000 prize. More importantly, I learned that combining different working styles produces better outcomes than forcing everyone into one approach.

Situation: During the annual NSS camp organized by my college in Pune, our unit of 40 volunteers was deployed to a village in Satara district for a 7-day community development camp. The village had poor sanitation awareness, and our project was to build two toilet units and conduct a hygiene awareness workshop.

Task: I was assigned to the awareness team — our goal was to get at least 100 villagers (out of roughly 300 total population) to attend our hygiene and sanitation workshop on Day 5.

Action: I realized that simply putting up posters in Marathi would not be enough — many of the older villagers were not literate. I coordinated with the local Anganwadi worker to spread word-of-mouth through the women's self-help group. I also organized a short street-play (nukkad natak) on Day 3 about handwashing and clean water, which drew a crowd and created curiosity about the main workshop. I worked with two teammates to prepare visual charts and demonstration kits (soap, ORS packets, water purification tablets) so the workshop would be interactive, not lecture-based.

Result: 137 villagers attended the workshop — well above our target of 100. The sarpanch was so impressed that he invited our NSS unit back the following year. Our camp coordinator submitted our awareness campaign as a model template to the university's NSS cell, and it was shared with 12 other colleges in the region.

Situation: I was the president of the Coding Club at SRMIST Chennai. Three weeks before our flagship annual coding competition (with 500+ expected participants from 15 colleges), our faculty advisor informed us that the college had double-booked our venue — the main auditorium — for a convocation rehearsal. We suddenly had no venue for an event we had been promoting for two months.

Task: As president, I needed to find an alternative solution quickly without cancelling the event, which would damage the club's reputation and waste the Rs 80,000 we had already spent on marketing and prizes.

Action: I called an emergency meeting with my core committee of 8 people that same evening. We brainstormed three options: postpone, move to a smaller venue, or go hybrid. I decided on a hybrid model — the opening ceremony and prize distribution would happen in a smaller seminar hall (capacity 200), while the actual coding rounds would be conducted online via HackerRank. I delegated tasks immediately: two members handled HackerRank contest setup, two managed communication to all registered participants, two coordinated the seminar hall logistics, and I personally called sponsors to explain the format change and ensure their branding would still be visible. I also negotiated with the IT department to extend lab access hours so students without laptops could participate from campus labs.

Result: We retained 460 out of 520 registered participants — only a 12% drop despite the format change. Three sponsors confirmed they would support next year's event too. The hybrid format actually worked so well that the club adopted it as the default for future events, increasing participation from other cities by 35%.

Situation: After I got placed through campus recruitment at Cognizant in my pre-final year, I noticed that many of my juniors (third-year students) were struggling with aptitude tests and coding rounds. The college's placement cell offered generic training, but students needed more targeted, peer-level guidance.

Task: I decided to start an informal placement preparation group to help at least 20 junior students improve their aptitude and coding skills before the placement season started.

Action: I recruited 3 other placed students and we organized weekend sessions every Saturday for 10 weeks. I took ownership of the Data Structures and Algorithms track. I curated 50 problems from LeetCode and GeeksforGeeks, organized by difficulty and topic, and created a shared Google Sheet to track each student's progress. For students who struggled with specific topics (like dynamic programming), I held extra 1-on-1 doubt sessions on Google Meet. I also compiled a "Company-wise Question Bank" by reaching out to seniors who had interviewed at TCS, Infosys, Wipro, and Accenture, and organized the patterns I found.

Result: Out of the 22 students who attended regularly, 18 got placed in the next placement season — an 82% placement rate compared to the department average of 60%. Four students specifically told me that the DP workshop was what helped them clear their coding rounds. The placement cell invited me to formalize the program as an official mentorship initiative for future batches.

Situation: During my summer internship at a fintech startup in Bangalore (a 12-person team), I was assigned to write API documentation for their payment gateway module. After two weeks of working with the APIs, I noticed that 3 out of 12 API endpoints were returning inconsistent error codes — the same error would return a 400 in one endpoint and a 500 in another.

Task: My assigned task was only documentation, but I felt the inconsistency would cause problems for external developers integrating the API. I decided to raise this proactively, even though it was outside my scope.

Action: I documented all 3 inconsistencies with specific examples, showing the request, expected response, and actual response for each case. I prepared a one-page summary comparing the error codes against REST API best practices. Instead of just sending an email, I requested 15 minutes during the Friday engineering standup to present my findings. I also proposed a standardized error code mapping that could be applied across all endpoints and offered to update the endpoints myself if the team agreed.

Result: The CTO was impressed and approved my proposed error code standardization. I spent the next week implementing the fixes across all 12 endpoints, and the changes were shipped in the next release. My internship evaluation mentioned "proactive problem identification" as a standout quality, and the CTO offered me a pre-placement offer (PPO) — which I attribute partly to showing initiative beyond my assigned scope.

Situation: During the Combined Annual Training Camp (CATC) organized by 1 Kerala NCC Battalion, I was appointed squad leader for a group of 12 cadets from 4 different colleges. Several cadets from other colleges were senior to me in age and were openly dismissive about taking directions from someone younger. On the second day, during a drill practice session, two cadets refused to follow my formation commands, saying they "already knew the drill."

Task: I needed to get the full squad synchronized for the inter-squad drill competition on Day 5 without creating a confrontation that would escalate to the commanding officer and reflect poorly on everyone.

Action: Instead of pulling rank, I had a private conversation with the two senior cadets during the mess break. I acknowledged their experience and asked if they would co-lead specific drill segments where their expertise was stronger — effectively giving them ownership rather than just compliance. I restructured the practice schedule so that each cadet got a chance to lead warm-up exercises on a rotating basis, which distributed authority and reduced the "taking orders from a junior" friction. For the actual competition drill sequence, I focused on precision timing rather than authority — I set up a metronome on my phone during practice so the commands were about rhythm, not about me giving orders.

Result: Our squad won second place in the inter-squad drill competition out of 8 squads. The two cadets who had initially resisted became the most disciplined performers because they felt invested in the outcome. The commanding officer commended our squad's "exceptional cohesion" during the closing ceremony. I received a B certificate with distinction, and this experience taught me that leadership is about enabling people, not commanding them.

Situation: In my sixth semester at BITS Pilani, our Database Management Systems course required a group project — an online library management system using MySQL and PHP. Two days before the submission deadline, we discovered that the book return function was silently corrupting records: when a student returned a book, the system would sometimes mark a completely different book as returned instead.

Task: I needed to find and fix the bug within 48 hours. The codebase was roughly 3,000 lines of PHP — written by 4 different people with inconsistent coding styles and minimal comments.

Action: I started by reproducing the bug systematically — I tried 20 different return scenarios and found that the corruption only happened when two students returned books within 30 seconds of each other. This pointed to a concurrency issue. I traced the code flow and found that the return function was using a global variable to store the book ID temporarily before updating the database, which got overwritten when a second request came in. I replaced the global variable with a session-scoped variable tied to each user's session ID, ensuring each return transaction was isolated. I then wrote 10 test cases specifically for concurrent returns and ran them using two browser windows simultaneously to verify the fix.

Result: The fix worked perfectly across all test cases. We submitted on time and received 48 out of 50 marks — the highest in our section of 35 groups. The professor used our concurrency bug as a teaching example in the next lecture on database transaction isolation, which was a proud moment for the team.

Situation: As the technical head for our college's annual cultural fest at IIIT Hyderabad, I was responsible for the sound and lighting setup for 3 stages over 2 days. One week before the fest, our regular AV vendor cancelled because he got a bigger contract from a corporate event. His quote had been Rs 1.5 lakh, and we had already allocated that budget with no buffer.

Task: I needed to arrange professional-grade sound and lighting for 3 stages within the same Rs 1.5 lakh budget, in just 7 days, during peak event season when most vendors were already booked.

Action: I called 15 AV vendors in Hyderabad — all either unavailable or quoting Rs 2 lakh or more. Then I tried a different approach: I contacted the Music Department and Drama Club on campus, who owned basic sound equipment. By combining their equipment, I could cover 1 of the 3 stages internally. For the remaining 2 stages, I found two smaller, independent sound engineers on Instagram (local Hyderabad musicians who did freelance event setups) and negotiated separate deals — Rs 55,000 each instead of a single vendor's Rs 1.5 lakh package. I also borrowed stage lighting from a neighbouring college's theater group in exchange for offering them free stalls at our fest.

Result: The total cost came to Rs 1.25 lakh — actually Rs 25,000 under budget, which we redirected to improve artist hospitality. All 3 stages ran without technical issues across the 2-day fest. The fest coordinator adopted my "distributed vendor" model for future years, calling it more resilient than depending on a single vendor.

Situation: At HackBVP 2025 (a 24-hour hackathon at BVP New Delhi), my team of 4 was building a crop disease detection app using image classification. We had trained a TensorFlow model on our laptops and planned to deploy it as a Flask API. Eight hours into the hackathon — with the model 70% trained — we realized that the free-tier cloud server we planned to use for deployment could not handle the model size (it was 800 MB).

Task: We needed to either find a way to deploy the large model or completely rethink our architecture, all with only 16 hours remaining.

Action: I proposed converting our TensorFlow model to TensorFlow Lite (TFLite) and running inference directly on the Android device instead of relying on a cloud server. This eliminated the deployment problem entirely. I spent 2 hours converting the model using TFLite's quantization tools, which compressed it from 800 MB to 45 MB with only a 3% accuracy drop. Meanwhile, my teammates built the Flutter frontend and integrated the camera module. I wrote the Kotlin bridge code to run TFLite inference natively on Android. We also added an offline mode — since the model ran locally, farmers in areas with poor internet connectivity could still use the app.

Result: Our offline-capable approach became our biggest differentiator. The judges specifically asked about our pivot and were impressed by the practical thinking. We won the "Best Use of AI" track prize (Rs 15,000) and received mentorship offers from two judges. The offline angle was something none of the other 40 teams had considered.

Situation: During my 2-month internship at a mid-size IT services company in Noida, I was working on a client dashboard project. Three weeks in, I realized that the delivery timeline the project manager had committed to the client assumed that two API integrations could be built in parallel — but both depended on the same authentication module that had not been built yet. Nobody else on the 6-person team had flagged this dependency.

Task: I was just an intern, but I could see that if the authentication module was not prioritized, both API integrations would be blocked, and we would miss the client deadline by at least a week.

Action: I mapped out the dependency chain on paper and showed it to the senior developer first (rather than going straight to the project manager, which could have seemed presumptuous). He confirmed the issue and suggested I present it at the next sprint planning meeting. I prepared a simple Gantt chart in Google Sheets showing the dependency bottleneck and proposed reordering the sprint: build the authentication module in Week 4 (current week), then build both APIs in parallel during Weeks 5 and 6. I also volunteered to pair-program on the authentication module to speed it up.

Result: The project manager accepted the revised timeline and thanked me for catching it early. We delivered the authentication module by the end of Week 4 and both APIs by mid-Week 6 — two days ahead of the client deadline. The project manager mentioned this in my internship review, writing that I "demonstrated systems thinking unusual for an intern." This experience reinforced the importance of looking beyond your own tasks to understand the full project picture.

Situation: During my final year project expo at Anna University, external evaluators included two industry professionals from manufacturing backgrounds who had limited familiarity with machine learning. Our project was a predictive maintenance system using LSTM neural networks for industrial motors — a deeply technical topic.

Task: I needed to present our project in a way that would impress both the technical faculty evaluators and the non-technical industry evaluators, within a 15-minute presentation slot.

Action: I restructured our presentation into two layers. For the first 8 minutes, I used a factory analogy: "Imagine a doctor who can predict you will get a fever three days from now by reading your pulse pattern. Our system does the same for machines — it reads vibration patterns and predicts breakdowns before they happen." I included a 2-minute live demo showing our system analyzing real vibration data and flagging an anomaly with a red alert. For the technical portion, I kept detailed architecture slides as backup and only showed them when the faculty evaluators asked specific questions. I also prepared a one-page visual handout comparing traditional maintenance (reactive) vs. predictive maintenance (our approach) with cost savings data from industry case studies.

Result: Both industry evaluators rated us 9 out of 10 — one of them said our presentation was the first time he "actually understood how AI can help my factory." We received the Best Project award for our department (out of 42 groups). The one-page handout approach was later adopted by the department as a suggested template for future project expos.

Situation: During my remote internship at a SaaS startup in Bangalore, I was assigned to build a "user analytics dashboard." I spent 4 days building a dashboard that showed user engagement metrics (page views, session duration, click heatmaps). When I presented it to my manager on the Friday review call, he said he meant an "admin analytics dashboard" — tracking internal team performance metrics, not end-user behavior. Four days of work was essentially wasted.

Task: I needed to deliver the correct dashboard within the remaining 6 days of my sprint while salvaging whatever I could from the work already done, and also ensure this type of miscommunication did not happen again.

Action: First, I took ownership instead of blaming the unclear brief — I acknowledged that I should have confirmed requirements before starting. I then audited my existing code and found that about 40% of the components (charts, date filters, layout) were reusable for the admin dashboard. I created a detailed requirements document for the admin dashboard with mockups using Excalidraw, shared it with my manager for approval before writing a single line of code, and got written confirmation on Slack. I also proposed a process change: for all future tasks, I would share a brief "Understanding Document" within the first day, outlining my interpretation of the task, so any misalignment could be caught early.

Result: I delivered the correct admin dashboard by Day 10 — one day early — by reusing the salvageable components from my first attempt. My manager adopted the "Understanding Document" practice for all interns going forward. In my internship feedback, he wrote that my response to the setback showed "maturity and process-oriented thinking." I learned that 10 minutes of clarification upfront can save days of rework.

Situation: In my third year at DTU Delhi, I was part of the college magazine editorial team. The team had been using Google Docs for all content editing and WhatsApp for coordination for three years. With 25 team members, articles were constantly getting lost in long WhatsApp chats, version control was non-existent (people edited the wrong draft), and deadlines were missed because nobody had a clear view of overall progress.

Task: I wanted to move the team to Notion for content management and task tracking, but the editor-in-chief and most senior members were resistant — they said the current system "works fine" and did not want to learn a new tool mid-semester.

Action: Instead of pushing for an immediate full switch, I took a "show, don't tell" approach. I set up a Notion workspace over a weekend and migrated one section of the magazine (the tech column, which I managed) as a pilot. I tracked the next two weeks: articles submitted on time increased from 60% to 100% for the tech column, and zero version confusion incidents compared to three in the previous edition for other sections. I then presented these results at the next editorial meeting, along with a 10-minute Notion walkthrough. I offered to personally onboard each team member with a 15-minute 1-on-1 session and created a simple "Notion Cheat Sheet" in Hindi and English for quick reference.

Result: The editor-in-chief agreed to a full migration. Within 3 weeks, all 25 members were using Notion. The next magazine edition was published 5 days ahead of deadline — a first in 4 years. Two other college clubs (the photography club and debating society) asked me to help them set up similar systems. This experience taught me that data and demonstration are more persuasive than arguments. For more strategies on building structured communication habits, PenLeap offers excellent frameworks for organizing thoughts and writing persuasively.

Situation: As the student coordinator for a technical workshop series at my college in Jaipur, I had committed to organizing 6 workshops over the semester with industry professionals. After the third workshop, I realized that student attendance had dropped from 120 (Workshop 1) to 80 (Workshop 2) to just 35 (Workshop 3). The remaining three workshops were on niche topics that would likely draw even fewer attendees. Our faculty advisor had invested significant effort in arranging industry speakers and would not be happy about cancellations.

Task: I needed to inform the faculty advisor that continuing with the remaining workshops in their current format would waste resources and the speakers' time, while proposing an alternative that would still deliver value.

Action: I prepared a brief data report showing the attendance trend, student feedback from Google Forms (which revealed that Saturday scheduling and overly theoretical content were the main complaints), and my proposed solution before the meeting. In the meeting, I led with the data rather than my opinion. I proposed consolidating the remaining 3 workshops into 1 intensive "Weekend Bootcamp" — a full-day hands-on session on a weekday (Friday) with all 3 topics restructured as practical labs rather than lectures. I also suggested adding a certificate for completion to incentivize attendance and proposed that I personally handle the logistics and speaker coordination for the new format.

Result: The faculty advisor appreciated my data-driven approach and approved the bootcamp format. The consolidated Friday bootcamp drew 95 attendees — more than Workshops 2 and 3 combined. Student feedback scored it 4.6 out of 5 compared to 3.2 average for the individual workshops. The faculty advisor later told me that what impressed him most was that I brought solutions, not just problems.

Situation: In the first semester of my final year at KIIT Bhubaneswar, I was doing a part-time remote internship at a Pune-based startup (15 hours per week), attending regular college classes (6 courses), and preparing for campus placements which were starting in 8 weeks. I was sleeping 4 hours a night and my performance was declining in all three areas.

Task: I needed to find a sustainable system to manage all three commitments without dropping any of them — the internship could lead to a PPO, my CGPA was at risk if I neglected academics, and placements were a non-negotiable priority.

Action: I created a detailed weekly time-block schedule in Google Calendar. I allocated mornings (8 AM to 12 PM) for college classes, afternoons (2 PM to 5 PM) for internship work, and evenings (6 PM to 9 PM) for placement preparation (aptitude on Monday-Wednesday, DSA on Thursday-Saturday). Sundays were for catching up on whichever area was falling behind. I also made two strategic decisions: I negotiated with my internship manager to shift my deliverable format from daily tasks to weekly sprints, giving me flexibility in when I worked; and I formed a study group of 4 friends for placement prep so we could divide mock test preparation and share solutions. I started saying no to non-essential social commitments temporarily.

Result: My semester CGPA was 8.4 (up from 8.1 the previous semester). I completed the internship successfully and received a PPO. I cleared the aptitude rounds for 4 companies and eventually got placed at Wipro with a Rs 3.5 LPA package. The time-blocking system worked so well that I still use a version of it in my daily routine. Looking back, the key lesson was that managing time is really about managing priorities — not every task deserves equal attention every day.

Situation: My professor at Jadavpur University Kolkata asked me and two classmates to co-author a research paper on sentiment analysis of Indian language tweets for an IEEE conference. We had 3 weeks until the submission deadline, but the work — data collection, model training, result analysis, and paper writing — would typically take 6 to 8 weeks.

Task: I was responsible for the data collection and preprocessing pipeline, as well as the results section of the paper. I needed to collect, clean, and label at least 10,000 Hindi-English code-mixed tweets within 10 days so that the model training could start.

Action: I broke my 10-day window into clear milestones: Days 1-2 for setting up the Twitter API scraper and collecting raw data, Days 3-5 for cleaning and preprocessing, Days 6-8 for labeling (I recruited 4 classmates as volunteer annotators, creating a simple Google Form for sentiment labeling to speed things up), and Days 9-10 as buffer for quality checks. I automated the preprocessing using a Python script that handled transliteration, emoji extraction, and stopword removal — which saved approximately 20 hours of manual work. I also set up a shared progress tracker so my teammates could see data readiness in real time and plan their model training accordingly.

Result: I delivered the cleaned, labeled dataset of 12,500 tweets (2,500 more than the target) by Day 9 — one day ahead of schedule. The paper was submitted 6 hours before the deadline. It was accepted for presentation at the conference, and we received a "Best Paper" nomination in the NLP track. The professor later cited our pipeline approach as an example of efficient research methodology in his lectures.

Situation: I was the event coordinator for a coding contest at our college in Coimbatore. The event was originally scheduled for March, giving us 6 weeks of preparation. Two weeks before the event, the college administration moved our date up by 10 days to avoid a clash with university exams. We suddenly had only 4 days to finish work that was planned for 14 days.

Task: I needed to ensure that participant registration (target: 150), problem setting (15 coding problems across 3 difficulty levels), the judging platform, and logistics (venue, certificates, prizes) were all ready 10 days earlier than planned.

Action: I immediately called an emergency meeting with my 6-member organizing committee. I triaged every remaining task into three categories: must-have (judging platform, problems, venue), nice-to-have (printed certificates, opening ceremony), and cut (merchandise, photo booth). We eliminated the nice-to-have and cut items entirely. I assigned two members exclusively to problem setting (they each created 7 problems and we peer-reviewed for quality), two to the HackerRank contest setup, and I handled registrations and venue logistics. For registrations, I switched from a Google Form (which required manual follow-up) to an Unstop listing, which automated confirmation emails and attendee tracking. I extended the registration deadline by 1 day but added an "early bird" incentive (guaranteed swag) to accelerate sign-ups.

Result: We had 138 registrations (92% of our target) and the event ran smoothly with no technical issues on the judging platform. Participants rated the event 4.3 out of 5 — only marginally lower than the previous year's 4.5 rating, which had 6 weeks of preparation. The dean later used our event as an example of "student resilience" in the college newsletter. The experience taught me that ruthless prioritization is the most underrated skill under pressure.

Situation: During my fifth semester at PES University Bangalore, I had three major deadlines falling in the same week: a DBMS project submission (worth 30% of the course grade) on Wednesday, a paper presentation competition at a neighboring college on Thursday (where I was representing our department), and the final rehearsal for our college's annual dance performance (which I was choreographing) on Friday evening.

Task: I could not skip any of the three — the DBMS project was a grade-critical submission, the paper presentation was a departmental commitment, and 15 dancers were counting on me for the choreography. I needed a plan that would let me deliver on all three without compromising quality on the most important ones.

Action: I used a priority matrix to rank the three by impact and flexibility. The DBMS project (highest academic impact, no flexibility on deadline) came first. The paper presentation (moderate impact, I was already prepared, just needed rehearsal) came second. The dance rehearsal (important but the group could rehearse the first half without me) came third. I front-loaded the DBMS project by working on it over the weekend and Monday, aiming to submit by Tuesday night — a day early. For the paper presentation, I practiced in 20-minute slots during lunch breaks on Monday and Tuesday. For the dance rehearsal, I recorded a video walkthrough of the choreography on Monday night and sent it to the group so they could practice without me on Tuesday and Wednesday evenings. I joined the final rehearsal on Friday as planned.

Result: I submitted the DBMS project on Tuesday night, a day ahead of the deadline, and scored 27 out of 30. I placed second in the paper presentation competition. The dance performance went smoothly and received the audience choice award at the fest. The video walkthrough idea was so effective that the dance club adopted it as a standard practice for future events. I learned that the key to managing competing priorities is not working harder but working in the right sequence.