Hacker News Reader

There are things from a formal CS background I wish more people mastered. Things like understanding how JOINs work, basics of memory management and understanding that two nested for loops is likely to be worse than a single one, even in the cloud. But knowing how to implement a specific sort isn't one of these. It's simply never come up outside of an exam.

I think that's kind of the point. If radical is looking for (3), they will probably know the information because it is interesting.

I'm shocked that a proper CS course wouldn't teach them. We covered Joins (and the relational maths behind them) in first year, and "nested for loops being bad" would be a necessary by-product of learning anything about complexity.

Oh, I don't mean to say these aren't taught (though being taught something and mastering it isn't quite the same).

What I mean is that those are the parts of a CS background that have actually been useful in my everyday coding life, and that I would expect from candidates I interview. To be opposed to knowledge/implementation of different types of sorts, which is also a part of a CS background, but has low practical use in my everyday coding.

mm, I agree with you there. I guess it's because sorts come up so much in a CS curriculum that they're considered to be magnificently important. In other words, they're just really handy bodies for imparting central ideas (like complexity), and people mix up the messenger with the message.

> the parts of a CS background that have actually been useful in my everyday coding life

Someone fresh out of school would have no idea how to discern that from anything else in the wide, wide world of CS unless they have experience working in the industry (from, say, a summer internship or co-op terms).

Hell, mastery of basic DVCS operations (say, git pull, git commit, git merge, although equivalent experience with hg, perforce, or TFS would be reasonable) isn't a guarantee, even if students spent four months in a lab "using" such a tool.

The people who "do best" in university get told by their professors to become graduate students. Most are not optimized to teach the skills you seek -- if you picked a random fresh graduate and they happened to have those skills, it's probable that either they taught themselves or they learned them at another employer.

I love coding, but if you make me implement a quicksort in the interview I'll probably be too nervous and fuck it up. Have you tried having more interactive interviews, or handing out projects?

I just like doing cool things, honestly. And I know a few people that are just like me.

We tailor the interview to the applicant: so someone coming from (GOOD!) Uni should be able to verbally explain a sorting algorithm. We don't ask them to code - it will take too long and a discussion is much more valuable (and almost impossible to pass by memorizing a couple of algorithms).

Heck, I passed a harder version of the test (including the theory, I'm a senior/lead/old-fart so I was expected to implement everything on top of the discussions) and I left formal education at 17 :)

They don't have to implement a working version, just give a good outline and be able to answer questions about it :)

For experienced people we go further, and do ask for some coding.

You've got 5 years experience in SQL? Then solve this simple problem which requires using JOINs and aggregates.

You're a javascript expert? Great, then demonstrate that you know the syntax and know what a closure is.

Java expert with a focus on patterns? Then you should be able to implement one of: Singleton/Factory/Command.

We get more people who have 10 years of experience with C# are are self proclaimed experts, but who don't know the difference between the heap and the stack then we do CS students applying for the wrong job.. but that's for a different thread :)

Ah, that seems pretty reasonable. I think my biggest problem is that when I'm interviewing I'll try to answer too quickly before thinking through a problem completely.

But I love discussions too, and if it's something I'm comfortable with, I could keep talking about the topic for as long as the interviewer wants.

I think there's value in recognizing when you don't know the answer to something. I had an interviewer ask me the difference between call and apply in JavaScript, at the time I wasn't sure, so I started to answer him... I explain that I knew you could use both to set the context in which the function was called, but eventually I just said: I'm not sure. And the interviewer gladly explained it to me.

In my case I got an internship where they gave me a 24 hour project to demonstrate my skills. I found that way less stressful than any interview I've ever had. And after the internship the company was so happy that they offered me a full time job!

Oh, that's exactly what I want to hear: everyone has gaps in their knowledge and it takes guts to admit it. As long as you can see that, and know where to gain the knowledge, than that won't be a problem.

Unless that knowledge is something vital and general. I.e. like not knowing what HTML is.

In the future I want to use internships to find younger engineers - it lets you get to know people a bit, and keeps new ideas flowing through the company.

Here's my problem with using quicksort at interview:

A developer who writes an implementation of the quicksort algorithm as part of their job should usually be removed from their post for incompetence.

The interview process should be a two-way procedure which also allows the candidate to understand what is expected of them in a role (and make their decision about the job accordingly). If regurgitating quicksort is expected, then this is a fair test: otherwise, this is not how you should be presenting the job.

How can you mess up quicksort? Pick a pivot, lower values on one side, higher values on the other. And recursively rinse and repeat.

I get really nervous and I make stupid mistakes. Every single time I've had an interview and I'm asked to code I end up making stupid mistakes because I try to answer too quickly or because I don't sit down to properly think about the problem. It's definitely something I need to work on.

Thankfully I got an internship that let me do a small project to demo my skills, instead of hazing me. And after my internship they were so happy that they offered me a full time job.

I once messed up a string size parser in an interview by going len instead of len - 1 in measuring the number of characters displayed.

It is stress. Introverts like myself I imagine collectively are horrible under intense pressure from random strangers who can dictate your future for months or years.

Quicksort is amazingly easy to screw up. There's a lot of opportunity for off-by-one errors in all the index manipulation. I coded quicksort as an interview practice exercise in plain C a few years ago and it took quite a number of iterations until getting it all correct.

Maybe the real lazy person is you and the way you interview. What does writing mergesort on a whiteboard have to do with writing Web software in 2013?

Nothing, but I think the implication is that it is a signal that can be used to predict which of the three categories the person falls into. People who fall into the third category (the desirable one) are likely to be able to implement mergesort on a whiteboard because they have a genuine interest and paid attention.

That being said, other, more practical questions may exist that retain the signaling characteristic.

With respect, I'd like to add a fourth category:

4) Actual computer scientist. If you ask him how to write mergesort, he will ask for a book to look it up in, same as if Einstein was asked for the value of pi. If you ask him to describe his favorite algorithm or the details of his current research, he will gladly tell you in extensive detail.

The problem with hiring those of us in category (4) is that it's hard to tell if we're bullshitting you, since after all we operate at a far more advanced and specialized level of expertise than most software development jobs actually use or require.

Sorting algorithms in general aren't constants, though. The implementation can have significant impact on running time, memory use, etc. And there are an infinite number of them with various tradeoffs you can tune.

I wouldn't expect an interviewee to know sorting algorithm X because they may just have forgotten. But why wouldn't they be able to come up with a sorting algorithm, and have some feel for the behavior? Seriously, selection sort is about as easy to come up with as fizzbuzz. If they can't think through a simple problem and come up with a solution, is it wrong to question their problem-solving skills?

Actually, if you asked in an interview how to sort, I'd try to come up with quicksort or mergesort. I wouldn't give you insertion sort or selection sort because I'd feel terminally embarrassed to go with so bad an answer.

Is it terminally embarrassing to say "this is bad, but..." and pass the test, then discuss (maybe write out) more advanced options? If all they care about is selection sort, you've saved time (often a good quality). If they care about more, you've demonstrated something, and opened the door for more.

Depends. I've been in interviews where they let me damn well know I was losing points for giving an algorithmically sub-optimal answer.

Sounds like (a) fun interview(s) :/ Alas, they exist. I guess it's too much to hope they don't.

Where did he say he was writing web software?

The author of the parent post probably assumed it from radicalbyte's "about" section.

Doing what you love, without getting paid a lot for it, is for social workers and teachers and other people whose jobs don't make someone else a ton of money.

Social workers can build parks or public housing or feed people, where in each case there is increased traffic through an area creating a boon in income for local business, there are public utiltiies companies that profit off more people in homes, and there are farmers and food distributors who have increased demand from food kitchens, even if the margins are sour.

Likewise, teachers lead to the student often becoming more productive and wealthy by knowledge transfer.

There is value in almost anything you do. We just have a social organization where some things are overvalued and others are undervalued.

Tuition from schools that don't really teach?