Hired – Technical Interview Score
refdash.com
Hired – Technical Interview Score
1–10 of 123 posts
Re: Hired – Technical Interview Score
#2This seems to have a rather strong focus on speed.
Re: Hired – Technical Interview Score
#3I don't know what to make of this. Looks like a potential headache. As an engineer in an interview, we never get told what we're being scored on in advance (naming, speed, coming up with wonky edge-cases, scalability to 1million times workload, versatility, mentioning a bunch of relevant buzzwords (bloom filters!), confidence?).
This is one reason why most interviewing is a subjective clusterfuck (not just software, I suspect). I'd bet really good money that numerous companies would reject Linus, Carmack, etc.
Hence the giving of graphs and other media that are meant to project an idea of objectivity while reducing an engineer to a few quantities turns my stomach.
Re: Hired – Technical Interview Score
#4Clearly the person didn't run the code. The factorial function returns an int. The factorial of 13 is already too big for a 32-bit int. The factorial of 21 is bigger than a 64-bit int.
Re: Hired – Technical Interview Score
#5I don't know what to make of this. Looks like a potential headache. As an engineer in an interview, we never get told what we're being scored on in advance (naming, speed, coming up with wonky edge-cases, scalability to 1million times workload, versatility, mentioning a bunch of relevant buzzwords (bloom filters!), confidence?). This is one reason why most interviewing is a subjective clusterfuck (not just software,…
> giving of graphs and other media that are meant to project an idea of objectivity
Agile has the same issues.
Re: Hired – Technical Interview Score
#6I don't know what to make of this. Looks like a potential headache. As an engineer in an interview, we never get told what we're being scored on in advance (naming, speed, coming up with wonky edge-cases, scalability to 1million times workload, versatility, mentioning a bunch of relevant buzzwords (bloom filters!), confidence?). This is one reason why most interviewing is a subjective clusterfuck (not just software,…
100% agree with this. At any given company I've worked at, the recruiting/evaluation strategy has been different--largely because they _are_ looking for different things in candidates.
Some places value communication skills over technical skills. Others will value experience over credentials. I think it's unrealistic to expect that there is "one true way" to perform an evaluation (technical or otherwise). It all needs to be in the context of the team/department/organization you're hiring for.
Re: Hired – Technical Interview Score
#7I don't know what to make of this. Looks like a potential headache. As an engineer in an interview, we never get told what we're being scored on in advance (naming, speed, coming up with wonky edge-cases, scalability to 1million times workload, versatility, mentioning a bunch of relevant buzzwords (bloom filters!), confidence?). This is one reason why most interviewing is a subjective clusterfuck (not just software,…
> giving of graphs and other media that are meant to project an idea of objectivity Agile has the same issues.
Would you like to elaborate? What "agile graphs" fail and why?
Re: Hired – Technical Interview Score
#8This seems to have a rather strong focus on speed.
Algorithmic complexities in general, which in the day-to-day life of a developer are rarely considerations. I can probably count on one hand the number of times I ran into a problem that required the type of algorithm design needed in these interviews, yet they form the basis of hiring in many places. Crazy town.
Re: Hired – Technical Interview Score
#9Clearly the person didn't run the code. The factorial function returns an int. The factorial of 13 is already too big for a 32-bit int. The factorial of 21 is bigger than a 64-bit int.
I think the code people have to write in interviews is not supposed to work/scale in the real world. The purpose usually is to test whether the candidate can implement a correct algorithm. Even though this is Java (?), it's used more like pseudo code.
A follow up question could be: "Do you see some problems with running this with big numbers? How would you scale it?"
Re: Hired – Technical Interview Score
#10How well can you decouple?
That's all I need to know about you. If you can do this well, I (or you) can fix all your bugs quickly. I (or you) can fix (most of) your performance issues quickly. If you can decouple, you can isolate whatever other areas of ignorance you have with ease.
How well can you decouple? Is it instinctual for you to riddle off code architectures and solutions that are decoupled? It takes time + a value system to acquire this skillset (so that it's instinctual) but once you have it, you can move mountains with code.
The sad thing is our industry doesn't create the conditions for acquiring this skillset. (And rarely, like in this scoresheet, do you see it measured in interviews.)
The usual refrain is "I didn't decouple here or there because, um, it was faster to take on the technical debt."
No, you didn't decouple there nor there because you didn't spend several years falling on your face trying to decouple and failing. Because you were too busy getting paid to crank out whatever works in the shortest possible time, all the while saying "I didn't decouple here or there because it was faster to take on the technical debt." You didn't decouple there because you don't know how to decouple there.