5 ms·

As someone whose taken and authored many: the whole point is often to have different levels of completion. There may technically be a "complete" point - often t

As someone whose taken and authored many: the whole point is often to have different levels of completion. There may technically be a "complete" point - often that isn't that hard to achieve. Usually there are several other possibly-non-obvious improvements the tester is looking for. Whether these improvements are obvious to you or not is a sign of experience.

opportune 3y ago
If I'm not given that guidance directly nor given a chance to clarify it as I do the solution (as with normal interviews), I don't really want to participate in the guessing game about what they want, if missing that guess results in all the work being wasted. As others have mentioned, I find the "limit yourself to 2-4 hours" BS. I can stand up a new http server in 2 hours to implement some API, sure. Adding unit tests, integration tests, a readme, build instructions/scripts, containerizing it, adding detailed comments, linting... generally not possible to do in 4 hours unless you have everything set up before then (I can't use my normal dev tools to do takehomes because they're through my employer). IRL you would generally scope this as a week-long task even for experienced employees. Maybe if I were unemployed and desperate for a job I'd suffer it, but most places I'm interested in working at ask whiteboard/design problems anyway.
- boredtofears 3y ago
  If it feels like a guessing game it's probably not obvious to you what the improvement is. They usually stick out like a sore thumb for the candidates that they're seeking if they're written well.
  - deredede 3y ago
    "If they're written well" is key here. Anyways, just show me the code and we'll discuss it together, don't waste my time making improvement to toy code that will never get used.
Tade0 3y ago
> Whether these improvements are obvious to you or not is a sign of experience. In my experience as an interviewer fishing for specific answers is what makes you miss the best engineers. I used to do this during my peak Dunning-Kruger phase and gave relatively poor marks to an guy who later proved to surpass both me and the rest of the team in every aspect that mattered - even though originally he barely made it through the interview process. Chiefly, he didn't do things the way we expected because he prioritized.
- deleted 3y ago
  [deleted]
- boredtofears 3y ago
  I definitely wouldn't fish for answers. The point is that they are obvious to an engineer with a certain skillset. Doesn't have anything to do with prioritization.
  - Tade0 3y ago
    > The point is that they are obvious to an engineer with a certain skillset. Are they always worth fixing, regardless how many there are? Also, you had plenty of time to prepare these and think this through. Someone seeing this for the first time may assume Chesterton's Fence and not change anything despite noticing - assuming it's less important than breaking whatever reason there might have been for doing things this way. What I'm getting at is that you're not necessarily getting the best engineers, just ones who think like the current you. It's a mistake and it's likely already costing you.
    - boredtofears 3y ago
      Not really, the improvements don’t break the solution in any way. There’s no “Chestersons Fence”. They’re much simpler than you seem to be assuming.
      - Tade0 3y ago
59nadir 3y ago
> Usually there are several other possibly-non-obvious improvements the tester is looking for. Whether these improvements are obvious to you or not is a sign of experience. There is a risk here for something that even really strong intermediate programmers fall into where they take a very prescriptive approach to programming so they tend to not understand things built from first principles and also tend to overvalue things like future-proofing and abstraction. Since you don't mention any specifics it's easy for people to fill in the blanks here and assume that at least a good portion of the things you refer to are those kinds of things.

opportune 3y ago

If I'm not given that guidance directly nor given a chance to clarify it as I do the solution (as with normal interviews), I don't really want to participate in the guessing game about what they want, if missing that guess results in all the work being wasted. As others have mentioned, I find the "limit yourself to 2-4 hours" BS. I can stand up a new http server in 2 hours to implement some API, sure. Adding unit tests, integration tests, a readme, build instructions/scripts, containerizing it, adding detailed comments, linting... generally not possible to do in 4 hours unless you have everything set up before then (I can't use my normal dev tools to do takehomes because they're through my employer). IRL you would generally scope this as a week-long task even for experienced employees. Maybe if I were unemployed and desperate for a job I'd suffer it, but most places I'm interested in working at ask whiteboard/design problems anyway.

boredtofears 3y ago
If it feels like a guessing game it's probably not obvious to you what the improvement is. They usually stick out like a sore thumb for the candidates that they're seeking if they're written well.
- deredede 3y ago
  "If they're written well" is key here. Anyways, just show me the code and we'll discuss it together, don't waste my time making improvement to toy code that will never get used.

Tade0 3y ago

> Whether these improvements are obvious to you or not is a sign of experience. In my experience as an interviewer fishing for specific answers is what makes you miss the best engineers. I used to do this during my peak Dunning-Kruger phase and gave relatively poor marks to an guy who later proved to surpass both me and the rest of the team in every aspect that mattered - even though originally he barely made it through the interview process. Chiefly, he didn't do things the way we expected because he prioritized.

deleted 3y ago
[deleted]
boredtofears 3y ago
I definitely wouldn't fish for answers. The point is that they are obvious to an engineer with a certain skillset. Doesn't have anything to do with prioritization.
- Tade0 3y ago
  > The point is that they are obvious to an engineer with a certain skillset. Are they always worth fixing, regardless how many there are? Also, you had plenty of time to prepare these and think this through. Someone seeing this for the first time may assume Chesterton's Fence and not change anything despite noticing - assuming it's less important than breaking whatever reason there might have been for doing things this way. What I'm getting at is that you're not necessarily getting the best engineers, just ones who think like the current you. It's a mistake and it's likely already costing you.
  - boredtofears 3y ago
    Not really, the improvements don’t break the solution in any way. There’s no “Chestersons Fence”. They’re much simpler than you seem to be assuming.
    - Tade0 3y ago

59nadir 3y ago

> Usually there are several other possibly-non-obvious improvements the tester is looking for. Whether these improvements are obvious to you or not is a sign of experience. There is a risk here for something that even really strong intermediate programmers fall into where they take a very prescriptive approach to programming so they tend to not understand things built from first principles and also tend to overvalue things like future-proofing and abstraction. Since you don't mention any specifics it's easy for people to fill in the blanks here and assume that at least a good portion of the things you refer to are those kinds of things.