Common questions + model answers

I'm a senior frontend developer at Artlist, on the main product team. A typical week is a mix: focused work on a current feature or performance initiative, code review across the team, occasional architecture or tooling discussions, and tighter collaboration with design and backend on whatever I'm shipping that sprint. Performance and locale infrastructure have been recurring themes in my recent work.

React and TypeScript are the core. Tailwind for styling. The build and CI side is largely standard — modern bundlers, GitHub Actions for CI. I use Node tooling daily, work with REST APIs primarily, and I'm comfortable across the stack from infra to UI when I need to be — my side projects on Cloudflare Pages keep that muscle alive.

I'll use a recent one. At Artlist, our translation infrastructure had grown to a point where we were shipping a lot of bytes to the client just to render localized strings, and a lot of those strings were never used in a given page view. I led an effort to restructure how we organized and shipped translation files — moving toward more granular splitting tied to route boundaries, removing dead keys, and improving how we cache them on the edge.

The result was a measurable reduction in JS sent to the client, faster locale switching, and a cleaner mental model for the team going forward. The interesting part wasn't the code — it was getting buy-in across teams to change a system that was "good enough" but had a clear performance ceiling.

I have a more detailed STAR-format version of this on the stories page.

One that stuck with me was a memory leak in a long-running React page. The symptom was simple — over the course of a session, the page got slower. The cause was deep — a third-party library was keeping references via event listeners that weren't being cleaned up, and a useEffect we'd written had a closure-over-stale-state problem that compounded it. Took a couple of days of Chrome DevTools heap snapshots and isolating the component tree to track down. Fix was small once we found it. Lesson: invest in profiling tools early and trust them over instinct.

A while back I disagreed with a senior colleague on how to handle a piece of state — they wanted to use a global store, I felt it should be local to a component subtree because the state didn't actually need to be shared. We talked it through, I laid out the trade-offs — coupling cost, testability, future maintenance — and we eventually settled on the local approach. The bigger lesson for me was: technical disagreements are easier when you focus on trade-offs, not preferences. "I prefer X" doesn't move anyone. "Here's what we give up if we go global" does.

Ask first. I'd rather spend 15 minutes asking the PM or designer the right question than spend two days building the wrong thing. When the answer doesn't exist yet — when nobody on the team has thought it through — I'll put together a one-page proposal with the assumptions I'm making, share it, and get a quick read. Builds shared context fast and keeps me from making lonely decisions.

Giving: I try to be specific and kind. Comment on the code, not the person. Distinguish between "this is wrong" and "I'd do it differently." Approve when something's good enough, even if I'd have done it slightly differently — perfect is the enemy of shipped.

Receiving: I take the comments at face value, ask for clarification when I don't understand, and push back when I disagree but with reasoning. If I find myself feeling defensive, that's usually a sign the reviewer found something real.

Most of my work has been remote-friendly. The patterns that work: clear written communication, async-first by default — write it down before you Slack it. Document decisions, not just code. Be explicit about handoffs across timezones. And don't underestimate the importance of one-on-ones — even 30 minutes a week with a manager or close collaborator keeps misalignment from compounding.

I'm based in Bangladesh — that's UTC+6. I have flexibility in my schedule and I'm used to overlapping with US and European teams. Specifically, I can comfortably do mornings or late afternoons US time, and full European working hours.

Yes, I'm currently at Artlist. My notice period is [say what's true — typically 30 days for senior roles]. I'd want to leave on good terms and ensure a clean handoff.

Step 1 — deflect:

"I'd love to learn more about the role and the full package before committing to a number. Could you share what you've budgeted for this role?"

Step 2 — if pushed, give the range:

"Based on the seniority of the role and my experience, I'm looking at $70,000 to $90,000 USD base, with the exact number depending on the structure of the package — benefits, time off, equipment, and how the role is set up."

See the full salary negotiation page for the why and the variants.

I'd want to give Artlist proper notice, so realistically about 30 days from accepting an offer. If there's flexibility on either end, we can talk through it.

Yes. I've worked remotely for a long time and I have a setup, a workflow, and the discipline for it. I'd actually prefer it.

useEffect runs after a render commits. You give it a function and a dependency array — when any value in the deps changes between renders, React re-runs the effect after first running the cleanup function from the previous run.

The most common mistake is forgetting that the function captures values from the render it was created in. So if you do something like read state inside an interval, you'll keep reading the stale value unless you update the dependency array, use a ref, or use the functional updater form. The second most common mistake is forgetting to clean up — subscriptions, intervals, event listeners — which leads to leaks.

useMemo memoizes a value — it returns the cached result of a computation as long as the deps haven't changed. useCallback memoizes a function — it's effectively useMemo for a function reference. They're both there to keep referential identity stable across renders, which matters when you're passing things to memoized children or to dependency arrays.

Common mistake: reaching for them too early. They have a cost, and React rendering is usually fast enough that you don't need them. I use them when I have evidence — usually a profiler trace — that referential stability is the actual issue.

Start with the user-visible problem — what's slow? Initial load? Interaction? Some specific action? That decides which tools to reach for.

For load: Lighthouse and the Network tab. Look at LCP, CLS, INP, the waterfall, and what's actually being shipped. Check bundle size with a visualizer. Look for blocking resources, large images, fonts.

For interaction: React DevTools profiler to find slow renders, Performance tab in Chrome to see where the main thread is being eaten. Look for layout thrash, expensive re-renders, big synchronous JS.

The thing I try to avoid is guessing. Measure first, fix the biggest thing, measure again.

var is function-scoped and gets hoisted to the top of its scope and initialized to undefined. let and const are block-scoped, hoisted but in a temporal dead zone — you can't access them before declaration. const additionally prevents reassignment of the binding, though objects and arrays declared with const are still mutable.

In modern code I default to const and reach for let only when I need to reassign. var basically never.

Pyramid-shaped, but with a heavy emphasis on integration tests. Unit tests are great for pure logic — utilities, reducers, calculations. They're less useful for tightly-coupled UI where the test ends up just mirroring the implementation.

For React I lean on React Testing Library — testing behavior, not internals. For end-to-end I'd use Playwright on the critical user flows, not every page.

I think the mistake teams make is over-testing easy stuff and under-testing the hard stuff. Coverage isn't the goal; confidence to ship is.

Default to semantic HTML — buttons are buttons, headings are headings. ARIA is for filling gaps, not first-line tooling. Keyboard navigation should work everywhere — if you can't tab through your UI, you've already lost. Color contrast matters.

For testing, I use axe-style automated checks in CI to catch obvious regressions, and I do manual keyboard-only navigation when shipping anything significant. Screen reader testing for critical flows. It's not optional, especially for an enterprise tool — your users will use it 8 hours a day, accessibility is real ergonomics.