harisrid Tech News

A Primer

Ok, it’s not as uncommon as you would think – for both interviewees and interviewers. Sometimes, the interviewee exceeds expectations and solutions the problem faster than expected. Now there’s a couple minutes remaining on the clock : 5 minutes to 10 minutes.

So what do we do? Sure, as an interviewer, I can end the session early and return time back to the candidate, but one thing remains certain – the candidate clearly met a hiring bar’s “bare minimum”. They can successfully move forward to the next steps.

In this case, ( really good ) interviewers will start asking stress test questions to gather more signals and write up stronger cases on behalf of their candidates. Perhaps theirs multiple candidates who met the hiring bar, and a single individual’s outperformance intimates a stronger case. Or the candidate is interviewing for a higher-level position ( e.g. they’re targeting mid-level/senior/staff+ levels ), and we as interviewers can ask level-setting questions to up-level candiditates or down-level candidates ( and if we’re good, we’ll up-level you ).

Now don’t get me wrong. Stress-test questions are harder to ask. Firstly, it’s a skill interviewers need to practice, hone, and refine. Secondly, they’re open-ended : there’s no correct answer to these questions, since they’re meant to probe a candidate’s brain and inform interviewers how a prospective hires problem solves.

Question #1 :

Prompt : Alright, we arrived at a working solution, but can you quickly walk me through how you would refactor your code for a production setting? Walk me through changes you would incorporate.

Justification : Let’s gauge how much experience a candidate has working with an large-scale industrial code base or microservice architectures.

Example Answers :

• Introducing class defintions and methods to support instantiation and invoke methods across multiple modules
• Leverages CONSTANT variable expressions and default initialization values
• Renaming variables for faster searching and readability
• Incorporate unit testing and stubs to compare EXPECTED versus ACTUAL values
• Leverage Git actions and allowing code to go to production IFF all unit tests pass
• Using singleton patterns to avoid multiple instantiation on each execution – save on CPU cycles, memory and optimize performancy

Question #2 :

Prompt : Let’s suppose a Product Manager or a Stakeholder comes in and needs statistics on how often scenarios are encountered. They want to collect data to improve their business. What modifications would you make?

Justification : Has a candidate interacted with business personas in the past who aren’t engineers? Even if they didn’t, do they theoretically know what they would want to show to an such individuals? Can they translate code to business asks? Can they generate and send metrics that inform how to obtain more business value?

Example Answers :

1. TC suggests leveraging production grade logging microservices or analytical tools – GA ( Google Analytics ), Sentry, Titan, or Splunk – to capture statistics of scenarios for fuzzy grep/search.
   • TC extends this and mentions using a trade-off analysis of internal 1st-party tooling with external 3rd-party tooling.
2. TC thinks of events tracking ; can they use a microservice as a producer, send data to a queue asychonously, and have a consumer service listen to the queue to collect stats?
3. TC thinks of storing or sending time series events : (user_id,customer_segment_group, timestamp,scenario) types of tuples.
4. TC mentions analyzing customers by cohort groups.