3 ms·
It's kind of odd how much of the interview process for a developer is counter-intuitive. Like the coding challenge. The naive expectation is that you quickly
by treis 5y ago
It's kind of odd how much of the interview process for a developer is counter-intuitive.
Like the coding challenge. The naive expectation is that you quickly and correctly solve the problem they give you. But the actual expectation emphasizes asking about edge cases and collaborating with your interviewer. Solving the problem quickly and correctly is not actually the optimal solution. Partially because it doesn't allow you to demonstrate collaboration but also because the interviewer might think you've seen the problem before and have memorized a solution. Even though memorizing a solution and regurgitating it is basically what everyone does on these challenges.
General work experience questions are similar. You don't want to tell the truth. You want to give a STAR (situation, task, action, result) answer that shows you have whatever characteristic they're looking for. The majority of people won't have actual good stories for most of those so just hammer that grain of truth into whatever the interviewer wants.
I'd add thoughts about system design, but I really suck at those and still haven't quite figured out what everyone's looking for.
- mrtranscendence 5y ago> The majority of people won't have actual good stories Oh, god. Sometimes it's like pulling teeth to get people to respond with concrete stories. Lie for all I care, but tell me something about what you've done in the past. Granted, I haven't interviewed anyone since I was in college hiring other college students, so hopefully people in the real job market do better here.
- deleted 5y ago[deleted]
- pgwhalen 5y agoI've given ~50 system design interviews. Personally, I'm looking for a combination of problem solving and collaboration skills. I am not particularly concerned about the quality of the system they have designed by the end of the interview, I'm more interested in: - whether they understand an issue when I try to "poke a hole" in their design - whether they can quickly synthesize that problem into a possible solution (even if it isn't the best solution) and what the tradeoffs of the solution are - how easy it is for me to understand the solution as they're explaining it Essentially, I am testing their ability to contribute in a technical design discussion while remaining humble and open minded. I admit it would also be nice to test their ability to actually design a good system, but rating someone on their ability to do that in a reasonable time frame seems far too fraught with biases around what "good" is or the degree of familiarity with the domain.