irena-review

Irena Review

My overall impression is that I would not recommend this candidate for a senior or intermediate level position based on this submission alone. But I believe they show promise as a junior engineer and can learn to overcome any design mistakes.

• Formatting: Good outside of minor formatting errors
• Clarity: Not bad
• User Experience:
  • Prints each number on its own line cast to a Float followed by the stack result
  • Quits on empty line (this is normally counted against but was a deliberate choice)
  • ❌ Uncaught Exception Output on Ctrl+C
• Edge Cases:
  • ✅ Floating Point Numbers
  • ❌ Dividing by Zero (Uncaught Exception)
  • ✅ Invalid Input (Exits Program)
  • ✅ Insufficient Operands (Displays Error)
  • ✅ Handles EOF on Input
• Error handling: ❌ Raises uncaught exceptions, causing an abort with trace
• Tests: ❌ Primarily integration tested. Lacking full coverage. Design is difficult to unit test.

Closing Thoughts

For this calculator assignment we ask that the developer provide exemplary code that demonstrates how well they can design things, assuming they can scale down quality to do things quickly, but not necessarily the other way around. This code is implemented in a single file. I would've liked to see the candidate demonstrate a stronger grasp of functional design or OOP. The code is written as 5 procedures in a module. Excluding the imports, no other classes or objects are in use, nor is a public/private interface declared. Control flow is provided by a series of if/else statements. Operators are implemented as a long chain of if/else. There is a lot of state being used when the only state necessary is for the stack. The tests served as a good indicator to the candidate that they may have run into an issue with their design, because the current design did lend itself to isolated unit testing. It appears that the developer encountered this obstacle and opted to ignore this in favor of integration testing files against large StringIO outputs.

Moving forward I am interested in hearing the reasoning behind these design choices and what trade offs might have been knowingly made. A good excercise might be extending the system with an interface that does not behave like StringIO, this might present a challenge in both the code and tests and I would like to see how the developer approaches the problem. I would also like to know more about the developer's ability to design a system in ways other than a procedural programming style.

Possible Exercises

1. Extend operators to include floor division //, exponential **, modulus %, bitwise and &, bitwise or |, and bitwise xor ^ operators.
2. Preserve the current Float/Int notation added entered by the user
3. Added support for irrational numbers (π, e, γ, δ) as well as Infinity
4. Add support for Unary operators like factorial (!) and log that expand the results