Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

Post reply on HN
Print view View original

31–40 of 315 posts

Re: People suck at technical interviews (2014)

#31

Post by mruniverse »

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

You really didn't know what they wanted? You think they wanted you to find a library that did it?

Re: People suck at technical interviews (2014)

#32

Post by MrLeftHand »

Scarblac wrote: post #23
MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

I disagree. You need to be able to find existing working solutions and use them, sure. But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid. They should however have told you that before the test.

Yes, they should have been more specific.

Problem solving skills go a long way especially in programming.

But then the question is how far should you go down the rabbit-hole.

For example, how many variables can someone use? How optimized should the code be, regarding memory and speed? Are you looking at the code to be understandable? Should I use comments? Should I use for or while?

Re: People suck at technical interviews (2014)

#33

Post by biztos »

PuffinBlue wrote: post #26

There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture,…

I agree completely, and this resonates with me particularly because I'm one of the many programmers also serious about other creative endeavors (in my case, the visual arts).

But it's worth considering that in larger companies, management is often terrified of the creative aspect of programming, because it messes with their primary goal of predictability. Thus they seek, many of them openly and explicitly, to make all technical roles fungible.

And as much as that's hurtful to us creative programmer types, it's not an irrational position for them to take.

The fact (or hope) that fungible programming roles can be more easily outsourced, especially to cheap-labor countries, is of course seen as a bonus.

This situation presumably gives a big advantage to any organization willing to engage with the creative aspects of programming, but I am starting to think it's in the nature of organizatins themselves to stop embracing that risk after a certain size is reached.

(Not that this is an argument against the portfolio idea. Even if you're going to work as a fungible cog, you'll probably get a better cog-job faster with a decent portfolio.)

Re: People suck at technical interviews (2014)

#34

Post by gavanwoolery »

mruniverse wrote: post #30
gavanwoolery wrote: post #28

Earlier quoted context omitted.

That is actually a really great point. Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell. Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the…

Would you hire a writer with bad grammar?

If they had a killer hook, yes. An editor can always review and fix the grammar. :)

A coding analogy: A compiler or debugger can catch bugs.

If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.

Re: People suck at technical interviews (2014)

#36

Post by zeemonkee3 »

MrLeftHand wrote: post #27
dijit wrote: post #19

Earlier quoted context omitted.

The issue is many companies have NIH syndrome, sometimes for a generally good reason. in the same circumstances I would have noted my find and copied the relevant code into my project, not because I'd do that in personal projects, but because companies only care about integrating their requirements with as few external dependencies as possible.

Yes, that is a problem as well. They don't want to use libraries from the outside, so they develop a lot of stuff in-house. Which will have specific requirements and getting someone up to speed takes longer then using an existing API, which is well known and used by millions of other companies and developers. Also most of the times these in-house APIs are developed by if not one, but a handful of people. So if they l…

Interviews like this are a two-way thing. In this case, I'd pick up the vibe that this was a company cursed with NIH and withdraw my application (unless I was desperate for a job or some other overriding factor, of course).

Technical interviews (much as I hate the whiteboarding bullshit) do give some insight to the interviewee about the kind of work and codebase they'll be dealing with - like the time an interviewer told me "We're really enthusiastic about MongoDB!" - OK, thanks for the coffee, I'll see myself out....

Re: People suck at technical interviews (2014)

#37

Post by hackinthebochs »

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

Did you actually think they wanted a roman-numeral converter? It should be obvious that the roman-numeral converter was a proxy to see how well you could reason through solving a programming problem. Surely you knew that was what they were after. That you seem incredulous that they didn't accept your clearly low-utility response is baffling.

Now, if you were signalling to them that googling a solution is the extent of your programming ability, then perhaps you were doing them a favor.

Re: People suck at technical interviews (2014)

#38

Post by MrLeftHand »

mruniverse wrote: post #31
MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

You really didn't know what they wanted? You think they wanted you to find a library that did it?

Yes, call me stupid.

I thought showing resilience by searching for an existing solution and implementing it, instead of reinventing the wheel, will give them a good impression. Clearly I was wrong.

But, when you come across a problem, what is the first thing you do? Try to find a solution and use that, or start from scratch every time? This costs money, time and manpower. Having someone who can solve a problem the fastest way possible without compromising the quality by using a known API which is used and tested by millions of others is the most effective way.

In my book it is a good solution. Believe me I worked with people who couldn't even do that and they are developers.

Re: People suck at technical interviews (2014)

#39

Post by prof_hobart »

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

You have to think about what they are trying to test. If it's "Do they know how to quickly find an answer to a known problem?", then your route is correct.

If it's "Could they take a problem that hasn't been solved before and solve it themselves?", then you're not really demonstrating that.

Unless I'm told otherwise, I would assume that a coding challenge would be more of the latter.

Of course, it's not how you'd solve it in real life. But that's like saying you should be allowed a calculator in a mental maths exam because you'd never try to to 27324/623 in your head these days.

Re: People suck at technical interviews (2014)

#40

Post by [deleted] »

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

[deleted]
Post reply on HN