|
|
|
|
|
by KronisLV
875 days ago
|
|
> Trying to hide it didn't even cross my mind - either they want to see how I work in a realistic environment with available tooling or they want to see what I can do in a "blind" setup. Honestly, the realistic style of work that's close to how one would actually approach problems in their day to day is pretty much ideal. In my case that would be using a nice IDE, some AI as a glorified autocomplete, IntelliSense and all that as well, in addition to Googling stuff along the way, if needed. That should be enough to let them know both how I think, as well as show how I can solve problems and reason about those solutions. Heck, maybe even give me a simple task to build a CRUD and then talk about the choices I've made, if they're serious about hiring me and want to actually see what's inside of my brain. But of course, in many places can't have that happen - they want to put the candidates in a situation where they just have a barebones text editor and expect them to produce good results. Blergh. |
|
So I pull out trusty old Ruby + RubyMine, and the question (I don't remember what it was specifically, but it was some sort of array manipulation type of thing) was trivially solvable with some Ruby STD lib method. Apparently he wasn't satisfied with the answer despite his prior instructions, and me not knowing what the actual method code is was reason enough to disqualify me from the job, which I found baffling.
I got into a bit of a heated discussion that, if I were solving a problem at work, there's a 99% chance I'd just reach for this method that Ruby itself comes with, because why the fuck would I try be a smartass and reinvent stuff here? And if for whatever insane reason I did indeed need a bespoke solution, I'd just poke around the source code and extrapolate from there, which he still didn't consider a good answer.
These interviewers drive me insane sometimes...