4 ms·

People on both sides of the table have the common misconception that coding challenges are about solving the problem. They're not, coding challenges are there f

People on both sides of the table have the common misconception that coding challenges are about solving the problem. They're not, coding challenges are there for me to gain an insight into how you think through problems and the questions you ask are 100x more important to me than the code you write. I have a colleague who, every coding challenge, immediately started by writing a bunch of tests and asking questions around the edge cases so that he could clarify the exact specs of the task he was being asked to perform. Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies. The story he was trying to tell was that he was an engineer that considered understanding the problem to be a much more important task than understanding the solution and he managed to tell it via the way he approached whiteboard coding.

financltravsty 3y ago
Tell that to my Google interviewer.
mekoka 3y ago
> Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies. Different problems test for different skills. Perhaps that colleague just misunderstood what he was being tested on. Linus Torvalds had this to say: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Not every coding challenge is about software design skills. A large number is about the programmer's potential to code to DS & A. It's assumed that design, philosophy and other moot software skills can be picked up, or that internal coding standards and code reviews somewhat mitigate a lack in that area. But I can very well see a mature engineer being annoyed by someone incessantly asking to confirm small details on a problem where they could make their own decision about terminal and exceptional conditions. Even if they have to explain them later. After you probe your interviewer once or twice on edge cases, you're usually told to assume the simplest situation. This should nudge you to what you're actually being tested on. No need to beat around the bushes, just solve the problem. Also, to gain insight into the culture of an organization, don't just assume or infer things, like that colleague did. Ask proper questions. Express that working in an organization with a mature engineering culture is a concern of yours. Ask about code review, software development philosophy, etc. You've shown yours, ask them to show theirs.

financltravsty 3y ago

Tell that to my Google interviewer.

mekoka 3y ago

> Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies. Different problems test for different skills. Perhaps that colleague just misunderstood what he was being tested on. Linus Torvalds had this to say: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Not every coding challenge is about software design skills. A large number is about the programmer's potential to code to DS & A. It's assumed that design, philosophy and other moot software skills can be picked up, or that internal coding standards and code reviews somewhat mitigate a lack in that area. But I can very well see a mature engineer being annoyed by someone incessantly asking to confirm small details on a problem where they could make their own decision about terminal and exceptional conditions. Even if they have to explain them later. After you probe your interviewer once or twice on edge cases, you're usually told to assume the simplest situation. This should nudge you to what you're actually being tested on. No need to beat around the bushes, just solve the problem. Also, to gain insight into the culture of an organization, don't just assume or infer things, like that colleague did. Ask proper questions. Express that working in an organization with a mature engineering culture is a concern of yours. Ask about code review, software development philosophy, etc. You've shown yours, ask them to show theirs.