6 ms·
I don't know what BFS is. I just googled it. Oh, I know what it is now. If you haven't been exposed to it, it's just jargon. That's the point. You are testing
by stegosaurus 10y ago
I don't know what BFS is.
I just googled it. Oh, I know what it is now.
If you haven't been exposed to it, it's just jargon. That's the point. You are testing for jargon rather than ability.
It is the distinction between saying 'implement FizzBuzz' and going silent, and actually explaining what it is. As an interviewer it is easy to forget that whilst you may have asked a question 20 times, this may be the candidate's first encounter with your terminology.
Steelmanning as applied to interviews, basically.
- jpatokal 10y agoNo, it's not a test of whether you know it, it's a test of whether you can implement it. If the candidate doesn't know/recall what BFS is, it's trivial to demonstrate the basic idea on a whiteboard, and it's the candidate's job to convert the idea into code. (Which, at the end of day, is pretty much what the vast majority of coding is about.)
- stegosaurus 10y agoI edited my post. Yes, this makes sense, if the interviewer describes what they're actually after. I have experienced (on both sides of the table) situations in which it just hasn't happened. 'Can you do X?' 'What is X?' 'Never mind, let's move on'.
- ams6110 10y agoIt's still not realistic. People don't code on whiteboards. You code (today) with all the resources of the internet at your fingertips, and if you need to invert a binary tree you will use a well-tested implementation from a standard library.
- catnaroek 10y agoI know for damn sure that, if I'm implementing something algorithmically tricky (not BFS, though), I first sketch the details on a whiteboard or a piece of paper.
- TheCoelacanth 10y agoIt's not supposed to realistic. It's supposed to be a test of programming ability that fits into an hour interview with time left over for talking about other things. Real world projects last months or years. You can't fit that into an hour, so you have to make do with something that can.
- LamaOfRuin 10y agoWhich is why they're not asking you to do it in an actual job. It's a proxy problem that is easy to communicate so you're not spending the entire interview explaining the problem. Arguably, fleshing out a spec would also be a valuable test, but not the same one.
- kuschku 10y agoPeople often do code on Whiteboards – but not actual code, but diagrams, plans, etc.
- catnaroek 10y agoSometimes actual code too. For instance, if I'm designing an optimization pass for a compiler, I'll write toy IR programs and show how the optimization pass will rewrite them. And I'll do it on a whiteboard.
- kuschku 10y agoYup. But the thing I meant is that you illustrate things, not actually code your application code.
- drakenot 10y agoMost specialized fields have jargon. It is the common language between the practitioners of that field. At what point should a person be expected to know some basic ideas and the words associated with them for the field they work in?
- stegosaurus 10y agoWell, if the knowledge of a particular thing is useful for that job, then yes, that's reasonable. But we know that most of the time this isn't true. <1% of software developers write sorting algorithms on the job, and even fewer of those actually need to know which one is Bubble and which Quick and which Heap without reference. If I'm a multinational company, I want my accountant to know what transfer pricing is. If I'm a self employed joiner, I don't. Problem solving tests are good. Memorization tests are terrible. We have search engines for that.
- drakenot 10y agoI think memorization tests of the sort that ask what FunctionX you should use from LibraryY for a particular situation are terrible. I don't consider asking a developer about basic data structures and their properties as terrible. This is foundational knowledge that is useful for nearly every programming job. Knowing about lists, hash tables, trees, etc and their operations or tradeoffs is extremely important. Similarly, having a developer that can reason about the runtime and memory complexity of the code they write is important as well. These are the "lingua franca" things that I was speaking about in my previous post. Even if particular developers think that the above things aren't useful to them, I would argue that they are probably wrong and just don't know how or why they are.
- stegosaurus 10y agoSure. I know what a list, a hash table, a tree are because I looked it up whenever I saw someone mention it, and eventually internalized it. But before that, I'd used them for 10-15 years without knowing the name because it doesn't matter. Take a hash table. Python calls it a dict. C++ calls it an (unordered) map. Java calls it.. whatever it calls it. It's nice to have that 'hash table' google term to find the thing you want in a new language, but otherwise they're just words. Actually in usage I type {} in Python and it is what it is. I'm not arguing that these things aren't useful at all. I'm arguing that the distinction between the CS-ified person that has spent the effort to learn what the words mean to pass interviews is not substantially more knowledgeable or useful than the version of that person that will have to find it out in the future. It's marginal. Basically it feels like a sort of 'table manners' test. You've put the fork on the wrong side of the plate, so you can't eat dinner with us today, you scoundrel. Don't take this to mean that I think that computer science is useless. Far, far from it. It is simply that I think that relying on jargon is testing whether someone genuinely has a CS degree (or equivalent without certification). It's not testing whether someone is a good programmer. If that's what you want, just ask for it. Let's not waste each other's time and money. The anger here exists because people want good faith interviewing, and instead they get "bloody hell the last 20 people were crap I can't be bothered any more" interviewing.
- dunkelheit 10y agoThat's not what happened to the OP. He was asked to code up a solution to maze searching problem. The statement of this problem is understandable by a 5-year old kid.
- LamaOfRuin 10y agoTo a degree this is true, but there is also significant value in having (and retaining) that broad base of knowledge that a good CS program or some systematic personal studies will get you. Most of the time you're not going to get a "implement this algorithm" you're going to get a "solve this problem we have" and you need to know the standard tools that are available to get you to a first approximation solution. Depending on what their listed requirements were, I think it's reasonable to expect you to know standard terminology, though I wouldn't count it against you if you asked to be reminded of the details for one or two things.
- robbiemitchell 10y agoWhy would an interviewer assume a front-end dev has a CS degree or has invested personal time in studying algorithms rather than other (probably more) relevant topics, such as various frameworks?
- LamaOfRuin 10y agoThat depends. Mostly because front end job listings still often list a CS degree as a requirement. Also, I think it's great when people enjoy working on the front end since I don't particularly, but I still want to work with people that aren't hyper specialized.
- robbiemitchell 10y agoI think you might be underestimating the breadth of front-end skills required to properly develop, test, deploy, deliver, monitor, analyze, and optimize front-end applications. Including the myriad third-party integrations that other teams need, from CS to marketing.
- LamaOfRuin 10y agoWell, I wouldn't have considered half of those things as part of "front end development" work, but it pretty much drives my point. I'm a firm believer in the idea that you'll be more effective at all of those things if you have a general baseline knowledge of CS, so that if you need to you can (relatively quickly) understand how and why all of your tools work the way they do.
- bad_user 10y agoTrees and graphs are fundamental to computer science and there are only two ways to traverse them. I don't know what kids are doing these days, but I learned this because of my high-school curricula. In other words, it's OK if you don't have a formal education in computer science, but when you don't have it, you need to make up for it by learning on your own, because this is basic stuff that high-school kids are learning. And it's even worse when people do have that education on their resume and don't know BFS, because it means they cheated on those courses. And what would you prefer for a hiring test? Straight IQ tests? A requirement for public, open-source contributions? Or are you speaking of querying databases and fading out divs? I think we can all agree that neither is entirely fair. And keep in mind that for all the pain involved in the interview process, the only alternative is optimistic hiring for a test period, except that doesn't work because it causes distress to everybody involved if it doesn't work out. This is why many companies now prefer internships, because thus they are dealing with young people that don't have big expectations.
- ts330 10y agoYou're right about learning. Everyone should be doing this ALL THE TIME. Problem solving and learning ability are what you should be measuring and then deciding if their past experience justifies the position/starting rate. This is far more likely to serve you well than testing the finer points of some algo/tech that is simply a building block of a solution to a far bigger set of business/technical challenges.
- bad_user 10y agoBut you cannot measure problem solving and learning ability without relying on a set of common knowledge to use in your tests. Again, are we speaking of giving out straight IQ tests? I think there's plenty of people that would be against that, plenty of people that consider IQ tests to be fundamentally flawed. And if not IQ tests, how do you measure problem solving and learning ability? Maybe you give the interviewee something to do, like an algorithm or a piece of code to develop on the spot, right? But maybe your personal expertise doesn't match with what the interviewer wants or needs. And the interviewer has to give you some problem to solve in some way. I remember that at a coding interview I was given the problem of programming a Lego Mindstorms device to detect obstacles and do stuff. But then the problem was really about reading a document on the C subset used to program the device, along with the several couple of functions needed to control the motion and read the sensors. Was that measuring learning ability in any way? Of course, if you think that the skill of reading a technical document with precise instructions is so rare. But that wasn't real world problem solving. So how can you test real world problem solving? Do you give candidates a homework? Ah, but then you run into another problem: the good candidates, the ones that might actually solve your homework, are rarely interested in spending their time on such things, because most good people already have jobs and a life and things to do and you can consider yourself lucky if you get their attention for a couple of hours. In that light, I don't think it's that unfair to give problems to solve that rely on basic algorithms and data structures, especially for companies where the problems solved are much harder than that.