3 ms·

I agree with the sentiment. Honestly we don't check for syntax or even require the code to compile. We let the candidate write puesdo code which usally isn't su

I agree with the sentiment. Honestly we don't check for syntax or even require the code to compile. We let the candidate write puesdo code which usally isn't super far python and javascript implementations of our challenge. We try to pay attention to the types of questions the candidates asks about context of the code and choices they make in designing a solution. That being said i'd be curious how you evaluate general software engineering ability (e.g. writing clean abstractions, decomposing monolithic methods, and general design). I feel most system design evaluations are a bit too high level or overly broad (e.g. design a library application or make a social network) and coding challenge are too low level.

scollet 6y ago
I like to think of the higher level as creative problem solving. Are they (me in this case) going down rabbit holes? Are they painting a clear picture? Are they communicating that picture? Are they suggesting edge cases? Are they minimizing bloat? Is it too complicated? What are the most important aspects of the design in their eyes? Can they argue for them? Do they understand where a piece fits and if not, do they understand that something has to go there? Can you both step back and definitely outline a logical flow? There's not always one solution, but the approach counts. Lower level is logical problem solving. Can they reason the problem space? Do they start naively? Can they iterate? Can they optimize? Can they explain each of these steps for future iteration? Do you understand what they're writing? Would you work on that code yourself? There's not always one solution here either, but 90% is getting a naive solution that can be optimized by taking a second look. I feel that the naive should be found in 5-15 minutes and you can spend the rest of the time talking about how to optimize. I know I'm rehashing what you probably already know, but at a certain point interviewers are just playing games. If you've found someone you want to work with who can also reason about problems in a timeframe you see fit, well... that to me looks like gold. I like these questions because that's how real systems are going to be built. Take-homes are great, but there is just so much effort wasted in the process if the product can't be understood.
itronitron 6y ago
One of my previous managers would set up the white board interview for a candidate by giving them a simple problem application (not a course-grading system but similar) to draft out on the whiteboard an initial design. Then they would add in additional details/requirements in about three stages. So the candidate at some point would typically have to back track and revise some of their initial design to accommodate the new requirements. It was a good measure of how well they communicated, how they dealt with undoing some of their prior work, and the process was fairly representative of the type of work involved in the position.

scollet 6y ago

I like to think of the higher level as creative problem solving. Are they (me in this case) going down rabbit holes? Are they painting a clear picture? Are they communicating that picture? Are they suggesting edge cases? Are they minimizing bloat? Is it too complicated? What are the most important aspects of the design in their eyes? Can they argue for them? Do they understand where a piece fits and if not, do they understand that something has to go there? Can you both step back and definitely outline a logical flow? There's not always one solution, but the approach counts. Lower level is logical problem solving. Can they reason the problem space? Do they start naively? Can they iterate? Can they optimize? Can they explain each of these steps for future iteration? Do you understand what they're writing? Would you work on that code yourself? There's not always one solution here either, but 90% is getting a naive solution that can be optimized by taking a second look. I feel that the naive should be found in 5-15 minutes and you can spend the rest of the time talking about how to optimize. I know I'm rehashing what you probably already know, but at a certain point interviewers are just playing games. If you've found someone you want to work with who can also reason about problems in a timeframe you see fit, well... that to me looks like gold. I like these questions because that's how real systems are going to be built. Take-homes are great, but there is just so much effort wasted in the process if the product can't be understood.

itronitron 6y ago

One of my previous managers would set up the white board interview for a candidate by giving them a simple problem application (not a course-grading system but similar) to draft out on the whiteboard an initial design. Then they would add in additional details/requirements in about three stages. So the candidate at some point would typically have to back track and revise some of their initial design to accommodate the new requirements. It was a good measure of how well they communicated, how they dealt with undoing some of their prior work, and the process was fairly representative of the type of work involved in the position.