4 ms·
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
by GreenJelloShot 7y ago
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.
- 70jS8h5L 7y agoExactly 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.
- iliketosleep 7y ago> 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.