Should I tell my interviewer I've seen a question? Also, should I study Glassdoor/Leetcode Premium questions for a company?
Have my first interview coming up with a big tech company and want to do some leetcode-prep to get my problem-solving muscles warm before the interview. I've gone on Glassdoor and seen some of the questions people have posted that they’ve gotten from the company in the past year. Should I practice these questions? The obvious answer would be “yes, you’d be crazy not to!”, but I can think of 3 reasons not to:
-
if I am asked if I have seen the question before, many people advocate answering truthfully, in which case, I kind of negate the advantage of studying-company specific questions. There are actually 2 reasons people have for telling the interviewer you've seen a question. One, because they want to know. This is the principle-based reason. Two, because they can tell if you're pretending not to have seen it. This is the pragmatic reason for disclosing that you've seen the question.
-
there’s an argument to be made against studying for any one-specific company and instead beefing up my DS&A skills in general – this would argue for studying questions that are the most common across all (big tech) interviews, not specific to the one I’m interviewing with.
-
This company is very big, and Glassdoor combines questions from multiple teams and departments. The chance that I'll see a question from the team I'm interviewing with is small.
Thanks!
Discussion
(2 comments)- 32 years agoRobinhood, Meta, Course Hero, PayPal
I'm gonna be honest - I had seen 80% of the DSA problems thrown at me during my Meta onsite interview. What my interviewers did to actually get to my organic problem-solving skills instead of content from my memory was to make me solve the problem in a different way (I really like this tactic, so I took it on myself when I did interviews on behalf of Meta).
The way I see it: It's a tough world out there (especially with interviews), and there's nothing wrong with using every (ethical) advantage you can get.
- Of course, if they ask you if you have seen the problem before and you have, you should be honest and tell them.
- But personally, if you have seen the problem before, I don't think you should proactively call it out and potentially get a curveball problem that completely destroys you.
- If you're learning data structures and algorithms properly, you should be able to eloquently explain the problem approach as opposed to dumping out memorized code. I feel like that has value to the interviewer.
Also, should I study Glassdoor/Leetcode Premium questions for a company?
Yes! At the end of the day, a job offer is so valuable, either for accepting or negotiating. If you don't give yourself that company-specific edge, others will, and it becomes so much harder for you to outcompete them. You can strike a middle ground here by only doing problems that show up 2+ times in the past 6 months.
The "interview story" for me with this is my Google onsite back in 2015. I got completely annihilated by my last round, and I found out later that the question I got was a common recently asked question from Google's Glassdoor data. That hurt to say the least.
- 22 years agoMeta, Pinterest, Kosei
You should absolutely look at company-specific Glassdoor and Leetcode -- they give a good sense of the types of questions being asked, and at the very least, it'll help you feel more confident.
On the topic of revealing if you've seen a question before, you don't need to volunteer that information unless they've explicitly asked for it. If the question is very similar to something you've practiced in the past, I'd say something like "I think I've seen a variation of this problem". This protects you in the case where the interviewer asks you half-way through if you've seen the problem before.
I remember in my Facebook interview back in 2017, I told them that I'd seen a version of the question asked, they asked me to do it anyway, and the fact that I was able to deliver the solution helped me a lot.
Remember that the actual solution to a coding problem is only half the battle in an interview. You still need to explain your thought process, communicate with the interviewer, talk through edge cases, etc. So there's still a lot of signal the interviewer gets.
