Comment by kamaal | Hacker News Reader

Comment by kamaal | Hacker News Reader

This is something to think about.

The interview process is so badly gamed that these days its kind of a ceremony. In a recent interview, I gave a candidate a practical problem. He was allowed to use the sed man page, and then I gave him a file and search/replace problem. Nothing much! The candidate fails! Instead he asks me if there is going to be a algorithm/data structure interview. I told him, I don't know but as far as I was concerned I was only going to test him on practical everyday problems.

It was almost like I had committed a sin. He was like, every company has those standard one's so why was I doing like a practical test. These days all candidates do is go through most common puzzles/algorithms/data structure stuff. Its actually quite easy to get access to those. Just spend some time on interview forums and you can practically game any interview, in any company any where around the world today.

My approach is straight simple. Throw a manual/documentation at the person. Give him a problem common enough to test a practical everyday situation. Check if he can pass the the test of reading the documentation and figuring out the solution to the problem. Or give him/her their favorite IDE/text editor + documentation + problem and let them solve it.

If they can do it, or even get the approach right they pass the test.

Else if all they are going to do is vomit some mathematical theory from college text books, which isn't even remotely relevant to our everyday work- I'm hardly interested in hiring such candidates.

May I ask where you work? I'd love to interview at a company like yours.

I'm in the process of changing careers to programming in my late 30s. I dabbled in coding on and off for most of my life, but two years ago I started taking it seriously, read K&R, etc, and completely fell in love with programming. And so I start thinking about working full-time as a developer, and schedule an interview for a programming position for a company in the industry where I've worked for the past decade. I've always been a confident interviewer, but I totally froze in this phone interview. They started the interview off with a tough algorithm problem that I probably could have solved on my own in 30-40 minutes, but couldn't possibly solve on the spot in a conference call, with several people listening in and quizzing me. From there, things went downhill quickly, and I struggled to answer questions that I could have easily answered on my own at my desk. Since then, I've been burned on two freelance programming assignments (that I should have known better than to take given the level of desperation involved), which was quite a blow after spending a decade freelancing for dozens of clients without incident in another industry.

I love programming, and so I continue to code whenever I get the chance (and have two rather large projects underway), but these experiences have shaken my confidence. If most programming jobs involve similar interview processes, I'm not sure this would be the best move for me.

However, this comment has given me hope. If there are companies out there like this, then I stand a fighting chance -- I would excel at an interview where I'm given a problem, a time limit, vim, and then told to go solve it with no whiteboard or group of people watching. Let it be a hard problem, but make it realistic -- not some obscure puzzle or algorithm -- and let me use my own tools. I wish there were some job board where companies with this type of interview process posted jobs.

Seconded.

I'll even spend the extra time on it if we can do something similar to "Here is the problem and the docs. Email me back within the hour with some working code and we'll get on a call to talk through your thought process".

It's like trying to run a competitive 100m without shoes at some interviews I've been through lately.

I do something like that. My first test is ask to reverse a string (not using the reverse function!) in any language and/or pseudocode. Is incredible how badly the test goes with the people! I interview for myself or others more than 100 people (of any background, including university, tech schols...) and I think only 10/12 people do it correctly - barely-

To make it more fair, I always let them alone. And give internet and a computer, and remember them they can use internet and search. Not even with that amount of help the thing work well (I truly have find someone smart enough to copy-paste something and return to me in 1 minute or less).

Then i do the puzzle question, but know I retire it some years ago and some more question about real stuff...

This is great. My first thought was "perfect, Haskell!"

reverse "whatever"

"No reverse function? but we can use the internet? The Prelude source probably has the best implementation of a reverse."

foldl (flip (:)) [] "whatever"

Reversing a string is actually an incredibly common interview question. It's a bit like FizzBuzz (IME even more common, but I can't really speak about the world at large).

It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se.

You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could code this up, but whether he can code it up quickly, under time constraints, while being stared at, under pressure, with rent or a mortgage on the line, and maybe kids to feed.

I am hard pressed to think of even one real life dev task I had in my entire career where I had to solve a problem under those circumstances. For most devs, we take ownership of the problem and solve it at our desk under reasonable time frames without the spotlight. For bigger problems, we might think about it in the car on the way home. We might sleep on it over the weekend.

That doesn't apply to reversing a string, of course. But you have to consider that, depending on the dev's background and skills, he may be spending time in jQuery, maybe Spring and Hibernate (for Java guys), maybe even some CSS. Maybe he's a GWT guy? Maybe he was assigned to a team dedicated to (God forbid) EJBs. In other words, he may be multifaceted and spends more time working with an API than "just" raw language coding. The language is just a means for working with the API.

And the one thing you want to measure is not something he does daily. Now, if he can't use a for loop, feel free to mock him. But reversing a string? That's clearly a puzzle.

EDIT: I can't get this part out of my mind: "Is incredible how badly the test goes with the people! I interview for myself or others more than 100 people (of any background, including university, tech schols...) and I think only 10/12 people do it correctly - barely-"

So you continue to use that question? Despite the results? So that when you do hire a guy that passes, he won't ever do this on the job because you know you damn well he should use the reverse() method? Because you won't pay him to code it raw and waste time and money when there is a 1.5 second solution to this? That's sadistic. :-)

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge:

1) That a string is implemented as an array of characters.

2) How to reverse an array.

The implementation is straightforward and should be trivial for just about anyone who's done much development.

I don't know that the question is that great, but it certainly isn't bad as a fizzbuzz-type question to use as a filter.

Fair enough.

Here's my solution:

def reverse() {

    def a = "Can a fella get a job?"
    StringBuilder b = new StringBuilder()

    for (int i = a.length(); i > 0; i--) {
        b.append(a.charAt(i-1))
    }
    print b.toString()

}

But it doesn't use arrays because quite frankly, I haven't used an array in years. I despise the noise of the brackets. :-)

Seriously, I use ArrayLists instead of arrays. But even on this FizzBuzz lite exercise, I got tripped up. My "i > 0" was off by one. And I started down the path of a.substring, but that was a bad move. I quickly switched to charAt.

But about the only relevant piece of this: on an IDE, I was able to place a breakpoint, see where I'm at, what my variables look like, and make adjustments.

That's real life. My original cut of this would have disqualified me. Actually, even the cut above would disqualify me since I didn't use arrays.

But I need to confess. What you see above is literally the first time I've ever reversed a string in this manner. It's just not something I do. And it didn't roll off the tongue so to speak. I knew I had to process the string from the end and work backwards, but it still felt like trivia and not a substantive inquisition into my skills or experience.

Trivial? A bit. It took me about 5 min. The off by one was killing me. It hits you in two places: the i > 0 and the charAt(i-1).

That isn't a bad solution. You obviously hope that someone you're interviewing can come up with something like that fairly quickly, but I certainly wouldn't disqualify you based on your method of solving it or an initial off-by-one error.

> What you see above is literally the first time I've ever reversed a string in this manner. It's just not something I do.

There is a certain amount of value in that - seeing how someone reacts to and solves something they've never seen before. Can you come up with a reasonable plan for attacking the problem, implement it, test it to see if it works in a bunch of cases, and make the necessary adjustments?

To be fair, the coding you do in an interview is a bit artificial - the problems may not be typical and you are without the environment you are usually coding in. The good news is that it is a skill that you can work on and become better at, and it is usually worth doing so if you are pursuing a job and you know these kinds of things will come up. I don't think it is wasted effort either - I've been trying to work on my algorithm/data structure skills by solving interview-type problems, and I've noticed that the work I've been doing to learn to solve them better has been beneficial in my daily programming as well.

Your solution is fine, you've passed, flying colours. I might poke a bit around the edges to see if I can get you to say the word "array", but mostly out of interest.

The important bit is that this is not an assessment of your ability as a programmer, it's a negative filter: Are you one of these people who simply can't program, because if you can't, let's not waste any more of each others time.

Arrays. (Uhhg...I said it but I feel dirty.) ;-~

I've never liked arrays due to the brackets. But in a twist of irony, I now spend all day in Groovy and I use maps, thus brackets all the time. Yet I don't even notice.

So after carefully thinking about it, I now realize its not the brackets. I can't explain it. There's something about arrays I just despise despite having no similar ill will towards ArrayLists. They just feel so 70s.

Personally I much prefer a[i - 1] syntax over a.charAt(i - 1). The extra "charAt" seems noisy to me. But that's probably just my C background showing.

Dood....I checked your HN profile which led me to your blog. You're talking about decompiling Java code and bytecode diffing. That's hot. See, now that is dev stuff. That's hardcore. Love it.

Now, that was a puzzle :) It was pretty fun to diagnose, even if the knowledge isn't incredibly useful and probably a lot less impressive than it might look at fist glance. Figuring out how stuff works (and why it doesn't work like you think it should) is pretty fun - I wish I had more opportunities to do it.

And at 1), you went wrong, in any language where strings are in unicode. Combining characters, byte order markers, surrogate pairs... And this is why I dislike the 'reversing a string' question. Because if you actually know anything about real world string handling, you know that correctly reversing a string is impossible, because there just isn't any logical way to reverse some constructs. How do you reverse a string which contains bidirectional control characters? What is the reverse of an optional line-breaking hyphen? Even simple things like parentheses might trip you up.

Once you really start thinking about reversing a string, you realise why it's so difficult to do robustly: because there is actually no logical reason to reverse a string.

As an interview question, I would only credit an interviewee for this question if they basically objected to the requirement in the first place, and explained how bad an idea it was - but since I wouldn't expect most interviewees to do that it would be a poor test to introduce in the interview.

That is a really good point and it complicates a lot of string-based questions, which is why they are almost always constrained (either implicitly or explicitly) by assuming that the string is ASCII only, which seems reasonable to me.

There are probably better filter questions to use that don't require as many artificial constraints.

Of course, in ASCII you can just reverse the bytes. Oh, until you come across a CRLF... Or a backspace... and it still makes no sense to even do it.

Reversing a string was initially a good interview question because in C you can keep probing multiple levels of knowledge with it. You learn if the interviewee knows the algorithm, then if they understand how to do it in place with a pointer, then if they understand the XOR pointer trick. It's not a very interesting problem in a language like Ruby or Python.

For that kind of language, what simple question do you suggest? My objective is test if the candidate have basic coding skills...

> So you continue to use that question?

Well, yes. Is the most simple one I can think that show if a person can declare variables, do a loop and show the result. If exist something better, I wanna know!

Before that question, I do things more complicated. Like do some CRUD, or some kind of task that was realted to the company I was before. But my first results with that lead me to simplify the interview a lot (in time and questions) because I see that if a person can't do this kind of task is pointless try with something better.

And I don't do much presure. I let them alone and give them all the time they want, with internet acces and that. I continue doing my work while they complete the task.

Is important to understand that in my past companies I was tasked to interview fresh graduated coders, and for a lot of backgrounds. And they pay badly. So no much oportunity of get "top players" back them. However, I interview several people with (in theory) experience or from reputable universities and that not change at all the end results.

P.D: Some point to the complications of do this task properly (because unicode). I don't even expect that kind of depth in the answer, looking more in the basic skill, code formatting, and the ability to explain the code writed...

Reply on news.ycombinator.com