The last two times I went through an interview cycle (one on each side) it struck me how dependent your success was on your chosen tools and whether the coding question dovetailed with those choices or not.
For instance if I'm working on a hard problem I usually need tests (whether I initially admit that to myself or not), and despite the fact that I'm often the one who sets up and/or defines our testing strategies, every time I set things up is an adventure, because I set it up once and run that way for years. I have zero muscle memory for the installation process and anyway the decisions might be a little different in 3 years. And more to the point, I want people to copy what I've done, so I do the same thing (which gets me an experience of what others are having to put up with/enjoying about my solution).
For the app server the situation isn't much better.
In an interview taking the time to set any of that up would be crippling, even though I'd come out even on a 2-3 day story and ahead on anything longer.
I have thought many times about setting up a blank application with testing, logging, and production-reasonable overrides for all the defaults for the app server, etc. Just so I have an easy starting point for quick prototyping, which is essentially what an interview often is.
Generators probably work for an interview, but for real projects, re-applying the generator with each release is kind of a bear. I propose that it would be much easier (possibly trivial) to do on an empty shell project and then merge downstream.
I kind of think one of the things we are missing about DVCS is that the ability to maintain permanent forks gives us other options for arranging cross-cutting concerns. Maybe one more generation of merge tooling is necessary for that to be A Thing.
Most interviews seem to weigh heavily in favor of "sprinters" over "marathoners". That is, they select for people who can go from nothing to working code in a short period of time.
I am one of those people who takes a while to get rolling, especially when starting from scratch. Interviews generally give you 30 minutes or an hour to produce something. I will easily take an hour to think about the problem, do some research, and then create some notes before writing any code.
This is, of course, not what most companies want. Unless you are asking me to do something trivial or something that I have claimed to do many times in the past, you can't expect me to come up with the "right" answer instantaneously.
I never jump right into editing code, unless I am already intimately familiar with it.
> Most interviews seem to weigh heavily in favor of "sprinters" over "marathoners". That is, they select for people who can go from nothing to working code in a short period of time.
This is a great way of putting it. As a "marathoner", I think the only way to pass these things is to condition yourself for the sprint. Which means being familiar with the types of questions that might be asked and practicing coding solutions until you can code them off the top of your head (and even on a whiteboard if necessary!!) The investment of required to achieve this is ridiculous, and there's no guarantee you'll be asked a familiar question.
It's absurd because in some software engineering jobs, a marathoner might be preferable to a sprinter but they'll most likely hire the sprinter.
Hiring remains an unsolved problem. The company who can truly solve the hiring problem will be a unicorn.
Exactly my feeling. I've been pondering a couple of recent negative interview experiences and felt this was my main issue. For any normal issue/work/feature/whatever, I'll have a few hours/days to ponder it and think of possible approaches and any issues that I might encounter down the line.
When put on the spot with a time crisis I tend to go too deep down a rabbit hole before realising the shortcoming of the approach I chose to take.
This leads to me usually doing great in take homes, compared to these recent in-person assessments. Also, confounded by having to work on an unfamiliar machine without any of my usual tooling which I'm not a fan of, especially as a keen fan of having a decent debugger set up.
For instance if I'm working on a hard problem I usually need tests (whether I initially admit that to myself or not), and despite the fact that I'm often the one who sets up and/or defines our testing strategies, every time I set things up is an adventure, because I set it up once and run that way for years. I have zero muscle memory for the installation process and anyway the decisions might be a little different in 3 years. And more to the point, I want people to copy what I've done, so I do the same thing (which gets me an experience of what others are having to put up with/enjoying about my solution).
For the app server the situation isn't much better.
In an interview taking the time to set any of that up would be crippling, even though I'd come out even on a 2-3 day story and ahead on anything longer.
I have thought many times about setting up a blank application with testing, logging, and production-reasonable overrides for all the defaults for the app server, etc. Just so I have an easy starting point for quick prototyping, which is essentially what an interview often is.
Generators probably work for an interview, but for real projects, re-applying the generator with each release is kind of a bear. I propose that it would be much easier (possibly trivial) to do on an empty shell project and then merge downstream.
I kind of think one of the things we are missing about DVCS is that the ability to maintain permanent forks gives us other options for arranging cross-cutting concerns. Maybe one more generation of merge tooling is necessary for that to be A Thing.