Summary
I am submitting this issue to provide formal feedback regarding the coding assessment. The current test design contains technical contradictions that enforce anti-patterns, and the administration process lacks transparency.
- Technical Contradiction: Static Data vs. Runtime Calculation
The test provides static data at build time but explicitly enforces a "runtime calculation" requirement.
• Current Behavior: The test fails or rejects solutions that pre-compute static data.
• Engineering Best Practice: In a real-world production environment, static data should be pre-computed to allow O(1) access. Enforcing runtime calculation for static datasets is an artificial constraint that negates standard optimization techniques.
• Impact: This forces candidates to write inefficient code that would be unacceptable in a professional engineering context.
- Process Integrity: Silent Updates
The rules/README were updated retroactively after candidates had already started or submitted their solutions.
• Making "silent changes" without notifying active applicants is fundamentally dishonest.
• It wastes candidates' time and creates an unfair evaluation environment.
- Lack of Communication
I attempted to reach out regarding these inconsistencies but received no response. Blaming "LLM behavior" or other external factors for design flaws, while failing to support applicants, reflects poorly on the engineering culture.
Recommendation
• Remove artificial constraints that contradict real-world performance optimization.
• Maintain a changelog for test requirements and notify candidates of any changes.
• Establish a clear channel for addressing ambiguities in the test specifications.
Summary
I am submitting this issue to provide formal feedback regarding the coding assessment. The current test design contains technical contradictions that enforce anti-patterns, and the administration process lacks transparency.
The test provides static data at build time but explicitly enforces a "runtime calculation" requirement.
• Current Behavior: The test fails or rejects solutions that pre-compute static data.
• Engineering Best Practice: In a real-world production environment, static data should be pre-computed to allow O(1) access. Enforcing runtime calculation for static datasets is an artificial constraint that negates standard optimization techniques.
• Impact: This forces candidates to write inefficient code that would be unacceptable in a professional engineering context.
The rules/README were updated retroactively after candidates had already started or submitted their solutions.
• Making "silent changes" without notifying active applicants is fundamentally dishonest.
• It wastes candidates' time and creates an unfair evaluation environment.
I attempted to reach out regarding these inconsistencies but received no response. Blaming "LLM behavior" or other external factors for design flaws, while failing to support applicants, reflects poorly on the engineering culture.
Recommendation
• Remove artificial constraints that contradict real-world performance optimization.
• Maintain a changelog for test requirements and notify candidates of any changes.
• Establish a clear channel for addressing ambiguities in the test specifications.