3 ms·

Okay. Now you're sitting with an interviewer to talk about your home asssigment. Turns out there were some changes in a system and you program needs to evolve a

Okay. Now you're sitting with an interviewer to talk about your home asssigment. Turns out there were some changes in a system and you program needs to evolve accordingly: actual format is protobuff struct and API is asynchronous — you send a bunch of tasks, server queues them up and gives you ids, after some time, results are pushed to a client as they come up. You must store data in SQLite and account for HTTP or REST errors (retry logic, etc.). Your one liner is neat and all, but now you have to do 2-3 hours of initial work + w/ever time it takes for adjustments in 2 hours scheduled for an interview. You could've thought out this toy architecture up front with initial simple implementations or at least discuss what they expect you to provide, but instead you wrote a shell script for some nefarious reason, even though you saw obvious disconnect between estimated time and time you actually spent.

deleted 10y ago
[deleted]
swalsh 10y ago
Nah, i'd hire the guy with the 1 liner over the guy with the robust architecture any day. A robust architecture is great and all, but I think it should be built after a need for it has been proven. When I was a junior developer, I was just trying to get code to work. When I learned design patterns, and had some bad experiences, then I started architect "robust" architectures for everything. After perhaps 6 or 7 years of doing this, I started to question my insanity. Sure there were several instances where I was like "Damn, really glad I built it like that" but there were an equal amount where it just ended up turning a simple problem into a complex problem. There's no good excuse for that. So now, I go high school simple first, and college hard later. If it means I have to do some rework, fine. I'm okay with a little rework, because in the end it aggregates to a simpler platform that took less time to build.
- _mg 10y ago
  Agreed, the thoughts of an experienced developer. Some related methodologies/acronyms: Lean development, MVP, KISS
hueving 10y ago
This is ridiculous. There are so many changes in requirements there (asynchronous with push results being the biggest), that everyone is going to have to throw away what they wrote an start over. Anything beyond 10-20 lines for the solution to this problem is pointless levels of abstraction and would be a huge red flag.
deleted 10y ago
[deleted]

deleted 10y ago

[deleted]

swalsh 10y ago

Nah, i'd hire the guy with the 1 liner over the guy with the robust architecture any day. A robust architecture is great and all, but I think it should be built after a need for it has been proven. When I was a junior developer, I was just trying to get code to work. When I learned design patterns, and had some bad experiences, then I started architect "robust" architectures for everything. After perhaps 6 or 7 years of doing this, I started to question my insanity. Sure there were several instances where I was like "Damn, really glad I built it like that" but there were an equal amount where it just ended up turning a simple problem into a complex problem. There's no good excuse for that. So now, I go high school simple first, and college hard later. If it means I have to do some rework, fine. I'm okay with a little rework, because in the end it aggregates to a simpler platform that took less time to build.

_mg 10y ago
Agreed, the thoughts of an experienced developer. Some related methodologies/acronyms: Lean development, MVP, KISS

hueving 10y ago

This is ridiculous. There are so many changes in requirements there (asynchronous with push results being the biggest), that everyone is going to have to throw away what they wrote an start over. Anything beyond 10-20 lines for the solution to this problem is pointless levels of abstraction and would be a huge red flag.

deleted 10y ago

[deleted]