4 ms·

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

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 not we wanted. We would like to see, how you would solve it with general code. So you're saying that doing investigation work, finding an existing working solution and applying that solution is not a good answer for you? Sorry but that's how I work. I find a problem; I investigate for a solution; if there is one I use it and implement it; if not then I will write one. The moral of the story is: interviewing is fundamentally wrong and doesn't help you find a good candidate. There are millions of good solutions to one problem in programming. Asking for a solution you want to see and not a solution that solves the problem will never help. Then why don't you clone yourself and have an army of developers which work the same way and produce the same code with the same flaws over and over and over.

dijit 10y ago
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.
- MrLeftHand 10y ago
  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 leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways. Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go. It is a vicious cycle and it seems nobody is willing to break it.
  - zeemonkee3 10y ago
    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....
  - epalmer 10y ago
    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.
Scarblac 10y ago
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.
- MrLeftHand 10y ago
  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?
  - scottlamb 10y ago
    fwiw, I think there are reasonable ways to approach these kinds of issues that will work with any interviewer you'd actually want to work with: > For example, how many variables can someone use? I've never heard of an interviewer explicitly limiting this, but if you have enough variables that you're asking, it might be a sign you've missed a more elegant solution to the problem... > How optimized should the code be, regarding memory and speed? Don't spend a lot of time on something before you know if it's what they want. You shouldn't go all the way through debugging the naive solution before you know if they're looking for something optimal; you shouldn't look for a very complex but theoretically optimal solution if they looking for fizz/buzz level of complexity. To make it more concrete, many of my candidates just say something like "I could put everything into an array, sort it, and print it", maybe even adding "in O(n) memory and O(n log n) time". When that happens, I write down "quickly got naive solution", ask "what if we don't have O(n) memory?", and wait for them to (or help them) come up with something else. That's great from my perspective, as is asking me explicitly how much RAM is available / how large the input may be / if I want an optimal solution or an easy-to-understand one. > Are you looking at the code to be understandable? Should I use comments? In general, they're probably looking for it to be understandable, but they should know if you're coding under time constraints on a whiteboard that it's hard to revise quickly, that you can't fit a lot of stuff there, and that it's a lot faster to say aloud what you might otherwise put in a comment. If they don't make allowances for that, you'd probably hate working with them anyway... Consequently, understandability might be more be about picking a meaningful variable name or thinking for a moment if you actually need to special-case some path before adding that extra if statement. Maybe drawing a quick diagram of your data structure. And if you have extra time (a judgement call: maybe if you have a working solution, they aren't trying to move you on to another problem, you have don't have anything more to ask them), you could refine a bit. > Should I use for or while? They should know you haven't had the chance to read their internal style guide. They shouldn't care about this. I also think they should give you significant leeway for minor syntax errors (saying, missing a ";"). There's a line somewhere between that kind of nitpicking and needing to see that you actually understand the language's syntax. It differs a little by interviewer. If you're anywhere close to the line, they should point out what's bothering them (perhaps saying "the compiler says ...") and give you an opportunity to correct it. If they don't, again they're probably kind of a jerk.
mruniverse 10y ago
You really didn't know what they wanted? You think they wanted you to find a library that did it?
- MrLeftHand 10y ago
  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.
  - rickr 10y ago
    As long as they didn't state you can't use external libs it IS a good solution. Their response lets their team dynamic and environment shine through. They came across an unexpected but valid solution and instead of accepting their question was beaten within the rules they rejected it. I'd wager they didn't fix the wording of the question afterwords either.
  - marcosdumay 10y ago
    Don't call it "stupid". Reading people is a skill like any other, that must be learned like any other. Most people get lots of practice when young, but not getting this practice does not make you "stupid", it makes you lacking on a specific skill.
- zeemonkee3 10y ago
  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.
hackinthebochs 10y ago
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.
- MrLeftHand 10y ago
  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.
  - hackinthebochs 10y ago
    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.
    - MrLeftHand 10y ago
prof_hobart 10y ago
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.
- MrLeftHand 10y ago
  I was thinking, but clearly my trail of thought wasn't the good one. Anyway, lessons learned. I hope...
deleted 10y ago
[deleted]
trumbitta2 10y ago
I agree with all you are saying so much that some months ago I had to write about it: https://www.linkedin.com/pulse/william-versus-technical-interviews-william-ghelfi https://www.linkedin.com/pulse/william-versus-technical-inte... The TL;DR of my (short, truth be told) blog post is the moral of your story.
- MrLeftHand 10y ago
  Thank god, it's not just me then. I had an interview where the guy was staring at me like I was interrogated. I had to solve a problem of concatenating to arrays of integers and putting them in ascending order. I was literally frozen and couldn't think and stood there like an idiot for 5 minutes whilst the guys was just staring at me, not making a sound. I don't have to tell you I felt destroyed after that. I felt I was a good for nothing idiot and should go shovel dirt then develop software. I still shiver a bit when I think back. The other things that I hate are the always reoccurring questions. Like what's an array; what's a map; what are the differences; etc... Come on I've been developing for quite a while now. I've been a sysadmin before that. I'm working in IT for more then 10 years now. Do you really feel the need asking all these things?
st3v3r 10y ago
No, they clearly wanted to see you write code. They didn't want to see how well you could download a library. That's why they gave you the test in the first place.
scottlamb 10y ago
> What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code. This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution? When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use <library X / programming language Y / tool Z>?" but my answer might be no. I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else. Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.

dijit 10y ago

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.

MrLeftHand 10y ago
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 leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways. Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go. It is a vicious cycle and it seems nobody is willing to break it.
- zeemonkee3 10y ago
  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....
- epalmer 10y ago
  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.

Scarblac 10y ago

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.

MrLeftHand 10y ago
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?
- scottlamb 10y ago
  fwiw, I think there are reasonable ways to approach these kinds of issues that will work with any interviewer you'd actually want to work with: > For example, how many variables can someone use? I've never heard of an interviewer explicitly limiting this, but if you have enough variables that you're asking, it might be a sign you've missed a more elegant solution to the problem... > How optimized should the code be, regarding memory and speed? Don't spend a lot of time on something before you know if it's what they want. You shouldn't go all the way through debugging the naive solution before you know if they're looking for something optimal; you shouldn't look for a very complex but theoretically optimal solution if they looking for fizz/buzz level of complexity. To make it more concrete, many of my candidates just say something like "I could put everything into an array, sort it, and print it", maybe even adding "in O(n) memory and O(n log n) time". When that happens, I write down "quickly got naive solution", ask "what if we don't have O(n) memory?", and wait for them to (or help them) come up with something else. That's great from my perspective, as is asking me explicitly how much RAM is available / how large the input may be / if I want an optimal solution or an easy-to-understand one. > Are you looking at the code to be understandable? Should I use comments? In general, they're probably looking for it to be understandable, but they should know if you're coding under time constraints on a whiteboard that it's hard to revise quickly, that you can't fit a lot of stuff there, and that it's a lot faster to say aloud what you might otherwise put in a comment. If they don't make allowances for that, you'd probably hate working with them anyway... Consequently, understandability might be more be about picking a meaningful variable name or thinking for a moment if you actually need to special-case some path before adding that extra if statement. Maybe drawing a quick diagram of your data structure. And if you have extra time (a judgement call: maybe if you have a working solution, they aren't trying to move you on to another problem, you have don't have anything more to ask them), you could refine a bit. > Should I use for or while? They should know you haven't had the chance to read their internal style guide. They shouldn't care about this. I also think they should give you significant leeway for minor syntax errors (saying, missing a ";"). There's a line somewhere between that kind of nitpicking and needing to see that you actually understand the language's syntax. It differs a little by interviewer. If you're anywhere close to the line, they should point out what's bothering them (perhaps saying "the compiler says ...") and give you an opportunity to correct it. If they don't, again they're probably kind of a jerk.

mruniverse 10y ago

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

MrLeftHand 10y ago
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.
- rickr 10y ago
  As long as they didn't state you can't use external libs it IS a good solution. Their response lets their team dynamic and environment shine through. They came across an unexpected but valid solution and instead of accepting their question was beaten within the rules they rejected it. I'd wager they didn't fix the wording of the question afterwords either.
- marcosdumay 10y ago
  Don't call it "stupid". Reading people is a skill like any other, that must be learned like any other. Most people get lots of practice when young, but not getting this practice does not make you "stupid", it makes you lacking on a specific skill.
zeemonkee3 10y ago
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.

hackinthebochs 10y ago

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.

MrLeftHand 10y ago
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.
- hackinthebochs 10y ago
  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.
  - MrLeftHand 10y ago

prof_hobart 10y ago

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.

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

deleted 10y ago

[deleted]

trumbitta2 10y ago

I agree with all you are saying so much that some months ago I had to write about it: https://www.linkedin.com/pulse/william-versus-technical-interviews-william-ghelfi https://www.linkedin.com/pulse/william-versus-technical-inte... The TL;DR of my (short, truth be told) blog post is the moral of your story.

MrLeftHand 10y ago
Thank god, it's not just me then. I had an interview where the guy was staring at me like I was interrogated. I had to solve a problem of concatenating to arrays of integers and putting them in ascending order. I was literally frozen and couldn't think and stood there like an idiot for 5 minutes whilst the guys was just staring at me, not making a sound. I don't have to tell you I felt destroyed after that. I felt I was a good for nothing idiot and should go shovel dirt then develop software. I still shiver a bit when I think back. The other things that I hate are the always reoccurring questions. Like what's an array; what's a map; what are the differences; etc... Come on I've been developing for quite a while now. I've been a sysadmin before that. I'm working in IT for more then 10 years now. Do you really feel the need asking all these things?

st3v3r 10y ago

No, they clearly wanted to see you write code. They didn't want to see how well you could download a library. That's why they gave you the test in the first place.

scottlamb 10y ago

> What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code. This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution? When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use <library X / programming language Y / tool Z>?" but my answer might be no. I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else. Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.