How to Hire a Frontend Developer (Backbone.js)

• aAvoid using events altogether
• bManually delete event handlers from models
• cUse the Backbone.View remove method to unbind events and remove DOM elementsCorrect
• dRely on garbage collection to automatically clean up views

Explanation: Using the Backbone.View remove method ensures that event listeners are properly unbound, which is crucial for preventing memory leaks in complex applications.

Why it matters: Tests view lifecycle discipline, the most important mid-level Backbone habit. Follow up: view.remove() only cleans up listeners registered with listenTo — what else (window resize handlers, intervals, third-party widgets) must be torn down in an overridden remove()?

• aImplement constant polling for data changes
• bUse model.fetch with success and error callbacksCorrect
• cRely solely on global AJAX error handlers
• dUse synchronous AJAX calls to ensure data integrity

Explanation: Using model.fetch with dedicated success and error callbacks allows for precise control over data flow and error management, which is essential in real-world applications.

Why it matters: Evaluates explicit, per-request error handling for fetch. Follow up by asking how they'd surface a 401 versus a 500 differently, and how the returned jqXHR or the model's error event can be used for retries and aborting stale requests.

• aRely solely on jQuery hashchange events without integrating Backbone.Router
• bDefine routes in Backbone.Router and trigger corresponding events to update viewsCorrect
• cReload the entire application every time the URL changes
• dUse window.location changes to force a full page refresh

Explanation: Defining routes in Backbone.Router and using them to trigger events allows the application to update specific views while maintaining overall state, a common requirement in SPA development.

Why it matters: Tests router-driven state management without full page reloads. Ask how they swap the active view on route change (removing the previous one to avoid zombies) and when to use router.navigate with {trigger: false} to update the URL without re-running the route handler.

• aOverride the collection's comparator with a custom function that considers multiple attributesCorrect
• bRely exclusively on server-side sorting to manage order
• cReplace the entire collection whenever data changes
• dManually call the sort method after every model update

Explanation: Overriding the collection's comparator to handle multiple attributes allows the collection to automatically re-sort models when they change, which is a best practice in dynamic applications.

Why it matters: Validates multi-attribute comparator design. Strong candidates add the nuance that Backbone collections only sort automatically on add/reset, so the comparator is combined with this.listenTo(this, 'change:priority', this.sort) to keep order correct when attributes change.

• aRely on global variables to share modules across the application
• bBundle all modules in a single file to reduce HTTP requests
• cUtilize AMD's define function to modularize components and load dependencies asynchronouslyCorrect
• dDynamically inject modules into the DOM as needed

Explanation: Using AMD's define function allows developers to structure Backbone.js components into modular, reusable units and benefit from asynchronous dependency loading, promoting better maintainability and performance.

Why it matters: Many Backbone codebases still use RequireJS. Confirms the candidate can structure views and collections as define([...], function (Backbone, _, tpl) { ... }) modules, understands shim config and the r.js optimizer, and can reason about moving them to Webpack.

• aDefine static routes for each possible URL variant
• bHard-code parameter values directly in each view
• cImplement dynamic route parameters with custom regular expression patternsCorrect
• dBypass Backbone.Router and delegate routing to the server

Explanation: Using dynamic route parameters with custom regex allows the router to flexibly match different URL structures, making it suitable for applications with unpredictable or numerous route variations.

Why it matters: Tests advanced Router knowledge beyond the routes hash. Seniors should know router.route(regex, name, callback), how captured groups become handler arguments, optional segments and splats, and how to keep deep-linkable state in the URL with pushState.

• aRely on garbage collection without manual intervention
• bExplicitly unbind all events and call view.remove() during view teardownCorrect
• cUse global event listeners to manage view lifecycle
• dDetach the view DOM element and leave events intact

Explanation: Explicitly unbinding events and removing the view ensures that no lingering listeners or DOM references remain, which is essential for preventing memory leaks in production applications.

Why it matters: Ensures the candidate can eradicate leaks systematically, not just patch one view. Follow up by asking them to describe a heap-snapshot comparison, how to read the retainers of a detached DOM tree, and how they'd encode teardown in a base view class so the whole team gets it for free.

• aRender the entire collection regardless of visibility
• bImplement virtualized rendering to only render visible modelsCorrect
• cLoad all models upfront and refresh the complete view on every update
• dDisable model events to reduce re-renders

Explanation: Virtualized rendering limits the number of DOM elements by only displaying what is visible to the user, which significantly boosts performance when handling large datasets.

Why it matters: Validates the ability to keep large, frequently updated collections responsive. Ask how they'd combine virtualization with batching of incoming updates (e.g., collection.set with merge, then a single debounced render of visible rows).

• aTrigger a complete re-render of the application on each change
• bUse a mediator or event aggregator to centralize and manage eventsCorrect
• cRely on periodic polling to check for updates
• dAllow every view to independently listen to model changes

Explanation: A mediator or event aggregator centralizes change notifications, reducing the risk of multiple views over-responding to a single model change, thus optimizing performance.

Why it matters: Assesses decoupled architecture for multi-view coordination. Strong candidates describe a Backbone.Events aggregator or Backbone.Radio channels, explain how they keep event contracts documented, and recognise the risk of cascading events.

• aUse synchronous module definitions to simplify the debugging process
• bBundle all Backbone components into a single monolithic file
• cDefine Backbone components as AMD modules with explicit dependencies and lazy load non-critical modulesCorrect
• dAvoid using RequireJS for Backbone components and inline dependencies

Explanation: Defining Backbone components as AMD modules ensures that dependencies are managed effectively and non-critical modules can be lazy-loaded, optimizing performance and maintainability in a production environment.

Why it matters: Confirms the candidate can control bundle size in a RequireJS codebase — r.js optimizer bundles per route, require([...]) for non-critical modules — and can plan a migration to Webpack/Vite dynamic import() without breaking existing AMD modules.