4 ms·
I call bullshit on this train of thought. I've been reading about this on HN and reddit for years now. This last December, I was promoted high enough, that I
by ep103 10y ago
I call bullshit on this train of thought.
I've been reading about this on HN and reddit for years now. This last December, I was promoted high enough, that I could design the entire interview process (with executive help) for my teams. Which was important, I very much need to hire some people.
So, keeping posts like this in mind, I designed as follows:
Phone Interview - We talk about you, the company, etc. Then a few technical questions. Do you know certain things about js that make me think you are genuinely familiar with the language (as opposed to just jQuery)? Do you know certain things about sql that make me think you are genuinely familiar with the technology (as opposed to just using a table designer)?
Assessment Test - Do a quick crud app, that will require some thought behind how to query the data. Make a point when talking to the prospective applicant that the code will be read by the team members they'll be working with, so while you can do the test quickly, please spend enough time on it that we can talk about the code, your choices, etc going into the technical interview. Ie) don't just link together 3rd party plugins.
Actual Interview - Interview with leads, interview with actual team members. Offer both use of Visual Studio / SSMS / IDE of choice or whiteboard. Ask questions about technology in general. Ask the applicant to explain how he'd design out a new feature. Change the feature spec, so that there's a little bit of a hard problem. Have to populate a tree from flat sql data, or aggregate data from a service, or some other not-quite-an-algorithm question.
The RESULTS?
Recruiters figure out what questions you are most likely to ask during the phone interview, and school the candidates.
The assessment test? No one bothers, everyone just hands in the simplest 3rd party libraries plumbed together with shitty code. Was the question select top per group? How about top 1 *? The really good devs shine through here, but a huge percentage don't even bother.
Actual Interview? No one uses IDE / SSMS. All of them choose whiteboard. The ones who genuinely know how to code, have no problem answering, and would be fine answering algorithm questions straight out. The ones who can't, get confused somewhere or other. They try to implement hacks around the problem (I'd have the dba do it), then fail to actually solve the question.
So In Short? I completely understand where this guy is coming from. But I also think, that at this point, I'm so tired of interviewing people who clearly don't care about their craft, that I want to start asking nothing other than algorithm questions... because the guy or gal that actually answers them will actually care about their craft. And at least with algo questions, I can change the question easily, and frequently. Coming up with real code problems, and good probing questions is much harder, particularly if they're going to have a short shelf-life before recruiters start training their candidates with answers.
- eternalban 10y agoAlgorithm questions come in two flavors: sensible: given the problem statement discuss your initial choice of algorithms and datastructures. This probably covers 80% of tech jobs out there. And you easily dig deeper with big-O and related here. You should have a very good idea if the candidate is clueless or not after this. other: given a datastructure and algorithm, implement it. This makes sense for a minority subset of jobs/devs.
- dpark 10y ago> given a datastructure and algorithm, implement it This can be entirely appropriate for most jobs/devs, depending on the datastructure/algorithm. One of the guys I work with sometimes asks people to implement mergesort. I was suspicious of this question at first but it's been quite good at weeding out mediocre candidates. Mediocre candidates will write broken code all over the board, and more telling, they won't understand why it's broken even when you point it out. Good candidates will generally make mistakes (because no one has mergesort code memorized and coding on a whiteboard is frankly tough), but they'll recognize them, typically on their own and always with pointers, and they'll be able to explain the issue and how to fix it once they see it. There's no trick to this question. There's no riddle, no "gotcha", and it's not a hard algorithm to understand or code. Just show that you can write minimally complex code and walk through it. It's like fizzbuzz but you can't memorize it.
- watwut 10y agoUnless your assessment was more specific, I would not know what it is that you are looking for, picked up some libs, plumbed them together and got ready to defend my choice. I would not be willing to spend more then couple of hours for it, since I wont be able to use it anywhere else (unlike general knowledge like ago or sql). The rest is understandable. Whiteboard, cause you want design and it will be faster to point, talk, erase and change. Unless you do some deep tech, people who can do general algorithms will be able to adapt fairly quickly.
- dpark 10y agoI fully agree with you on this. If you ask someone to build a trivial CRUD app as part of their interview process, you should probably expect them to hack something together to get the job done. In fact, you should expect that on the job. If you don't have complex needs or high scalability requirements, gluing a bunch of plugins together seems like the appropriate approach. Who wants to hire an architecture astronaut who hears "design a new ORM system" when someone says "build an app to update customer addresses"?