Don’t be a stubborn interviewer!
During a recent interview at a Pune-based startup, I encountered a problem statement that involved a rather uncommon custom data structure.
The problem, summarized on one page with about 150 words, took me around 10 minutes to fully comprehend.
I discussed my approach with the interviewer, proposing the use of a specific data structure tailored to the problem's requirements:
Element = pair<pair<int,int>, vector<int>>;
vector<Element> vp;However, despite my clarity, the interviewer insisted on using a HashMap. With just 20 minutes left, he abruptly requested a switch to HashMap and solving the problem. This change, coupled with the lengthy problem statement, led me to overlook two important edge cases, ultimately costing me the opportunity.
“After checking his LinkedIn profile, I found that the interviewer was a 5-star coder on CodeChef. This suggests he was so confident in his approach that he was not ready to accept an alternative approach. His stubbornness and his ultimate preference for the HashMap cost me an opportunity.”
PS: I am myself a competitive programmer with a rank under 100 in CodeChef long challenges.
Typical competitive coders.
Cant "develop" shit, but are very efficient at counting frog jumps.
Ohh, that hurt’s
Childish behaviour by Interviewer.
They think interviews are stringent tests rather than a collaborative call.
Don't be so confident just by looking at the codechef profile he might be solving problems on other platform, though it's surely is a problem with interview done by sde1 or sde2 they are quite stubborn for seniors engineer they are ready to accept any solution unless it does the required task.
I faced the same with one of investment banks. Funny part was: when I benchmarked both the codes after the interviews and my solution was slightly faster with same time and space complexities.