8 ms·

Interest is not enough, unfortunately. There are plenty of engineers who are attracted to the challenge and excitement of building new things, but have no appre

Interest is not enough, unfortunately. There are plenty of engineers who are attracted to the challenge and excitement of building new things, but have no appreciation for The Right Way to build things. Great engineers think beyond "how" and ask the "should" questions as well. Mediocre engineers glue things together in a haphazard way with little thought about what's the best way to write things. Caring about maintainability, comprehensibility and extensibility is partially a function of experience, but I've met plenty of experienced engineers who still write bad code and design systems poorly. It has no correlation to how much of a tinkerer and curious person they are, in my experience.

brightball 11y ago
Attention to detail will usually preclude someone from gluing things together like you describe though. Those are important details to account for and the type of person you're describing is more task focussed (aka - I got it done) than detail focussed (aka - I got it done right).
- Nav_Panel 11y ago
  I would say this dichotomy doesn't quite capture what's being discussed. To my mind, detail focused can still result in an ugly hack of a solution, merely with all corner cases covered. I think one possible phrase closer to the heart of things would be "aesthetically focused" as well as detail focused -- they care not only about the details of the functionality, but about the "technical beauty" of their solution.
muddyrivers 11y ago
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.
lamontcg 11y ago
At the same time you can overdesign something based on how it 'should' be engineered to the point where you haven't shipped anything and your company is bankrupt. You need someone that can pick a decent enough pattern which can get the job done in the time allotted. I would not hire someone that has a list of a hundred 'shoulds' which need to be met for any project to be shipped. That's a recipe for never shipping.
- deleted 11y ago
  [deleted]
infinite8s 11y ago
> I've met plenty of experienced engineers who still write bad code and design systems poorly. It has no correlation to how much of a tinkerer and curious person they are, in my experience. Can they really be considered experienced then? Or are they basically just people who are first year engineers repeated for 5, 10, 15, etc years.
FLUX-YOU 11y ago
>There are plenty of engineers who are attracted to the challenge and excitement of building new things, but have no appreciation for The Right Way to build things. It still takes a village to get to this point, which means even in the best case, we're all going to contribute some shitty code to the world because that's just the learning curve. You can, of course, go a long time without peer review or having ever been shown a better way to do the stuff you just did.
- fapjacks 11y ago
  This is a very poignant observation. Interesting.

brightball 11y ago

Attention to detail will usually preclude someone from gluing things together like you describe though. Those are important details to account for and the type of person you're describing is more task focussed (aka - I got it done) than detail focussed (aka - I got it done right).

Nav_Panel 11y ago
I would say this dichotomy doesn't quite capture what's being discussed. To my mind, detail focused can still result in an ugly hack of a solution, merely with all corner cases covered. I think one possible phrase closer to the heart of things would be "aesthetically focused" as well as detail focused -- they care not only about the details of the functionality, but about the "technical beauty" of their solution.

muddyrivers 11y ago

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.

lamontcg 11y ago

At the same time you can overdesign something based on how it 'should' be engineered to the point where you haven't shipped anything and your company is bankrupt. You need someone that can pick a decent enough pattern which can get the job done in the time allotted. I would not hire someone that has a list of a hundred 'shoulds' which need to be met for any project to be shipped. That's a recipe for never shipping.

deleted 11y ago
[deleted]

infinite8s 11y ago

> I've met plenty of experienced engineers who still write bad code and design systems poorly. It has no correlation to how much of a tinkerer and curious person they are, in my experience. Can they really be considered experienced then? Or are they basically just people who are first year engineers repeated for 5, 10, 15, etc years.

FLUX-YOU 11y ago

>There are plenty of engineers who are attracted to the challenge and excitement of building new things, but have no appreciation for The Right Way to build things. It still takes a village to get to this point, which means even in the best case, we're all going to contribute some shitty code to the world because that's just the learning curve. You can, of course, go a long time without peer review or having ever been shown a better way to do the stuff you just did.

fapjacks 11y ago
This is a very poignant observation. Interesting.