I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea).
This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.
Do you truly believe that being really good at CS will magically make you a skilled programmer?
Isn't the problem more often that lacking awareness of theoretical CS issues can limit your potential as a programmer? For example, someone with that awareness would immediately recognise some of the later questions as standard graph theory problems and could then solve them appropriately. Without that context, maybe a good programmer could still figure out a working solution from first principles, but it would surely take them longer. And while I don't suppose many of us will be working on intergalactic transport infrastructure any time soon, similar recognition scenarios do come up in plenty of day-to-day programming jobs.
There's a difference between expecting candidates to know when to recognize graph theory problems and expecting candidates to know (and implement) Dijkstra's algorithm as the correct solution to some abstract problem. I don't remember what Dijkstra's algorithm is exactly off the top of my head (all I remember is that it's for graph traversal and has a memorable name), but I do know when to recognize graph theory problems so I can start looking for the correct solution.
I definitely agree that general CS knowledge is highly beneficial (it's why I put in the time to learn), but knowing implementations for specific algos doesn't seem as important in the day-to-day as interviews make it out to be.
That is nice, however when hiring people it is useful to get somebody who can actually implement the solution too, rather than just sitting back smugly having identified a problem as "Dijkstra's".
If somebody can get as far as recognizing the problem as requiring Dijkstra's algorithm, they can go pull a book off the shelf, or use Google, and find the details of the implementation. Or, more likely, find a pre-existing implementation[1] that can be re-used.
Personally, I doubt that many people are walking around with the deep details of Dijkstra's memorized and readily available, unless they have a job that very specifically focuses on graph operations and they do nothing else day in and day out. So you could memorize it just for the interview, and then forget it again by the next day. But is there really any point to all that?
There are however people who can fairly easily write graph traversal and recursive code on a whiteboard. I wouldn't mind someone not knowing Dijkstra's well enough to code it from memory, but I'd be leery of someone who struggled with basic recursion, either writing the code or running through it and reasoning about it.
I wouldn't mind someone not knowing Dijkstra's well enough to code it from memory, but I'd be leery of someone who struggled with basic recursion, either writing the code or running through it and reasoning about it.
I agree with this--but I don't think the interviewer should be asking for an implementation of Dijkstra's in the first place. That's my whole point--it's not a real world problem to need to know an algorithm from memory. If I need a particular algo, I'll look it up and find a supported open source library that implements it 10x better than I could have.
My point is that you can gauge somebody's knowledge without making good software developers feel inferior e.g. by asking them how they would go about finding a person's likely connections given some weighted data for an imaginary social network. And then you can maybe get responses like, "That's a good question--I've dealt with that before when I was working on X, Y, Z and ended up using weighted graphs according to how many friends a person had in common …" or "I'm not entirely sure on the exact algorithm I'd recommend, but that sounds like we would set up a weighted graph and go from there …".
Rather than making talented people feel stupid, you encourage conversation. But what do I know, I don't interview people every day so take what I say with that in mind. I just think tech interviewing is broken. I'm always left frustrated and my excitement to join the team dies down due to thinking I won't fit in because I'm not "smart" enough.
I mean, you're speaking as if you had the magic cure-all to technical interviewing, and if you did I'm sure you'd be telling us what it is instead of somewhat condescendingly criticizing someone else's methodology.
> I will concede that being good at CS will give programmers an advantage in solving problems in a subset of domains.
> I suspect I could add the word small to advantage and subset and that statement would still be true.
I doubt that's even close to true. You need CS knowledge to optimize programs and to design reliable services. It would only be true if you squint really hard and cherry pick some domains where CS knowledge isn't valuable and cherry pick what counts as 'academic CS knowledge'.
I would have edited my previous reply, but it was too late.
> Are they not different skill sets? One is a practical skill, the other an academic one.
I'd like to see you design and program a P2P networked program without any CS knowledge, like Kazaa or Bit Torrent, that actually works as well as they do.
> I've met "programmers" who had depth of theoretical knowledge but couldn't code their way out of a paper bag.
That's true for lots of fields, but it's not hard to see that that doesn't mean theoretical knowledge isn't useful.
It's a lot, lot easier to read papers on the algorithms needed by, and understand the specific requirements of, a particular project than it is to learn the entirety of software development outside algorithms ad hoc.
Honestly, even though I do know a fair bit about the Bit Torrent algorithms, I wouldn't trust that knowledge since it's most likely out of date or incomplete. It's deserving of research for anyone, even people who 'know it already'.
That's why I don't understand these narrow algorithmic tests - very, very seldom is a priori knowledge about DFS vs BFS going to be something that makes or breaks a project.
It would be akin to testing civil engineers on the memorization of precise ratios of the ingredients of concrete in current usage, instead of on the broad applicability of particular materials to particular purposes.
For a working peer-to-peer network, who would you bet on to get a working solution first:
1. a programmer without any formal CS training
2. a CS graduate without any practical programming experience
Most programmers without CS degrees would pick up the concepts needed in a few days, most CS students would take months to even be able to finish a basic program. And it would fall over as soon as you sneezed at it.
While there will be exceptions on either side, run that race a thousand times, and the programmers would win the majority of times.
This is why I said you'd have to squint really hard to find something like this. You're clearly moving the goalposts here. I didn't ask about just a working solution, which could be almost anything. Even just something as hacky as everyone running an ftp server might fit such an extremely vague criterion.
But to run with your new scenario, professional programmers could come up with just a working solution quickly. However, lots of CS students could do the same. Pretending like no CS students can program reasonably well is disingenuous.
> most CS students would take months to even be able to finish a basic program
I don't have statistics on that, but I suspect most seniors and juniors could get something working in far less than a month. You're just trying to paint them in a worse light here. It's not like CS students don't have larger projects they complete in relatively short time frames.
> And it would fall over as soon as you sneezed at it.
I bet the that would be even more so for programmers with no CS experience. The reason I mention P2P programs is that they require CS fundamentals to function reasonably well. And CS students would be far better equipped to look up and understand and implement those things. Your average programmer who thinks CS is unnecessary is likely to write something that indeed 'falls over as soon as you sneeze at it' here because under a real load, it will not perform well.
> While there will be exceptions on either side, run that race a thousand times, and the programmers would win the majority of times.
For writing yet another Rails website or somesuch, maybe. For an example like mine, that requires in-depth CS knowledge, not a chance! I think the reason you are so confused is that you assume CS students can't be 'programmers' and/or you're mentally pitting experienced devs against new CS students. I doubt a new programmer that didn't have CS knowledge would do well at any of this!
I doubt most CS grads could do this. One hard part of it is the p2p (but that's already been solved [0]). Having a project that large where you don't eventually shoot yourself in the foot because of architecture and finish in a reasonable time without using too many resources on a user's computer is also a hard part.
>I suspect I could add the word small to advantage and subset and that statement would still be true.
Sounds like you're only familiar with programming to solve easy problems. Lots (most) of us do it, and that's fine, but there are a large number who tackle the more complex domains and need both skills.
I'm disagreeing that I don't believe it is a 'small' number of domains, only that they are domains you're not familiar with (or aware of.) Other than that though, yes, we agree.
I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea).
This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.