Re:How to prepare a technical interview (and why good progra...
by fstopmick on Sunday October 20, 2019 @07:10PM
(#21307967)
A long time ago I came up with an acronym that's served me well as a consultant who has to bounce from one customer to the next and run through interview gauntlets of all types: RACEMOORES:
R: Restate with sample inputs/outputs/diagrams
A: Assumptions ~ scale of inputs, uniqueness, range, variable parameters now and in the future
C: Complexity: runtime complexity, space complexity, etc
E: Edge cases
M: Maintainability
O: Overflow
O: Optimizations
R: Refactoring - DRY / SOLID / etc
E: Extensibility
S: Scalability
I use the "memory palace" heuristic to guide me through this, where each letter is a naked dude waving a flag on a racetrack I vividly remember from Gran Turismo back in the day. Absurdity helps it stick . I start every interview by writing this on the board and checking off the letters as I run through them. I usually stick another "O" in there for "Other stakeholders", depending on the gig.
This happens to work nicely when guiding/assessing interviewees through technical scenarios as well.
R: Restate with sample inputs/outputs/diagrams
A: Assumptions ~ scale of inputs, uniqueness, range, variable parameters now and in the future
C: Complexity: runtime complexity, space complexity, etc
E: Edge cases
M: Maintainability
O: Overflow
O: Optimizations
R: Refactoring - DRY / SOLID / etc
E: Extensibility
S: Scalability
I use the "memory palace" heuristic to guide me through this, where each letter is a naked dude waving a flag on a racetrack I vividly remember from Gran Turismo back in the day. Absurdity helps it stick . I start every interview by writing this on the board and checking off the letters as I run through them. I usually stick another "O" in there for "Other stakeholders", depending on the gig.
This happens to work nicely when guiding/assessing interviewees through technical scenarios as well.