A portfolio can show that an app has attractive screens. It tells you less about what happens when a save request times out, two devices edit the same workout, or a user signs out with unsynchronized records.
Those situations reveal engineering judgment. Evaluating fitness app developers means examining how they preserve data, explain decisions, test failures, and respond to review feedback.
The assessment should reflect your product. A personal exercise log and a connected coaching platform have different requirements. Start with the actual responsibilities of the role, then select code and scenarios that make those responsibilities observable.
1. What to Look for in a Code Review
Read a small feature from input to persistence. Follow what happens when the user enters a value, submits it, receives an error, and tries again.
Readability and responsibilities
Names should explain meaning. completedSets communicates more than data2. Functions should have responsibilities that a reviewer can describe without reconstructing the entire application.
Look for appropriate separation between interface behavior, validation, storage, and network communication. A screen that performs all four may be difficult to test or change.
However, splitting every operation into several abstractions can also obscure a simple workflow. Ask what each boundary makes easier.
Correctness before preferences
A formatting disagreement is different from a data-loss bug. Classify comments by their consequence:
- Correctness: A failed save clears the user’s entries.
- Security: A request can access another member’s workout.
- Maintainability: A rule is duplicated across several screens.
- Style: A name differs from an established project convention.
Explain the effect rather than asking candidates to match your personal taste.
An illustrative review example
Suppose a save handler sends a workout to the API and immediately resets the form. A reviewer should ask whether the reset occurs after reliable persistence or merely after starting the request.
A better structure might validate the input, persist it locally, mark synchronization as pending, and then update the interface. Whether that design is appropriate depends on the offline requirements.
The useful review comment is specific:
If this request fails, the entered sets disappear. Can we preserve the form or commit the session locally before resetting it?
That invites a solution and exposes the failure mechanism.
2. Evaluating Mobile Architecture
Architecture questions should connect design choices to behavior.
Ask: “Which parts of this feature would change if we replaced the API or introduced offline logging?”
A strong answer identifies dependencies and explains how business rules remain testable without rendering a screen or making real network calls.
For native versus cross-platform development, discuss required device capabilities, team knowledge, dependency support, and platform-specific behavior. A framework preference is useful only when the candidate can explain its consequences.
For state management, ask who owns the current workout and how stale responses are handled. An older network response should not silently replace a newer edit.
Performance discussions should begin with measurement. Ask how the candidate would investigate a slow history screen: database queries, excessive rendering, image loading, and memory use are different possibilities.
Also examine dependency choices. A package should solve a clear problem, have an understood maintenance burden, and avoid unnecessary coupling to core product logic.
3. Fitness-Specific Engineering Scenarios
Domain details can expose defects that a generic CRUD exercise misses.
Workout history and progress
Review how sets, repetitions, duration, and weight are represented. Explicit units matter: a value of 50 is ambiguous without knowing whether it means kilograms or pounds.
Historical records should remain understandable when a routine changes. Editing an exercise template should not unintentionally rewrite the meaning of completed sessions.
For progress charts, inspect missing values, aggregation boundaries, and time zones. Missing weight data should not automatically become zero. A session near midnight may belong to a different calendar day depending on the product’s reporting rules.
For related product context, see M TECHUB’s article on fitness tracking app development. Keep the technical assessment focused on the tracking workflows your application actually requires.
Nutrition, notifications, and integrations
Nutrition records need clear portion units and data provenance. Changing an entry should produce consistent totals without implying that source estimates are exact measurements.
Notifications require attention to preferences and schedule changes. A canceled reminder should not remain active because an old schedule was cached.
Wearable integrations add permission handling and reconciliation questions. Imported activity may overlap with manually recorded activity. Ask how the application identifies sources and avoids accidental double counting.
Assess these concerns when the feature belongs to the product. Do not reject a capable mobile developer for lacking integration trivia unrelated to the role.
4. Assessing Backend and Data Handling
Consider a hypothetical workflow: a user completes a workout offline, closes the app, and reconnects the next day.
Ask where the session is stored, what survives an application restart, and how the server recognizes repeated delivery.
One possible design uses durable local storage and a queue of pending operations. A local transaction can save the workout and its pending operation together, reducing the risk that one exists without the other.
The candidate should explain:
- Stable identifiers for sessions and operations.
- Server-side authorization and payload validation.
- Retry behavior for transient failures.
- Duplicate request handling.
- Concurrent edits and deletion propagation.
A timeout does not establish that the server rejected the request. It may have committed the workout before the response was lost. Repeating that operation must not create another workout.
Conflict resolution also deserves explicit treatment. “Latest timestamp wins” can discard valid changes and becomes unreliable when device clocks disagree.
Database and caching decisions should follow access patterns and consistency requirements. Ask how stale cached records are invalidated and whether fetched data can overwrite pending local edits.
5. Testing and Debugging
Ask: “How would you test that workout logging continues during temporary network loss?”
A strong response describes outcomes and failure points:
- Entered sets remain available after restarting the app.
- Repeated synchronization produces one logical server record.
- Expired credentials preserve pending work.
- Permanent validation errors do not trigger endless retries.
- Switching accounts does not upload records under the wrong identity.
Unit tests can cover validation, conversions, and state transitions. Integration tests can verify persistence, API contracts, authorization, and duplicate handling. UI or end-to-end tests can cover the essential user journey.
Include a test where the server commits but the client never receives confirmation. Disconnecting before a request is sent tests a different condition.
For debugging, ask for a reproducible report containing steps, expected behavior, actual behavior, environment, and sanitized diagnostics.
Performance investigations should use representative data and devices. A universal coverage percentage or a passing test suite alone does not demonstrate reliability.
6. Security and Privacy During Code Review
Follow data through collection, storage, transmission, diagnostics, and deletion.
Reviewers should investigate privileged credentials embedded in client code, missing authorization checks, sensitive request bodies in logs, and permissions unrelated to the feature.
Authentication and authorization are separate. Knowing who made a request does not establish that they may read a particular member’s records. Enforce that boundary on the backend.
Check appropriate credential storage, protected network communication, local data exposure, and third-party analytics configuration. A crash report can leak information even when application logs look clean.
Ask candidates to explain the threats their controls address and demonstrate how those controls are tested. Naming a security standard or using encryption does not establish that the entire application is secure.
Fitness and health-related records deserve careful handling, but legal obligations depend on the application, data, relationships, and markets. A code review cannot independently establish blanket legal compliance.
7. Designing a Fair Technical Assessment
Provide a small, deliberately imperfect workout feature using synthetic records. Clearly label it as an interview fixture.
Exercise requirements
Ask the candidate to:
- Identify the most consequential defects.
- Explain a prioritized repair plan.
- Implement one bounded improvement.
- Add or describe tests that demonstrate the improvement.
- Discuss what remains unresolved.
The fixture can include an API timeout, lost form state, and duplicate synchronization. Avoid unrelated defects that turn the exercise into a guessing game.
Clarifications and edge cases
Candidates should clarify whether offline writes are required, whether sessions can be edited, and whether multiple accounts or devices are supported.
Discuss process termination, expired authentication, partial batch success, and conflicting edits. These can be design questions rather than mandatory implementation tasks.
Fairness and scope
State the expected time commitment and provide an equivalent collaborative option where practical. Avoid excessive unpaid work or tasks that could serve as usable commercial deliverables.
Require a particular stack only when it is relevant to the job. Explain permitted documentation and tool use in advance.
Common weaknesses include catching every exception without recovery, retrying permanent errors, keeping pending records only in memory, and adding abstractions without resolving the defect.
Ownership and handover
When assessing an external development team, examine whether another engineer could build, test, and maintain the delivered application. Clarify access to repositories, infrastructure, documentation, and third-party dependencies.
Technical maintainability and contractual rights are separate questions. For the contractual discussion, see M TECHUB’s article on fitness app development contracts and code and data ownership. Confirm the actual rights and handover obligations in your agreement.
8. A Structured Evaluation Rubric
Use the following descriptions as discussion aids. They are not a scientifically validated hiring instrument.
| Area | Weak | Acceptable | Strong |
|---|---|---|---|
| Readability | Responsibilities are unclear | Main workflow is understandable | Clear boundaries and proportionate abstractions |
| Correctness | Handles only the success path | Covers required behavior | Identifies subtle failures and preserves data |
| Architecture | Relies on pattern names | Explains a workable design | Connects alternatives to constraints |
| Testing | Tests mirror implementation | Verifies important outcomes | Tests failures and explains remaining gaps |
| Data and security | Trusts client identity or exposes records | Enforces basic boundaries | Traces data lifecycle and consistency risks |
| Collaboration | Cannot discuss feedback constructively | Explains changes and questions | Prioritizes evidence and revises assumptions |
Record examples supporting each judgment. Decide role-specific priorities before interviewing so an impressive presentation does not overshadow a serious correctness issue.
9. Red Flags and Assessment Mistakes
Investigate ignored error states, unexplained complexity, sensitive logging, and absent consistency rules. Skipping tests deserves clarification rather than an automatic conclusion: the time limit may have forced a trade-off.
Repeatedly treating review comments as personal criticism can impede collaboration. Reviewers also have a responsibility to make comments respectful and specific.
Avoid judging candidates solely on typing speed, preferred formatting, or familiarity with one library. Give them room to ask questions and revise an initial answer.
A useful assessment reveals how someone reasons when the first solution is incomplete.
Conclusion
Code reviews and practical exercises make engineering decisions visible: what the developer protects, what they test, and how they respond when behavior fails.
Choose a representative workflow, introduce realistic failure conditions, and evaluate the reasoning alongside the implementation. Match expectations to the role and product.
Which code-review issue most often signals a deeper engineering problem to you, and what do you investigate next?
Top comments (0)