4 ms·

I apply almost the same approach as OP. You can get a relatively good picture at a candidate's engineering skills and thinking ability via "go[ing] deep into th

I apply almost the same approach as OP. You can get a relatively good picture at a candidate's engineering skills and thinking ability via "go[ing] deep into the details", compared to asking algorithm questions. I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. This approach has been working well for senior candidates. It is much harder to interview new graduates.

cmccomas 11y ago
> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit there and watch them do it, they'd freeze up. On the other hand, if you give them a project, give them a timeframe to develop it, then have them walk you through what/why they did, they would absolutely excel. It's sitting there in front of someone(s) and the expectation, that would just cause them to freeze up.
- robryan 11y ago
  Yeah I do wonder what you are getting out of not doing this. If they were to somehow cheat (get someone else to do it) this would be picked up very quickly on the job and waste everyone's time including their own.
- muddyrivers 11y ago
  On the spot. I fully understand that many good engineers could freeze up, myself included. That is the reason the coding question is about a realistic problem. No dynamic programming, graph theory, suffix tree, etc. Also, before the coding, I would talk to the candidates about technologies listed in their resumes. It is mostly like a talk between two engineers in a meetup or a conference, not a technical test. My intention is to build an environment that the candidates can feel like real work environment as much as possible. It also helps to bring up the candidates spirits. We are talking about something we like! As long as the candidates get the logic flow on the solution, can write code down in well-formatted manner, pay attention to corner cases, it doesn't matter if the candidates actually complete the coding, if I think given enough time in a real work environment that the candidate has no problem in doing it. There are some red flags I pay attention to. For example, readable code is very important to me since we work in a team and we spend more time reading code than actually writing it. Once we had a candidate. he got the coding right, but his code was very hard to read. It reminded me of some obscure C code in the past that one statement was trying to do many things so that it became very convoluted. For me, it is not "smart". It is bad engineering.
bsder 11y ago
> I also ask candidates to code on a realistic problem. I just ask them to bring code, and tell them we're going to talk about it. It doesn't have to be their own (it normally is though). It doesn't have to be good code (nobody has yet brought bad code, but I wouldn't really care). I would rather talk to somebody in their own code and language. If they can't explain it to me, then that's a data point, too.
splintercell 11y ago
> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aimed at making the machine work, where as engineering is more about the artistic aspect of building software (which is highly dependent upon experience and tenacity to get the job done). That people wanna hire Engineers, but they test for Programmers. This got me thinking about a common pattern I have been observing. Most of the algorithms I implement in a real world code are very basic. Most of the work I do, revolves around the fact that my code should be easily understandable to other people (and sophisticated algorithms prevent that), that people should be easily be able to modify it, repurpose it or expand it In real world, if I ever was asked to implement FizzBuzz, I wouldn't even open my editor until I understood what is it going to be used for, what future features it will have, and what existing code will it work with. Once I understand it all, I might never write the code which most people write (or I myself write) during a fizzbuzz interview. Maybe it's time to create a Software engineering fizz buzz rather than programming fizzbuzz.
- muddyrivers 11y ago
  The current common interview practice is more like a programming contest. The candidate has to figure out a problem and finish it within ~30~35 minutes. Very competitive, but with little engineering involved. I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.
  - splintercell 11y ago
    The way I envision "Software Engineering Test" as a 20 questions exercise. The interviewer will give a simple user story to the user. "As a user I want to be able to add two numbers". After the candidate implements that, "As a user I want to be able to subtract two numbers". At this point look how the candidate continues. If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points. Then ask him to add multiplication functionality. If at this point he encapsulates the code as a class, good, if not then make him do that and let him choose the encapsulation(with no bonus points). Now the point of this exercise is how good of a job does a developer do of figuring out what does the client want especially when client himself doesn't know what he wants. Somehow once the Calculator class is implemented, the next user story is to "create an interest rate calculation method which offers different interest rate based on credit rating", the idea is the new user requirement is a client asking for to do something quite weird. You can't JUST add this method to the Calculator class. This is the point where the candidate shows how good he is in being an artist with the code.

cmccomas 11y ago

> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit there and watch them do it, they'd freeze up. On the other hand, if you give them a project, give them a timeframe to develop it, then have them walk you through what/why they did, they would absolutely excel. It's sitting there in front of someone(s) and the expectation, that would just cause them to freeze up.

robryan 11y ago
Yeah I do wonder what you are getting out of not doing this. If they were to somehow cheat (get someone else to do it) this would be picked up very quickly on the job and waste everyone's time including their own.
muddyrivers 11y ago
On the spot. I fully understand that many good engineers could freeze up, myself included. That is the reason the coding question is about a realistic problem. No dynamic programming, graph theory, suffix tree, etc. Also, before the coding, I would talk to the candidates about technologies listed in their resumes. It is mostly like a talk between two engineers in a meetup or a conference, not a technical test. My intention is to build an environment that the candidates can feel like real work environment as much as possible. It also helps to bring up the candidates spirits. We are talking about something we like! As long as the candidates get the logic flow on the solution, can write code down in well-formatted manner, pay attention to corner cases, it doesn't matter if the candidates actually complete the coding, if I think given enough time in a real work environment that the candidate has no problem in doing it. There are some red flags I pay attention to. For example, readable code is very important to me since we work in a team and we spend more time reading code than actually writing it. Once we had a candidate. he got the coding right, but his code was very hard to read. It reminded me of some obscure C code in the past that one statement was trying to do many things so that it became very convoluted. For me, it is not "smart". It is bad engineering.

bsder 11y ago

> I also ask candidates to code on a realistic problem. I just ask them to bring code, and tell them we're going to talk about it. It doesn't have to be their own (it normally is though). It doesn't have to be good code (nobody has yet brought bad code, but I wouldn't really care). I would rather talk to somebody in their own code and language. If they can't explain it to me, then that's a data point, too.

splintercell 11y ago

> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aimed at making the machine work, where as engineering is more about the artistic aspect of building software (which is highly dependent upon experience and tenacity to get the job done). That people wanna hire Engineers, but they test for Programmers. This got me thinking about a common pattern I have been observing. Most of the algorithms I implement in a real world code are very basic. Most of the work I do, revolves around the fact that my code should be easily understandable to other people (and sophisticated algorithms prevent that), that people should be easily be able to modify it, repurpose it or expand it In real world, if I ever was asked to implement FizzBuzz, I wouldn't even open my editor until I understood what is it going to be used for, what future features it will have, and what existing code will it work with. Once I understand it all, I might never write the code which most people write (or I myself write) during a fizzbuzz interview. Maybe it's time to create a Software engineering fizz buzz rather than programming fizzbuzz.

muddyrivers 11y ago
The current common interview practice is more like a programming contest. The candidate has to figure out a problem and finish it within ~30~35 minutes. Very competitive, but with little engineering involved. I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.
- splintercell 11y ago
  The way I envision "Software Engineering Test" as a 20 questions exercise. The interviewer will give a simple user story to the user. "As a user I want to be able to add two numbers". After the candidate implements that, "As a user I want to be able to subtract two numbers". At this point look how the candidate continues. If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points. Then ask him to add multiplication functionality. If at this point he encapsulates the code as a class, good, if not then make him do that and let him choose the encapsulation(with no bonus points). Now the point of this exercise is how good of a job does a developer do of figuring out what does the client want especially when client himself doesn't know what he wants. Somehow once the Calculator class is implemented, the next user story is to "create an interest rate calculation method which offers different interest rate based on credit rating", the idea is the new user requirement is a client asking for to do something quite weird. You can't JUST add this method to the Calculator class. This is the point where the candidate shows how good he is in being an artist with the code.