HR & Behavioural Web Development Interview Questions

Situation: during my final year, a local coaching institute needed a website. Task: I had to build a responsive site with course pages and an enquiry form in three weeks. Action: I designed the layout in Figma, built it with semantic HTML, CSS Grid and JavaScript, stored enquiries in MySQL through PHP and deployed it on shared hosting. Result: it scored above 90 in Lighthouse and brought enquiries within the first month.

I follow MDN Web Docs, web.dev and the release notes of Chrome and Firefox, and I check Can I Use before adopting a new feature. Every few weeks I build a small demo with something new, such as container queries or the popover attribute, and push it to GitHub. For example, after reading about native lazy loading, I replaced a JavaScript library in my project and reduced the bundle size.

Situation: a designer wanted a five-column pricing table on mobile. Task: I had to deliver the design while keeping it usable on small screens. Action: I built a quick prototype on a real phone, showed that text became unreadable, and proposed a swipeable card version that kept the same visual style. Result: the designer agreed, we updated the Figma file together, and mobile conversions on that page improved after launch.

Situation: a marketing team needed a campaign landing page in two days. Task: I had to ship a responsive, fast page with a lead form. Action: I confirmed the must-have sections first, reused existing components and a CSS grid template, and tested on three devices while building instead of at the end. Result: the page went live on time with a Lighthouse score above 90, and I added animations in a later update.

Situation: after a release, users reported the checkout button did nothing on some phones. Task: I had to find and fix it quickly. Action: I reproduced it on an older Safari, found that a new array method was unsupported, rolled back the change, then added a polyfill and Babel targets for those browsers. Result: the fix shipped the same day, and we added real-device checks to our release checklist.

I start with MDN for the precise definition, then write tiny experiments in the browser console to see the behaviour myself. If it is still unclear, I watch a short explanation and try to explain it in my own words in notes. For example, I learned the event loop by predicting the output of mixed setTimeout and promise code, checking it, and repeating until my predictions were right.

Situation: a client asked why their site was slow on mobile. Task: I needed approval to optimise images, which meant extra work. Action: I avoided jargon, showed a side-by-side video of load times, and compared large images to sending a heavy parcel by post. Result: the client approved the work, load time dropped from 7 to 2.5 seconds, and they trusted my later suggestions more.

Situation: our product listing page took over 6 seconds to become interactive. Task: I was asked to bring it under 3 seconds. Action: I profiled it in DevTools, found a large unused library and unoptimised images, replaced the library with native code, converted images to WebP with lazy loading, and deferred third-party scripts. Result: interaction time dropped to about 2.4 seconds and bounce rate fell noticeably.

I chose PHP because it powers a large share of websites, including WordPress, and many Indian agencies and product companies still hire PHP and Laravel developers. It is quick to deploy on almost any hosting. I started with plain PHP to understand requests, sessions and databases, then learned Laravel. In my project, a course enquiry portal, Laravel's validation and Eloquent let me deliver features in half the time.

Situation: I joined a project with a 10-year-old PHP codebase full of mixed HTML and SQL. Task: I needed to add online payments without breaking existing features. Action: I wrote tests around the checkout flow first, extracted database code into a small class using PDO, and added the payment module separately. Result: payments launched with no regressions, and the team adopted the same approach for later changes.

Situation: in my internship, a training institute tracked batches, students and fees in spreadsheets. Task: I had to design a MySQL schema for a web portal. Action: I normalised data into students, batches, enrollments and payments tables, added foreign keys and indexes on common filters, and wrote views for monthly reports. Result: reports that took a day manually now loaded in seconds, and data errors dropped sharply.

I always test queries on a local or staging copy first, run a SELECT with the same WHERE clause before any UPDATE or DELETE, and wrap risky changes in a transaction so I can roll back. I confirm a fresh backup exists before migrations. In one release, this habit caught a WHERE condition that would have updated every row, and we fixed it before it ever reached production.

Situation: during a code review, I noticed a teammate built a search query by concatenating user input. Task: I had to flag it without making them feel blamed. Action: I messaged them privately, showed a harmless injection example on staging, and suggested a prepared statement fix with a short snippet. Result: they fixed it before release, and we added a SQL injection check to our review checklist.

Situation: a manager wanted to launch a form without server-side validation to save a day. Task: I needed to protect the product without blocking the launch. Action: I explained the risk in business terms, data leaks and spam, and proposed shipping core validation and rate limiting now, with less critical hardening in the next sprint. Result: we launched on time with essential protections and completed the rest within a week.

Situation: in a past project, unusual admin logins were detected at night. Task: as the lead developer, I had to contain and investigate. Action: I disabled the affected accounts, rotated credentials, preserved logs, found a reused weak password, and coordinated with management on informing users as required by India's DPDP Act. Result: no customer data was exfiltrated, and we enforced two-factor authentication for all admin accounts.

Situation: in my first project, I stored user passwords using md5. Task: when a mentor reviewed my code, I had to fix it before launch. Action: I learned why fast hashes are unsafe, switched to password_hash and password_verify, and added rehashing on login for existing users. Result: the system became secure, and since then I always research security best practices before building authentication.

Situation: our e-commerce site went down at 11 PM during a sale. Task: as the on-call developer, I had to restore it fast. Action: I checked logs, found PHP-FPM workers exhausted by a slow query, restarted the service, added an index to fix the query, and kept the team updated every 15 minutes. Result: the site was back in 20 minutes, and I wrote a postmortem with monitoring alerts to catch it earlier.

Situation: a client wanted a big redesign live before a weekend campaign. Task: I had to respect their goal but reduce risk. Action: I explained that weekend issues would have fewer people to fix them, proposed deploying Thursday morning on staging-tested code, and arranged a rollback plan and someone on call. Result: the client agreed, we deployed Thursday, fixed two small issues the same day, and the campaign ran smoothly.

Situation: a new joiner was nervous about deploying to production. Task: I was asked to make them independent within a month. Action: I wrote a step-by-step deployment checklist, let them deploy to staging while I watched, then paired on two production releases with them driving. Result: they handled releases alone after three weeks and later improved our checklist with a rollback section.

I enjoy building things people use directly. During college, I made a website for a local library, and seeing members search books online gave me real satisfaction. Web development lets me combine design with logic, from HTML and CSS to PHP and MySQL, and see results immediately. I want to grow in a team that ships real products and eventually take ownership of complete features end to end.