Importance of context, follow-up questions, and not using lambdas
This month I thought I was going to chat about AI and my experience so far with it but that might be next month. Instead, I am going to chat about a recent interviewee I had.
If you didn’t know, as of March, I am still looking for my next role. Reach out! if you think I might be a good fit. Anyway…
Interviewing is hard. This is true both for the interviewer and the interviewee. I’ve conducted a few interviews in my career, and I have also been interviewed many, many, more times — to many. Practice helps for sure but it does not make it easier (or more likely) that one will land a role — or that you will higher the “right” person.
So much can and has been said on hiring the “right person” problem, I want to focus on something that happened to me. A failing on both the interviewer and interviewee. I could have done better and I think the interviewer could have done better too. What could we have done better?
- Remove assumptions, ask at least 1 follow-up question.
- Assume the best in the person.
So this is the setup…
I was given a tech home project. No limitations on technology stack or tools to use. Wonderful! I was even encouraged to use generative AI. More on this next month.
The interview was basically building V1 version of the company’s product I was applying for. Without going into the details of their business model, the problem was to architect a system to manage meal orders and auto place orders on behalf of the user if they haven’t by a particular time.
Regardless, the order being placed needed to conform to some dietary restrictions previously imposed. I have to say that the intended users were patients in a hospital. It is relevant in my thinking.
Other than that, very little was given in terms additional information… so here go my assumptions.
Given the nature of the business I assumed
- Although critical functions, user demand is overall low.
- Not all users will place orders at the same time.
- This system would run in environments that have hundreds of users not thousands or hunderds thousands.
- This system would run “on-prem” thinking that commissary are generally near or in the same building as the patients.
In retrospect, even thought it was a take-home project, I should have asked these questions…
I even second guessed my self, I was surprised that the take-home did not have an obvious case for lambda usage as it is all the rage. But then, it maybe is a test to know when NOT to use lamdbas. So I pressed on, without asking questions.
I was given three hours over the course of a week. I realistically spent more like 5 hours. I spent most of my time writing a design document including schema, model, end-points, etc and I fed it to Claude Code. I buttoned down the critical business logic and turned in the take-home. Stressed, tired, but happy with my thinking I turned in my work.
A few days later I got the verdict: rejection. I am numb now but it stung.
Thankfully I had the presence of mind to follow-up, and ask why. And to their credit they answered! They wanted me to use lamdbas. But why! Lamdbs are great but in this case, they do not fit.
I will follow up with a thought about when lamdbas should be used but I wish that even with a take-home project the interviewer had been a little-bit curious, had asked at least one question. It may not have changed the verdict but at least a conversation would have been had. It could have been a learning opportunity for everyone.