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

41–50 of 315 posts

Re: People suck at technical interviews (2014)

#41

Post by zeemonkee3 »

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?

He's a developer, not a telepath.

In tests like this you make it clear what's allowed - "use the standard library, no external dependencies" etc. Because in a normal working situation, his solution is perfectly valid.

If I were interviewing him it certainly wouldn't be a dealbreaker. I'd probably want to discuss more about pros and cons of in-house vs using libraries, because you tend to find out more about the skills and qualities of a developer from human conversation than scribbling on a whiteboard.

Re: People suck at technical interviews (2014)

#42

Post by [deleted] »

gavanwoolery wrote: post #34
mruniverse wrote: post #30

Earlier quoted context omitted.

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.

[deleted]

Re: People suck at technical interviews (2014)

#43

Post by MrLeftHand »

hackinthebochs wrote: post #37
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 o…

A solution is a solution. Proving that you can search for a solution and use it is a positive thing. There are loads of people who can't do even that. It wasn't like copy-paste. You still have to understand how to write the code that uses the API, you still have to get the input from the console and write the output to it.

And if I follow your trail of thought, then I hope you're not using stackoverflow when you do your job, because that means you are relying on others to solve a problem for you. Does your boss know about this?

I wonder how many times you copy-pasted anything.

And just for your information I still provided a second solution for them after they frown back the first one.

But hey, sorry if I think solving a problem doesn't mean I have to write everything from scratch.

Re: People suck at technical interviews (2014)

#44

Post by ozim »

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,…

There are also different types of programmers. Some will do well with portfolio like web developers. But how you would approach creating portfolio as embedded dev? When you work on proprietary stuff and github repo does not really show that you do well with hardware, because customer might not have time/knowledge to run this stuff to check if it is actually working.

Re: People suck at technical interviews (2014)

#45

Post by hackinthebochs »

MrLeftHand wrote: post #43
hackinthebochs wrote: post #37

Earlier quoted context omitted.

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 o…

A solution is a solution. Proving that you can search for a solution and use it is a positive thing. There are loads of people who can't do even that. It wasn't like copy-paste. You still have to understand how to write the code that uses the API, you still have to get the input from the console and write the output to it. And if I follow your trail of thought, then I hope you're not using stackoverflow when you do y…

You're in an interview, you know they're looking for signals to your programming ability. You should offer them the maximally-informative signal without having to be prodded. Sure, knowing to search for an existing solution first is an asset, but that should be more-or-less a given. If you didn't want to assume it was a given you could have just mentioned that in the real world you would simply google for an API or an existing method as you were coding up the solution to their question. It just seems counter to the entire process of interviewing to expect essentially an API call to be acceptable in that context, so your apparent expectation that it would be doesn't seem reasonable at all.

Re: People suck at technical interviews (2014)

#46

Post by MrLeftHand »

prof_hobart wrote: post #39
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 sol…

I was thinking, but clearly my trail of thought wasn't the good one. Anyway, lessons learned. I hope...

Re: People suck at technical interviews (2014)

#47

Post by mruniverse »

gavanwoolery wrote: post #34
mruniverse wrote: post #30

Earlier quoted context omitted.

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.

Is the "technical" part really analogous to grammar? I don't think many interviewers care about that. They don't care about missed semi-colons. They want to see that you know how to solve a problem. And a github portfolio is not going to give them that.

As an aside, I think debugging is hard even with a debugger.

Re: People suck at technical interviews (2014)

#48

Post by MrLeftHand »

hackinthebochs wrote: post #45
MrLeftHand wrote: post #43

Earlier quoted context omitted.

A solution is a solution. Proving that you can search for a solution and use it is a positive thing. There are loads of people who can't do even that. It wasn't like copy-paste. You still have to understand how to write the code that uses the API, you still have to get the input from the console and write the output to it. And if I follow your trail of thought, then I hope you're not using stackoverflow when you do y…

You're in an interview, you know they're looking for signals to your programming ability. You should offer them the maximally-informative signal without having to be prodded. Sure, knowing to search for an existing solution first is an asset, but that should be more-or-less a given. If you didn't want to assume it was a given you could have just mentioned that in the real world you would simply google for an API or a…

To be honest this was like 4 years ago. I thought it was a good thing to show that I can get things done in way it costs less effort and time.

I was wrong, I moved on, so did they.

If I would have a similar test today I wouldn't go down the same route, because I know what they would expect.

Maybe it was my sysadmin past talking back then. Trying to find a good existing solution for the problem.

Re: People suck at technical interviews (2014)

#49

Post by epalmer »

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…

Admittedly my situation is different than probably 95% of the HN readers that develop code. I write mostly Java code for my university job. I develop code about 30% of the time. The code I write and maintain are mostly ETL / Middleware solutions that stay in-house. I have an associate that is learning Java and will take over when I retire in 5 years. I have no one telling me what I can and can't use. My bosses expect me to make sure that the license for the libraries I use are compatible with our culture and risk profile. And most are apache 2 licenses.

Without the use of libraries I could not get my job done. I rely on Apache Camel and Apache Httpcomponents heavily. In fact I am replacing a home grown Middleware solution with one that uses Camel right this month because the homegrown solution is just not extensible. I use other libraries as well like Jdom2.

The risk in these libraries going stale exists but is low enough to outweigh the risk of me writing crappy code because my expertise is not that great in writing middleware, xml parsers and the like. My applications work as intended. My management is happy. I am productive in their eyes.

I don't have a NIH attitude.

Edit: added this statement.

At 62 years old I think I am glad I don't foresee the need to change jobs and go through the "modern" developer interview process. I feel for those that have to do this dance.

Post reply on HN