How to Hire a Frontend Developer (Ember.js)

• aRewrite all routes using the old Ember object model
• bIncrementally refactor components to Glimmer componentsCorrect
• cRemove computed properties without replacement
• dReplace controllers with services across the board

Explanation: This approach allows for a smooth transition by gradually updating components to the modern Glimmer syntax while preserving application stability.

Why it matters: Evaluates whether the candidate can modernise a live codebase safely. Classic and Glimmer components coexist, so the migration can proceed one component at a time behind existing tests. Follow up by asking which optional features (template-only-glimmer-components, jquery-integration: false) and codemods they would enable first.

• aIncrease the number of observers
• bDisable data-binding throughout the application
• cSwitch back to manual DOM manipulation
• dUtilize Ember's Glimmer VM and minimize excessive computed propertiesCorrect

Explanation: Leveraging the Glimmer VM and reducing unnecessary computed properties helps in optimizing render cycles and improves overall application performance.

Why it matters: Tests understanding of how Glimmer's autotracking re-renders only what changed, and why long computed-property chains and observers cause wasted recomputation. Ask how they would profile a slow list (Ember Inspector render performance tab, Chrome Performance panel) and when they would add @cached to an expensive getter.

• aEmbed jQuery.ajax calls directly in templates
• bUse Ember CLI to set up periodic polling mechanisms
• cUtilize observers to trigger data fetches on every binding change
• dLeverage Ember Data's adapter customization combined with WebSocket integrationCorrect

Explanation: Customizing adapters to integrate with WebSockets allows real-time updates to be managed efficiently, aligning with modern integration practices.

Why it matters: Validates the candidate can keep real-time updates flowing through the store rather than around it: a service owning the WebSocket connection, pushing normalised payloads with store.push or store.pushPayload so every component bound to those records updates automatically, and tearing the socket down cleanly.

• aRely solely on server-side validation after form submission
• bUse component lifecycle hooks in combination with ember-cp-validationsCorrect
• cHardcode validation logic in the route's model hooks
• dUtilize outdated mixin patterns without leveraging any addon

Explanation: This approach leverages Ember's robust component model and a specialized addon for validations, providing a flexible, maintainable solution for dynamic form handling.

Why it matters: Assesses form-state design with a dedicated validation addon. ember-cp-validations is common in older codebases; ask how the candidate would build the same form in Octane with ember-changeset and ember-changeset-validations, buffering edits so the Ember Data record is only changed on a successful save.

• aLeverage window.fetch inside components without error handling
• bImplement Ember Concurrency tasks to handle asynchronous flowsCorrect
• cUse setInterval to poll for data periodically
• dEmbed asynchronous logic directly into computed properties

Explanation: Ember Concurrency provides a clean, manageable way to handle asynchronous operations, making it ideal for managing state and side effects in real-world scenarios.

Why it matters: Confirms the candidate uses ember-concurrency for user-triggered async work: derived state (isRunning, last.value, last.error) replaces manual flags, modifiers prevent races and double submissions, and tasks cancel automatically when the component is destroyed. Ask them to choose a modifier for type-ahead search versus a payment submit button.

• aRely on Ember Data's default fetching without customization
• bIntegrate Ember Concurrency tasks with debouncing to throttle API callsCorrect
• cIncrease polling frequency to fetch data more aggressively
• dUse observers to trigger API calls on every property change

Explanation: Using Ember Concurrency with debouncing provides a controlled way to manage and reduce API calls, ensuring efficient performance in real-time applications.

Why it matters: Assesses whether the candidate can control request volume in a production dashboard: a restartable task with await timeout(ms) debounces bursts of filter changes, cancels in-flight work, and exposes derived loading state. Follow up by asking how they would combine this with Ember Data caching (backgroundReload, peekAll) to avoid refetching unchanged data.

• aReplace computed properties with native getters and tracked propertiesCorrect
• bConvert computed properties into regular methods invoked from templates
• cRetain computed properties unchanged to preserve legacy behavior
• dRemove computed properties in favor of using jQuery for direct DOM updates

Explanation: Upgrading to Octane involves using native getters and tracked properties, which streamline reactivity and improve overall app performance and maintainability.

Why it matters: Tests mastery of the Octane reactivity model: autotracking removes the need for dependent keys, plain getters recompute only when consumed tracked state changes, and @cached memoises expensive derivations. Ask how they would handle computed.readOnly, volatile, or macro-based properties (filterBy, sort) during the migration.

• aCreate a custom error service that wraps Ember.onerror and forwards errors to a tool like Sentry with contextual informationCorrect
• bDisable global error handling to avoid performance impacts
• cUse try-catch blocks extensively in every component's rendering function
• dDepend solely on browser console logging for error tracking

Explanation: A centralized error service provides a reliable way to capture and report errors with context, essential for diagnosing issues in complex integrations across production environments.

Why it matters: Validates production telemetry design. Seniors should know that Ember.onerror, RSVP's 'error' event, and route error substates catch different failure classes, and that modern apps typically use @sentry/ember (which instruments these hooks) plus release tagging, source maps, and route context for actionable reports.

• aUtilize route lifecycle hooks (beforeModel, model, afterModel) to prefetch data and validate stateCorrect
• bEmploy global JavaScript event listeners to monitor and manage routing changes
• cRely on direct DOM manipulation after each route transition
• dHandle state consistency solely within component lifecycle hooks

Explanation: Route lifecycle hooks are designed to manage asynchronous data fetching and state validation, making them the optimal choice for handling complex transitions in production.

Why it matters: Tests understanding of the router's promise-aware transition pipeline: beforeModel for guards and redirects, model for the primary data, afterModel for dependent data and validation, all of which block rendering until resolved and route errors to error substates. Ask how they would handle aborted transitions, willTransition guards for unsaved changes, and query params with refreshModel.

• aDelegate all session management to server-side processes without client-side integration
• bManage authentication state using global variables across the application
• cUtilize Ember Simple Auth's session management along with custom authenticators to handle token refresh seamlesslyCorrect
• dStore authentication tokens in unencrypted local storage and rely on client-side validation

Explanation: Ember Simple Auth provides a robust framework for session management in Ember.js applications, and custom authenticators offer fine-tuned control over token refresh, ensuring state consistency during user transitions.

Why it matters: Ensures the candidate can design a robust client-side session lifecycle: ember-simple-auth's session service and session stores, a custom authenticator implementing authenticate, restore, invalidate, and token refresh scheduling, cross-tab session synchronisation, and route protection with requireAuthentication.