11 ms·

I’m an Engineer, Not a Compiler

263 points by Luyt 15y ago

ExpiredLink 15y ago
I guess it's hopeless.
deleted 15y ago
[deleted]
jimbobimbo 15y ago
The article was almost good until this part: "They do not necessarily know all of the details of syntax of a given language, especially if they are used to a good IDE which does it for them..." followed by description of IDE guessing which package the class is in. Um, no. If I'm interviewing a software engineer for C# or C++ position, I'd expect them to know syntax of the language they're claiming their proficiency in. I wouldn't care if someone wouldn't remember details of standard library/framework (heck, I wouldn't even ask - this IS a stupid question), but if a person can't write 10 lines of framework-agnostic code in the language they claim they are specializing, that's the end of interview right there.
DrJokepu 15y ago
> My favorite phone interview question? “What’s your favorite language?” followed by “What are it’s weaknesses?” This is also one of my favourite questions to ask when I'm interviewing someone. Unfortunately most of the time the only response I get is confused stares. Maybe this is just a UK culture thing but it feels like many people are not prepared to display critical thinking on a job interview.
- ntkachov 15y ago
  Depends who you ask. Ask most people at my school and they will give you an answer of "Java". Is Java their favorite language? No. Its their only language. Also if one cannot understand the philosophy behind the language that they are using and express why they like that philosophy and what benefits it brings, they probably aren't using the language right. However, ask anyone who is great at what they do and you got yourself an hour long discussion.
  - bmj 15y ago
    In my experience (on both sides of the table), it's okay to say "what are the shortcomings of language_x" if you are interviewing for a specific set of skills. If the candidate has a list of languages on their CV, then it may be worth asking the "what's your favorite language" question first.
- Argorak 15y ago
  Thats a great question to find newbies. It shows that the candidate has deep experience with the language or programming. As an ancodote: I was on RailsConf Berlin 2007, as a Ruby programmer with 3-4 years of Ruby experience. It was like being the grumpy old man (with 23 years :) ) in a group of young, happy and fundamentally unexperienced people. Most of them had about 6 month or less of ruby experience, they just hadn't seen the bad parts yet. I think any experienced programmer can rant for a least 5 minutes about his favorite language. Also, I think that experienced programmers can quickly find valid criticism even in languages that they don't use all day. And I think thats global. Most people aren't critics and will hop onto any prepared argument they can find. Thats why I hate most discussions about software.
- djhworld 15y ago
  It depends who you ask, a lot of developers out there are not polyglots and mostly (especially in the enterprise world) are good old 9-5'ers who have no interest in programming outside of work time. I've encountered many people like this. Nothing wrong with that obviously, but asking a question like "what is your favourite language" is never going to yield fair results across the board
  - dsrguru 15y ago
    I think the point here is that you want to weed out such monoglots that lack a deeper understanding of CS and instead find a hacker who loves coding and has exposure to many languages, paradigms, data structures, etc. If that's your goal, wouldn't asking "what's your favorite language" yield very fair results?
    - cunac 15y ago
      Personally I would think you want somebody who can get job done instead of some ADD kid which is jumping from one hyped language de jour to other. But that is only me , YMMW
      - tikhonj 15y ago
        That is a false dichotomy--just because somebody is interested in different languages does not mean they are "some ADD kid" and, moreover, somebody exclusively working 9-5 with no particular passion to programming is probably not "somebody who can get the job done" especially if the job is non-trivial. And if you're hiring for a trivial position, optimizing your interview process is probably a waste of time anyhow.
        onemoreact 15y ago
        It takes a long time to become a truly awesome developer. And working more than 9-5 tends to burn people out over time. Which is why I suspect most of the top programmers in the world are much closer to 9-5'er than most people on HN are willing to admit. PS: One of my favorite stories of such a person goes something like this. Coder X was fired after failing to get a 6 month project finished after a full year. Greg, took two 40 hour weeks to read the documentation and slap something together to keep the project from slipping, but made a simple mistake which ended up causing significant problems in production a few days later. After fixing the problem he asked the QA people why they put it into production that quickly while missing such a basic issue was not discovered. Their response, we stopped testing your code a few years ago and this is the first problem that's showed up. The most interesting part of this story is if Programmer X had got his code to work after say 11 month he would no have been fired. Which means the company would employ someone that's 3% as effective as this guy.
- tomp 15y ago
  I have seen so many programming languages that my only answer to the first question can be, "None". Haskell is too restrictive, OCaml too verbose and inflexible, Java lacks closures, Javascript has weird equality semantics, C lacks garbage collection, Python lacks static typing, Clojure has too many `)))`s, Ruby is inconsistent, ... I could go on. In the end, I just settled on a language that I have to use at work (currently Python), but I'm wishing for something better to come along...
  - DrJokepu 15y ago
    You see, what you've just written down is a perfectly fine answer to the question.
  - gaius 15y ago
    There are two kinds of programming languages, those that people hate, and those that no-one uses.
  - Yrlec 15y ago
    You should try C#. It's like Java with closures (and some other nice features: http://stackoverflow.com/questions/610199/the-art-of-programming-java-vs-c-sharp http://stackoverflow.com/questions/610199/the-art-of-program... )
    - tomp 15y ago
      C# is one of the most interesting languages, really. It's been developing really fast, and along with F#, it shows that MS is really putting an effort into programming language progress. However, my main concern with C# is not the language, but the libraries/ecosystem. It's so tightly bound to Windows that it hurts. There are no good cross-platform implementations, poor IDE support, and I'm pretty concerned developing for a runtime that might go away... Now, if only MS would open-source their implementation, most of these arguments would become void.
      - silverlake 15y ago
        Mono is pretty good. F# also runs on the Mono runtime.
- papercruncher 15y ago
  Along the same lines, my favorite question is "What is your favorite data structure?". Most of the time, the answer is HashTable followed by a complete lack of understanding as to how a hash table works. Occasionally someone would respond with 'Quick Sort' Every now and then you get a candidate whose eyes lit up and you can't get them to shut up (in a good way). And that is the story about how I discovered judy arrays.
- v0cab 15y ago
  Perhaps the word 'limitations' might be more appropriate than 'weaknesses'? A 'weakness' implies some kind of flaw, whereas a limitation is something the language wasn't specifically designed to do or specialise in.
  - scott_s 15y ago
    I think weakness is appropriate. For example, I love Python. But I only use it for automating system tasks and data post-processing. It just doesn't perform well enough for me to use it as part of the infrastructure in a high-performance system. I do consider that a flaw; it is a weakness. It is also a limitation, but when given a choice between synonyms, I prefer the stronger one.
- CaptainZapp 15y ago
  I was thinking about this question and agree, it's a good one. Just out of curiosity: How would you react if my answer is: Shell?
  - jerf 15y ago
    Then I would hope to hear something about dangerous quoting or difficulties in abstracting things or how it affords some fairly dangerous practices and writing rock-solid shell scripts takes disproportional effort vs. other languages or possibly how it can be slow if you're not careful, though I'd consider that a last-tier objection. But it would be a bit of a bizarre choice. I would expect it only if you were coming out of a sysadmin position transitioning to a developer. (Which I've seen, so I don't mean that as some sort of implicit impossibility.)
    - CaptainZapp 15y ago
      Actually I'm coming from database programming, primarily in SQL, where scripting can add immense value to whatever you're up to. That said, I very much agree with your sentiments and it does require effort to write resilient, maintainable scripts. Nevertheless, for my day to day work it's probably the most useful "language".
  - Danieru 15y ago
    I imagine he would say 'What are the weaknesses of bash scripting?'
- varikin 15y ago
  I love this question and have been using it lately though not tied directly to languages. It works great for frameworks and libraries (think Hibernate, Spring, etc) as well. I am uneasy about programmers who are passionate about a technology without being able to talk the problems with that technology.
dmitrykoval 15y ago
If you happen to be asked such questions it might be a good indication that the type they are looking for is code monkey. Or they are just not good enough to assess engineering skills. In both cases it's a red flag.
- jimbobimbo 15y ago
  Yeah, basically one should always remember that interview with a company always works both ways. It's OK to ask questions or just listen to your internal BS-o-meter while talking with company reps.
newssy 15y ago
Technically, you are just a person who converts money and coffee to code. So shut up all the whining and grow up.
staktrace 15y ago
I disagree with some parts of the post. I think good engineers have to be able to work effectively at a high "system" level of abstraction as well as at a low "compilation" level of abstraction. If you can't look at a chunk of code and know enough about the language to know that it could throw a ClassCastException, then it is quite likely that you will fall prey to other language gotchas which can bubble up and destroy the entire design of the system you're trying to build. I don't think the current state of the art in software development has yet advanced to the point where we can just black-box away all of the entire "compilation" stuff such that it never affects the "system" stuff. I really would like that to be the case, because it would eliminate a lot of unnecessary complexity in software development. I think asking a limited number of compiler-level questions (less than 5) in an interview doesn't take up a lot of time, and can allow you to get an idea of how much actual experience the candidate has with the language as well as dealing with nitty-gritty problems that come up while you're coding. The value and time spent are both small, so the value/time ratio is probably in the same ballpark as any other question you might ask.
- ajuc 15y ago
  I don't know. I remember problems with different classloaders, old versions of classes being deserialized, different versions of classes being sent over RMI, etc. Some of these probably resulted in ClassCastException. Some had thrown more specific Exceptions, am I supposed to remember the exact Exception that was thrown in each case? I'll probably know if you show me stacktrace. But I only know because I've encountered such problems. People working on the other end of our system would recognize different set of problems that results in this Exception or similiar. Nano questions are bad, because you are really asking if candidate has had the exact same experience that you had. Some did, some didn't, it doesn't matter. Anybody will solve the problem within minutes, most probably googling the most promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or grepping the source tree, whatever). Even auto-importing packages in IDE can cause problems - sometimes it imports from the wrong package. Is it enough reason to ask questions about "which package contains Hibernate Session class?" or even "which package contains ArrayList class?". I don't think so. Being aware of the problems good abstractions can cause (there's always a few problems) is IMHO enough, no need to remember everything you can google in 5 seconds. EDIT: or maybe you meant that you just check if people know casting can throw ClassCastException, with that I'm OK.
slavak 15y ago
I for one would be grateful if an interviewer asked me this kind of question. It gives me an instant and unambiguous indication that this is not a place I want to work, saving me a lot of wasted time - and God forbid if I'd otherwise actually ended up accepting a job there.
- hashbo 15y ago
  It’s usually a bad sign about the interviewer’s interviewing skills, not always them as a person or the team. I have worked for some nice, amiable smart folk who interview like crazy people. It’s the whole > IT skills < social skills thing. But I empathise - I really don’t like interviews which are like that, especially when they’re usually a game to try and make the interviewer seem smarter than the interviewee.
shimfish 15y ago
I had a company that was ready to give me a job make me take a PHP test on http://www.123assess.com http://www.123assess.com After the 10th question asking me to debug 30 lines of obfuscated code in my head while a 3 minute countdown ticked away, I called it a day and decided these were people I didn't want to work for.
deleted 15y ago
[deleted]
gbvb 15y ago
I believe Any senior engineer worth his salt should be able to do lint style verification of someone else's code quickly. When I am expecting someone to be a senior enough engineer, they should be able to look at someone's code during Code reviews and find the issues in it that can lead to problems without resorting to IDE/debugging. I do agree that nano-questions are not useful except in situations where you get a resume with keyword bonanza: You know the kind, ones with every language,OS in the first page listed so that they will pass through the corporate recruiter filter. For those, nano-questions trip up but that will give me an indication to dig a little deeper into their IDE usage pattern. If they show some proficiency in it, (for e.g., tell me the command in Eclipse to find all the references to a particular method, if the answer is search in files, .. :)).
- wladimir 15y ago
  If you want to someone to do lint, why not just run lint and save on an expensive hire? Code reviews are there to find problems with the code that are not found by trivial static verifiers and/or IDEs. This requires a level of understanding of the language and experience in reading (instead of writing) code, but has nothing to do with regurgitating keyword definitions. Better in that case to just give a code fragment and make them spot the (algorithmic, logic, security, not spelling) errors.
  - gbvb 15y ago
    Ok. I was making a point but I guess you are right about lint. I was trying to point out that it is easy have developers write code that can easily be O(n2) vs O(n log n) because this did not use the right kind of the maps when they were initially building the code. Or I can see developers using HashTables vs HashMaps interchangeably and not see the threading impact. In these cases, some basic questions about their understanding of the classes seem to be a good indicator. Would you consider that a nano-question? I was..
dhotson 15y ago
I'm kind of on the fence on this. These questions might seem pretty lame, but as an interviewer it does tell you something about the candidate's level of experience with a language. If you've worked with a language for any decent amount of time. There are things that you really should know without having to look it up all the time. This is especially true if you mention on your resume that you're an expert at something. I'm definitely going to ask you a difficult question about it and I'll expect you to answer in some depth. If you mention you're a Java pro but can't tell me what the 'synchronized' keyword does for example. I'd be concerned.
- zeru 15y ago
  If you are trying to hire an "expert" and ask him questions like that, you are doing it really wrong, unless you are trying to scare him away. If anything you want to actually talk to him about what he has done, about the languages, his thoughts and passion in the subject... not ask him first programming classes in college questions. However if you are trying to hire some kind of junior-like engineer who has never had a job before, i can see why questions like this could be asked, but i still dont think it's the best way to gather knowledge about the person you are interviewings level of expertise.
  - jiggy2011 15y ago
    I think these could be weeder questions for people you know little about. If you have an applicant who has a github full of great code or experience working for a good software company you can probably skip this. However if you get a candidate without much on paper but who insists they are a Java expert but doesn't know what the extends keyword does then there is something wrong somewhere. The problem with asking for definitions for words though is that I personally often forget exactly what these are if I ever learned the correct term in the first place. For example I knew how to override methods and the differences between the type system in PHP and the one in Java long before I knew what polymorphism or "dynamic typing" meant.
  - dhotson 15y ago
    Don't get me wrong. I ask all those other questions as well. The problem is: people lie. It's the old thing where if you want to hire a juggler, don't you want to see them juggle?
funkah 15y ago
> Basically: Any question that takes 5 seconds to answer with Google is not a good question. Can't argue there. I haven't done a ton of interviewing in my career so far, but it is important to me to find out how the other person thinks. Being able to cite function names and package identifiers from rote is not important, at all.
- Turing_Machine 15y ago
  From another POV, I would argue that being able to use Google-searchable resources effectively is a very important skill that should be explored more thoroughly in the modern interview process. The examples and code snippets available on the web (e.g., Stack Overflow) can save hours and hours of time (= money), particularly when the official documentation is crappy. Coupled with that, maybe some questions would be in order about how and when you're legally allowed to use the stuff you find using Google (MIT license? GPL? Creative Commons? How do I have to attribute this stuff? Do I have to release the source?).
burke 15y ago
I'm coming at this from the perspective of someone with a pretty good memory for things like this, but those particular "nano questions" seem pretty damn fair to me. They're fundamental enough that it's not really relying on random trivia; they're testing things that you need to know 90% of the time to write a program, no?
- kevingadd 15y ago
  You don't need to 'know' them because you can literally find them out in 500 milliseconds. There's no value whatsoever in memorizing it. It's a useless factoid. I use C# almost every day and if you quizzed me about what namespaces certain types are in, I'd probably get it wrong. That's not because I haven't been using it regularly for years (I have), it's because that shit isn't worth wasting brain cells on. Even worse, though, the modern programmer ends up using a lot of languages. I have, in the past few years, had cause to write C#, Python, C++, C, Perl, JavaScript, ActionScript, PHP, SQL, Lua, Objective C, and Ruby. All for work. Each one has its own syntax, semantic quirks, standard library, etc. Out of all of the important things for someone to understand about a language - why would you care about something as unimportant as the exact namespace/package path of a particular type? Does that matter? Would you rather know whether I know the exact namespace Adobe's JSON parser lives in, or would you like to find out whether I'm familiar with the ins and outs of the ActionScript runtime? Honestly, if you think the kind of minutiae this article mentions is a good interview question, there's no way I'd want to work for you, because you don't care about things that matter - culture, candidates' desire and ability to learn, candidates' willingness to teach others, etc.
- funkah 15y ago
  I just don't know what I would stand to gain by learning that the candidate can recall from memory which package the Java List class is in. It seems pointless to ask.
edw519 15y ago
Imagine interviewing carpenters: Method 1: How many ten penny nails in a pound? Who makes better screwdrivers, Craftsman or Snap-on? Why? What's your favorite toolbox? Why? How can you tell when wood has been treated? Why should you measure twice, cut once? Which end of the hammer do you hold? Method 2: Show me something you built. Describe what you did. Cut this piece of wood according to these specs. If you needed someone to build your house, which method would you choose?
- deleted 15y ago
  [deleted]
- moocow01 15y ago
  Actually know a guy who just had to completely redo his deck because the contractor used the wrong nails on treated wood. So in that regard technicalities do have some signifigance.
  - matwood 15y ago
    Method 2 would have covered it with : Show me something you built. Describe what you did. When the person describes what they did that opens up questions around materials, methods, and technicalities. Just having them tell you what a certain kind of nail is would have been useless without also demonstrating they used it properly when needed.
  - brudgers 15y ago
    The fact he was using nails rather than screws for a deck should have been the first clue. But neither method would have overcome your friend's lack of expertise.
- DavidWoof 15y ago
  If I had to deal with the fact that 85 out of 100 applicants got the "end of the hammer" question wrong, you can bet I'd always start with method 1 just to filter out the imposters. That would free up time to correctly use the method 2 with the remaining 15 applicants.
srean 15y ago
IDE dependency? Perhaps, but that isn’t necessarily a bad thing since that is representative of the tools they will be using in the office. Mine is perhaps an unpopular view. I have come to believe that a decent programmer can and should be able to work well enough without an IDE. Presence of an IDE should be a sufficient condition not a necessary condition and I see so much of the latter. IDEs are a crutch and there is a minimum level of "walking" that I expect from you without a crutch. If you have to reach for a crutch even for the simplest tasks you will earn my suspicion that you are not as comfortable as the other guy in more complicated operations. As for the claim that IDEs are a representative tool, it need not be true, more for a start up pushing the envelope. Who knows which new or non mainstream language/technology will be most suited for the job. There may not be any mature tooling available yet. I would want my co-hacker to be able to cope. To give an example, there was this guy who claims he knows scala, but loathes working on a scala project because apparently there are no mature debugger for scala in eclipse. For him a eclipse plugin is a necessary condition. I have seen too many programmers who program in the following mode - let me type something in the IDE. No errors detected ?, good. Let me test it on a few cases. Didn't work ? let me bump up the loop bound by one, no cookie ? let me decrement it by 2, didnt work, let me change the sign of this expression from positive to negative -...ad infinitum. I am more scared when such a code passes a few half assed test cases and the author cannot explain why the fix works. I am not saying IDE are universally bad, quite the contrary. I advocate IDEs, but under two scenarios - (i) you are learning a new language (ii) you are an expert in that language. It is the overly populated middle ground, where it is used as a substitute for (a) thinking about your code or (b) knowing the language, that worries me.
- pnathan 15y ago
  If you have to use an IDE to program, you're not programming in the language, you're programming the IDE. There are many times I have to log into remote systems and all I have are nano or vi. Not even emacs. If I have IDE-dependancy, I'm up a creek without a paddle.
  - eropple 15y ago
    If you're hot-patching code in a remote environment, you have much bigger problems than "I don't have an IDE!". I use an IDE--and for many languages, ex. Java, Scala, and C#, would say I have to--because my time is worth something to me.
phatbyte 15y ago
To me, a perfect interview would be: "Here's a coding challenge, go home, write the code to solve this, come back tomorrow and tell me three things: - How you did it, - Why you pick this solution, - How it could be improved" by doing this I could see how he writes code, if he's just a google copy&paster, and what's his skills in algorithm optimization etc...and specially, how he/she thinks. Quite frankly I don't care if someone doesn't know what Polymorphism is right from his head. I didn't knew what polymorphism was until a few months ago, and yet I was applying the same principles in a lot places in my code. That's the downside of being a self-taught you don't get to know a lot of theory, but on my work I know I'm doing it right. (Also because polymorphism is a very abstract thing to be honest....) In a nutshell, get developers who can show you their code and can it explain it, don't rely on theory, you are not hiring a college professor.
raganwald 15y ago
I’m going to take the incredibly unpopular stance that nano-questions are not considered harmful. It’s true that only asking nano-questions, or emphasizing them, or thinking that a good engineer must necessarily be able to answer all of the nano-questions perfectly are all broken ways of thinking. But I look upon them as a kind of FizzBuzz. I know for a fact that while you can look them up in Google in 500 nanoseconds, experienced people doing hands-on work are going to be able to answer 2/3 nano-questions instantly. A few such questions sprinkled in the opening part of the interview are useful for weeding out the AbstractArchitectureAstronautFactoryFactories from the Programmers. I’m not talking about esoterica, e.g. “What is protected inheritance in C++?” Lots of practitioners might say, correctly, that they never use it and can easily look it up if you need to know how it works. And sometimes answering esoterica correctly has negative correlation: You end up hiring people who are SmartButTooBusyPlayingWithCoolIdeasToGetStuffDone (I’m a prize example of this). But if a programmer says he’s working with jQuery and I ask him to explain the difference between $(‘.foo.bar’), $(‘.foo,.bar’) and $(‘.foo .bar’), I don’t want to hear from him that he can look it up on the Internet, a jQuery programmer knows the answer. It’s acceptable for someone to say, “I don’t know jQuery, but I’m a smart guy, I can figure it out on the job by looking stuff up,” but if he says he’s been using it to build awesome HTML5 applications, I want to ask a few of these questions to make sure that I’m interviewing the person described on the resumé. A working programmer will know the answer to all of them, they shouldn’t be hard. Interview pressure will cause some fuzz, so I don’t expect perfect, maybe get 2/3 or 3/5 right and then we can talk about composition vs. inheritance or whatever other pet “Start a conversation with a smart person” question. I want to be incredibly clear about this: I don’t think that there is some strong correlation between memorizing things and being a good programmer. I don’t think programmers should rush out and memorize trivia just to “pass” an interview. I look stuff up all the time in my job. But I do think that if the questions are easy and obvious to the working programmer, a few of them are an appropriate FizzBuzz for weeding out the folks who have falsified their hands-on experience. By and large, interview questions are a touchy subject because they serve as a kind of metric for valuing people. So when I say I think it’s cool to ask a few of these questions, some folks are going to think that I say that I measure their worth by whether they know a handful of bits of information. That’s not the case. I’m not saying you’re unworthy if you don’t memorize things. But I am saying that if you claim to have a certain type of experience, there are some questions that are going to be dead easy for you to answer, and those questions are going to help us get to the good part of the interview very quickly. p.s. List vs Set is a funny question. I can’t imagine anyone with a degree being ignorant of the difference regardless of the programming language! It’s also a good lead-in to a more experiential question: “Okay, can you describe a time you’ve used a set of some kind? What were you trying to accomplish? ..."
XcodeNoob 15y ago
So an interviewer asked dumb questions, and sometimes they get my orders wrong at McDonalds. NEXT.
deleted 15y ago
[deleted]
jussij 15y ago
This is why as a 20 year veteran of Windows C/C++ programmer I no longer bother applying for C/C++ software development contracts. I really don't give a stuff that your Boost/STL trick question is missing a semi colon, which in reality would result in pages and pages of false compiler error messages. I really don't want to try an second guess the compiler and tell you where the missing semi colon should go. I use the compiler to detect my mistakes. I read the compiler output error messages, understand the message and fix my mistakes. But I don't pretend to be a compiler. I'm a software developer. I use the tools available to me to write software.
- qwe123_troll 15y ago
  There is no such language as "C/C++". In fact, when I interview programmers, saying that you program "C/C++" is an immediate red card and a thank-you-we-will-contact-you-later.
robomartin 15y ago
"A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language" Precisely. I'll take someone who can think this way before someone who can rattle-off all of the minutiae about a particular language. I've run across too many programmers who don't have a clue about project organization, MVC, data representation, optimization, etc. Yet, they can pass minutiae-filled tests about a particular language. Unless you've been programming in a single language for an extended period of time you will not have encyclopedic knowledge about that language and its libraries. Get 15 to 20 languages under your belt and the effect is more pronounced. I know exactly what it takes to write a number of sort algorithms, genetic solvers, neural networks, real-time embedded OS and more. No, I can't rattle off exactly how to write it in the language of the day. When switching to a language I haven't touched for a while it takes me two to four weeks to "task switch". I surround myself with reference books, use the IDE and any available online resource. Somewhere during that period I start to rock. I get the job done and produce clean and efficient code, fast. I would probably fail the kind of questioning the article describes. Yet I've been solely responsible for large projects using languages spanning from assembler to Forth, C, C++, Verilog, Lisp and, lately, Objective-C. Bad programmer! No doughnut!
lrobb 15y ago
On the list vs. set... This is an "easy" one if you just stick to the standard CS def, or you just know a language that has a clearly defined library offering that... But in PHP, there's technically no difference between a list and a set: An array in PHP is actually an ordered map. A map is a type that associates values to keys. This type is optimized for several different uses; it can be treated as an array, list (vector), hash table (an implementation of a map), dictionary, collection, stack, queue, and probably more. As array values can be other arrays, trees and multidimensional arrays are also possible.
- icebraining 15y ago
  But in PHP, there's technically no difference between a list and a set Sure there is. In a set, you can't have repeated values. PHP arrays can. Of course, you can implement a set using a PHP array.
  - lrobb 15y ago
    I'm well aware of the difference between a set and a list. My point, which was apparently lost, is that the underlying implementation of these structures is the same in PHP.
trustfundbaby 15y ago
This story is a bit embarrassing to me, but I'll tell it anyway, I went for an interview a while ago, where I got asked a basic Javascript question ... problem is, I haven't actually written actual javascript in almost 3-4 years (not simple, but not really that hard either) ... I've been writing jQuery, which is supposed to be javascript, but I digress ... I know how Javascript works, scoping, hoisting blah blah blah, but I haven't written a for loop, or used an actual getByTagName or whatever in a long long time ... I told the interviewer this, and they seemed cool with that, they asked me to write in pseudo code and I did that, then they asked me to convert it to javascript ... hunh? Well, I started going through line by line and started doing just that, asking them to refresh my memory about the syntax of stuff, even how to write a for loop (yup, its amazing what spending years using jQuery.each or $.each will do to you :P). Anyway, we concluded and though I was annoyed at how out of practice I was, I thought I did okay. Well the recruiter who set it up, called me back (very nicely I might add) and gave me the feedback on the interview. The interviewer, (who had been very nice to me too btw), had eviscerated me, writing that I displayed a lack of Javascript fundamentals ... saying I didn't even know how to write a for loop. I don't blame them, because we clearly shouldn't have been talking in the first place, they were obviously looking for a hard core Javascript guy ... and not person who could just build complex front end UIs & interactions using backbone/ember/spine/jquery/whatever, which is what I was more interested in. But it also got me thinking about how some engineers fixate on syntax, and use it in judging other programmers, and I realized that in some circumstances it is pretty appropriate. For example, if you're looking for a specialized dev, then that kind of stuff probably does matter; in that, it can help you spot a star very quickly ... but I also think that over reliance on it could let you miss out on people who could easily specialize to the level you want, but might not have that immediate level of familiarity with the language. But when you have to go through 100's of candidates, is that something you're willing to take the time to look out for? Should you? Sorry for the rambling, just been thinking about it for a long time now.
- barrkel 15y ago
  You have your specialization / generalization axis the wrong way around, I think. Knowing what a for-loop looks like in a C-derived language is correlated with broad experience; once you know it in C, you know it in Java, JavaScript, C++, C#, etc. But someone who knows primarily jQuery / backbone / ember / spine etc. is much more of a specialist, not a generalist. They have deep specific knowledge of a narrow toolset, rather than broad general knowledge of a wide toolset. That is, knowledge of language over libraries indicates generality (if you know the language and its idioms well, you should pick up most libraries fairly easily); knowledge of libraries over language indicates specialisms, because you end up a little out of your depth when not wading through the library's DSLs.
phamilton 15y ago
I think it is important for questions to be within the scope of the resume. If the applicant claims 20 years of Java only experience, throwing in a few of those questions is just a sanity check for that claim, especially if that claim is one of the reasons you are hiring them. A sportswriter who claimed an expertise in basketball wouldn't feel it unfair to be asked a few trivia questions in an interview. If he didn't know how may winning seasons the Chicago Bulls had with Michael Jordan then maybe he isn't as expert in basketball as he claims. Where these questions are unfair is when the applicant is more of a generalist. They have worked on very diverse projects in multiple paradigms and multiple languages. Their skill lies not in knowing how to use their tools, but in approaching new tools and quickly understanding how to use them. If you are a Java shop and someone comes into the interview with little Java experience then asking questions about Java specific type enforcement is going to leave them a little flustered. Cater the interview to the applicant, not necessarily to the position. Then evaluate your understanding of the applicant with respect to the position and see how well they fit.
spiralpolitik 15y ago
There seems to be trend toward ever increasing absurdity when it comes to interviewing for Software Engineers. In fact some of the recent HN posting about interview techniques are verging on being a parody of the Knights who say Ni from Monty Python and the Holy Grail ("We want you to cut down the largest tree in the forest...with a Herring !!"). As the post says find the Person who is the best fit for your team/company. Everything else can and will be learned on the job if you get the right candidate.
chimeracoder 15y ago
The real problem is what knowledge the question is supposed to test - is it testing whether you know the answer to the question, or is it testing something else altogether? Put another way, the problem is less the specificity of the questions and more the ease with which you can expect to earn them. I haven't used Swing/AWT in two years, and I couldn't really tell you what inherits from what. But after a weekend of breaking through the rust, I'd get back into it, so it's of no consequence to any potential employer. However, some language-specific questions are very telling. For example: How many arguments does type() take in Python?[1] If you answer '1' or 'either 1 or 3', that tells me two very different things about you. The latter tells me that you may understand that Python uses prototypical inheritance, rather than 'pure' class inheritance, and it tells me that you may have done a non-trivial amount of Python metaprogramming before. If you understand Python's inheritance structure in this way, you're a much more valuable candidate to some companies than you are for simply knowing syntax errors and interpreter-specific quirks... and the opposite may be true at another company). (Of course, it's possible that you know that and have simply forgotten, or were confused by the phrasing, etc. - no question is perfect, but after enough of these, you start to piece together a picture of the candidate). The point is, the former question is something that you can reasonably learn during a training period and which asks little more than face value. As for the latter question - you all know that now, so you can also learn it during a reasonable training period. But actually applying that knowledge (which comes with the followup questions) is something that would require a significant level of familiarity with the subject in question, which is what they are really trying to get at. [1]This may not be the best wording for the question, since it tips the interviewee off to the trick beforehand, but I can imagine a way to present this question so that it wouldn't.
- nachtrabe 15y ago
  My standard approach to the "determining their depth" problem is to give them a problem where detailed knowledge provides an obvious (or perhaps more elegant) answer, but there are other possible answers. For example, "how would you implement a least recently used cache in Java" can provide a wide array of answers and tells me a lot about the person's knowledge of the SDK and overall algorithm design. The details of their solution and the ensuing discussion tells me a lot more, no matter what their level, than whether they simply know that LinkedHashMap.removeEldestEntry exists.
parvinsingh 15y ago
I wonder, how would someone interview a doctor. Asking him more of theoritical questions ? Or asking him to do practicals, which I believe might be completely off the books depending on the situtation :). Anyways, there are 1) people who pass the interview very well, and cannot perform the duty on the job. 2) people who do fair on the interview, but are very well executors of the duty. 3) People who really become the backbone of the feature, and become the go to guy for everything and anything, they may or may not perform at the interview.
IanDrake 15y ago
I usually open with some nano questions. Sorry, but if you say you have 5 years of experience with C# but can't tell me which namespace List<T> or Stream or SQLDataReader is in, then we're done, because you're lying.
- henrikschroder 15y ago
  I have eight years of C# experience, and I don't really know. I think the generic list is in System.Collections.Generic or something, but no clue on the SQLDataReader. ADO something something? I don't think I've ever written an import statement by hand, it really, really isn't important to know.
  - IanDrake 15y ago
    And ya' know, that would be a fine answer, "I use resharper and haven't even had to think about that in years". I would also accept "System.Collections" as a reasonable answer. You should here some of the responses I get: What's a namespace? Uhmmm, HashTable? I don't use collections. Also, if they can't name some namespaces I'll usually ask them what classes they're familiar with for accessing a database or opening a file. If you can't name parts of the framework you use on a daily basis by namespace of class name, you're not going to be a very productive programmer. If knowing this stuff isn't important, than I'm an expert Java programmer too. I just can't name any of the packages or classes, but I can tell you all about inheritance.
    - henrikschroder 15y ago
      Fair enough. :)
blahblahhhhhh 15y ago
Great post. I felt the same way recently in a few interviews.
jebblue 15y ago
Excellent article, totally relevant, thanks.
hef19898 15y ago
Fully agree with this post, even not being a programmer 8I'm slowly asking myself why anyway...) I'm not thrilled by the prospect of answering detail questions out of my head. Things like, I already hated them back in university. Nice to check if the candidat can remember the basics, but I'd actually prefer a guy who can not only remeber them but actually use them in context. Coming more from the classical engineering fields, you don't want a guy who can write in norm script on hand written drawings, you want a guy who can use Catia (or what ever) AND can actually design good, working parts. And that actually has nothing to do with Catia skills. Nothing different to my current field in Supply Chain Management, but there I'd strongly suggest using some basic nano questions, sad as it is.

263 points by Luyt 15y ago

ExpiredLink 15y ago

I guess it's hopeless.

deleted 15y ago

[deleted]

jimbobimbo 15y ago

The article was almost good until this part: "They do not necessarily know all of the details of syntax of a given language, especially if they are used to a good IDE which does it for them..." followed by description of IDE guessing which package the class is in. Um, no. If I'm interviewing a software engineer for C# or C++ position, I'd expect them to know syntax of the language they're claiming their proficiency in. I wouldn't care if someone wouldn't remember details of standard library/framework (heck, I wouldn't even ask - this IS a stupid question), but if a person can't write 10 lines of framework-agnostic code in the language they claim they are specializing, that's the end of interview right there.

DrJokepu 15y ago

> My favorite phone interview question? “What’s your favorite language?” followed by “What are it’s weaknesses?” This is also one of my favourite questions to ask when I'm interviewing someone. Unfortunately most of the time the only response I get is confused stares. Maybe this is just a UK culture thing but it feels like many people are not prepared to display critical thinking on a job interview.

ntkachov 15y ago
Depends who you ask. Ask most people at my school and they will give you an answer of "Java". Is Java their favorite language? No. Its their only language. Also if one cannot understand the philosophy behind the language that they are using and express why they like that philosophy and what benefits it brings, they probably aren't using the language right. However, ask anyone who is great at what they do and you got yourself an hour long discussion.
- bmj 15y ago
  In my experience (on both sides of the table), it's okay to say "what are the shortcomings of language_x" if you are interviewing for a specific set of skills. If the candidate has a list of languages on their CV, then it may be worth asking the "what's your favorite language" question first.
Argorak 15y ago
Thats a great question to find newbies. It shows that the candidate has deep experience with the language or programming. As an ancodote: I was on RailsConf Berlin 2007, as a Ruby programmer with 3-4 years of Ruby experience. It was like being the grumpy old man (with 23 years :) ) in a group of young, happy and fundamentally unexperienced people. Most of them had about 6 month or less of ruby experience, they just hadn't seen the bad parts yet. I think any experienced programmer can rant for a least 5 minutes about his favorite language. Also, I think that experienced programmers can quickly find valid criticism even in languages that they don't use all day. And I think thats global. Most people aren't critics and will hop onto any prepared argument they can find. Thats why I hate most discussions about software.
djhworld 15y ago
It depends who you ask, a lot of developers out there are not polyglots and mostly (especially in the enterprise world) are good old 9-5'ers who have no interest in programming outside of work time. I've encountered many people like this. Nothing wrong with that obviously, but asking a question like "what is your favourite language" is never going to yield fair results across the board
- dsrguru 15y ago
  I think the point here is that you want to weed out such monoglots that lack a deeper understanding of CS and instead find a hacker who loves coding and has exposure to many languages, paradigms, data structures, etc. If that's your goal, wouldn't asking "what's your favorite language" yield very fair results?
  - cunac 15y ago
    Personally I would think you want somebody who can get job done instead of some ADD kid which is jumping from one hyped language de jour to other. But that is only me , YMMW
    - tikhonj 15y ago
      That is a false dichotomy--just because somebody is interested in different languages does not mean they are "some ADD kid" and, moreover, somebody exclusively working 9-5 with no particular passion to programming is probably not "somebody who can get the job done" especially if the job is non-trivial. And if you're hiring for a trivial position, optimizing your interview process is probably a waste of time anyhow.
      - onemoreact 15y ago
        It takes a long time to become a truly awesome developer. And working more than 9-5 tends to burn people out over time. Which is why I suspect most of the top programmers in the world are much closer to 9-5'er than most people on HN are willing to admit. PS: One of my favorite stories of such a person goes something like this. Coder X was fired after failing to get a 6 month project finished after a full year. Greg, took two 40 hour weeks to read the documentation and slap something together to keep the project from slipping, but made a simple mistake which ended up causing significant problems in production a few days later. After fixing the problem he asked the QA people why they put it into production that quickly while missing such a basic issue was not discovered. Their response, we stopped testing your code a few years ago and this is the first problem that's showed up. The most interesting part of this story is if Programmer X had got his code to work after say 11 month he would no have been fired. Which means the company would employ someone that's 3% as effective as this guy.
tomp 15y ago
I have seen so many programming languages that my only answer to the first question can be, "None". Haskell is too restrictive, OCaml too verbose and inflexible, Java lacks closures, Javascript has weird equality semantics, C lacks garbage collection, Python lacks static typing, Clojure has too many `)))`s, Ruby is inconsistent, ... I could go on. In the end, I just settled on a language that I have to use at work (currently Python), but I'm wishing for something better to come along...
- DrJokepu 15y ago
  You see, what you've just written down is a perfectly fine answer to the question.
- gaius 15y ago
  There are two kinds of programming languages, those that people hate, and those that no-one uses.
- Yrlec 15y ago
  You should try C#. It's like Java with closures (and some other nice features: http://stackoverflow.com/questions/610199/the-art-of-programming-java-vs-c-sharp http://stackoverflow.com/questions/610199/the-art-of-program... )
  - tomp 15y ago
    C# is one of the most interesting languages, really. It's been developing really fast, and along with F#, it shows that MS is really putting an effort into programming language progress. However, my main concern with C# is not the language, but the libraries/ecosystem. It's so tightly bound to Windows that it hurts. There are no good cross-platform implementations, poor IDE support, and I'm pretty concerned developing for a runtime that might go away... Now, if only MS would open-source their implementation, most of these arguments would become void.
    - silverlake 15y ago
      Mono is pretty good. F# also runs on the Mono runtime.
papercruncher 15y ago
Along the same lines, my favorite question is "What is your favorite data structure?". Most of the time, the answer is HashTable followed by a complete lack of understanding as to how a hash table works. Occasionally someone would respond with 'Quick Sort' Every now and then you get a candidate whose eyes lit up and you can't get them to shut up (in a good way). And that is the story about how I discovered judy arrays.
v0cab 15y ago
Perhaps the word 'limitations' might be more appropriate than 'weaknesses'? A 'weakness' implies some kind of flaw, whereas a limitation is something the language wasn't specifically designed to do or specialise in.
- scott_s 15y ago
  I think weakness is appropriate. For example, I love Python. But I only use it for automating system tasks and data post-processing. It just doesn't perform well enough for me to use it as part of the infrastructure in a high-performance system. I do consider that a flaw; it is a weakness. It is also a limitation, but when given a choice between synonyms, I prefer the stronger one.
CaptainZapp 15y ago
I was thinking about this question and agree, it's a good one. Just out of curiosity: How would you react if my answer is: Shell?
- jerf 15y ago
  Then I would hope to hear something about dangerous quoting or difficulties in abstracting things or how it affords some fairly dangerous practices and writing rock-solid shell scripts takes disproportional effort vs. other languages or possibly how it can be slow if you're not careful, though I'd consider that a last-tier objection. But it would be a bit of a bizarre choice. I would expect it only if you were coming out of a sysadmin position transitioning to a developer. (Which I've seen, so I don't mean that as some sort of implicit impossibility.)
  - CaptainZapp 15y ago
    Actually I'm coming from database programming, primarily in SQL, where scripting can add immense value to whatever you're up to. That said, I very much agree with your sentiments and it does require effort to write resilient, maintainable scripts. Nevertheless, for my day to day work it's probably the most useful "language".
- Danieru 15y ago
  I imagine he would say 'What are the weaknesses of bash scripting?'
varikin 15y ago
I love this question and have been using it lately though not tied directly to languages. It works great for frameworks and libraries (think Hibernate, Spring, etc) as well. I am uneasy about programmers who are passionate about a technology without being able to talk the problems with that technology.

dmitrykoval 15y ago

If you happen to be asked such questions it might be a good indication that the type they are looking for is code monkey. Or they are just not good enough to assess engineering skills. In both cases it's a red flag.

jimbobimbo 15y ago
Yeah, basically one should always remember that interview with a company always works both ways. It's OK to ask questions or just listen to your internal BS-o-meter while talking with company reps.

newssy 15y ago

Technically, you are just a person who converts money and coffee to code. So shut up all the whining and grow up.

staktrace 15y ago

I disagree with some parts of the post. I think good engineers have to be able to work effectively at a high "system" level of abstraction as well as at a low "compilation" level of abstraction. If you can't look at a chunk of code and know enough about the language to know that it could throw a ClassCastException, then it is quite likely that you will fall prey to other language gotchas which can bubble up and destroy the entire design of the system you're trying to build. I don't think the current state of the art in software development has yet advanced to the point where we can just black-box away all of the entire "compilation" stuff such that it never affects the "system" stuff. I really would like that to be the case, because it would eliminate a lot of unnecessary complexity in software development. I think asking a limited number of compiler-level questions (less than 5) in an interview doesn't take up a lot of time, and can allow you to get an idea of how much actual experience the candidate has with the language as well as dealing with nitty-gritty problems that come up while you're coding. The value and time spent are both small, so the value/time ratio is probably in the same ballpark as any other question you might ask.

ajuc 15y ago
I don't know. I remember problems with different classloaders, old versions of classes being deserialized, different versions of classes being sent over RMI, etc. Some of these probably resulted in ClassCastException. Some had thrown more specific Exceptions, am I supposed to remember the exact Exception that was thrown in each case? I'll probably know if you show me stacktrace. But I only know because I've encountered such problems. People working on the other end of our system would recognize different set of problems that results in this Exception or similiar. Nano questions are bad, because you are really asking if candidate has had the exact same experience that you had. Some did, some didn't, it doesn't matter. Anybody will solve the problem within minutes, most probably googling the most promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or grepping the source tree, whatever). Even auto-importing packages in IDE can cause problems - sometimes it imports from the wrong package. Is it enough reason to ask questions about "which package contains Hibernate Session class?" or even "which package contains ArrayList class?". I don't think so. Being aware of the problems good abstractions can cause (there's always a few problems) is IMHO enough, no need to remember everything you can google in 5 seconds. EDIT: or maybe you meant that you just check if people know casting can throw ClassCastException, with that I'm OK.

slavak 15y ago

I for one would be grateful if an interviewer asked me this kind of question. It gives me an instant and unambiguous indication that this is not a place I want to work, saving me a lot of wasted time - and God forbid if I'd otherwise actually ended up accepting a job there.

hashbo 15y ago
It’s usually a bad sign about the interviewer’s interviewing skills, not always them as a person or the team. I have worked for some nice, amiable smart folk who interview like crazy people. It’s the whole > IT skills < social skills thing. But I empathise - I really don’t like interviews which are like that, especially when they’re usually a game to try and make the interviewer seem smarter than the interviewee.

shimfish 15y ago

I had a company that was ready to give me a job make me take a PHP test on http://www.123assess.com http://www.123assess.com After the 10th question asking me to debug 30 lines of obfuscated code in my head while a 3 minute countdown ticked away, I called it a day and decided these were people I didn't want to work for.

deleted 15y ago

[deleted]

gbvb 15y ago

I believe Any senior engineer worth his salt should be able to do lint style verification of someone else's code quickly. When I am expecting someone to be a senior enough engineer, they should be able to look at someone's code during Code reviews and find the issues in it that can lead to problems without resorting to IDE/debugging. I do agree that nano-questions are not useful except in situations where you get a resume with keyword bonanza: You know the kind, ones with every language,OS in the first page listed so that they will pass through the corporate recruiter filter. For those, nano-questions trip up but that will give me an indication to dig a little deeper into their IDE usage pattern. If they show some proficiency in it, (for e.g., tell me the command in Eclipse to find all the references to a particular method, if the answer is search in files, .. :)).

wladimir 15y ago
If you want to someone to do lint, why not just run lint and save on an expensive hire? Code reviews are there to find problems with the code that are not found by trivial static verifiers and/or IDEs. This requires a level of understanding of the language and experience in reading (instead of writing) code, but has nothing to do with regurgitating keyword definitions. Better in that case to just give a code fragment and make them spot the (algorithmic, logic, security, not spelling) errors.
- gbvb 15y ago
  Ok. I was making a point but I guess you are right about lint. I was trying to point out that it is easy have developers write code that can easily be O(n2) vs O(n log n) because this did not use the right kind of the maps when they were initially building the code. Or I can see developers using HashTables vs HashMaps interchangeably and not see the threading impact. In these cases, some basic questions about their understanding of the classes seem to be a good indicator. Would you consider that a nano-question? I was..

dhotson 15y ago

I'm kind of on the fence on this. These questions might seem pretty lame, but as an interviewer it does tell you something about the candidate's level of experience with a language. If you've worked with a language for any decent amount of time. There are things that you really should know without having to look it up all the time. This is especially true if you mention on your resume that you're an expert at something. I'm definitely going to ask you a difficult question about it and I'll expect you to answer in some depth. If you mention you're a Java pro but can't tell me what the 'synchronized' keyword does for example. I'd be concerned.

zeru 15y ago
If you are trying to hire an "expert" and ask him questions like that, you are doing it really wrong, unless you are trying to scare him away. If anything you want to actually talk to him about what he has done, about the languages, his thoughts and passion in the subject... not ask him first programming classes in college questions. However if you are trying to hire some kind of junior-like engineer who has never had a job before, i can see why questions like this could be asked, but i still dont think it's the best way to gather knowledge about the person you are interviewings level of expertise.
- jiggy2011 15y ago
  I think these could be weeder questions for people you know little about. If you have an applicant who has a github full of great code or experience working for a good software company you can probably skip this. However if you get a candidate without much on paper but who insists they are a Java expert but doesn't know what the extends keyword does then there is something wrong somewhere. The problem with asking for definitions for words though is that I personally often forget exactly what these are if I ever learned the correct term in the first place. For example I knew how to override methods and the differences between the type system in PHP and the one in Java long before I knew what polymorphism or "dynamic typing" meant.
- dhotson 15y ago
  Don't get me wrong. I ask all those other questions as well. The problem is: people lie. It's the old thing where if you want to hire a juggler, don't you want to see them juggle?

funkah 15y ago

> Basically: Any question that takes 5 seconds to answer with Google is not a good question. Can't argue there. I haven't done a ton of interviewing in my career so far, but it is important to me to find out how the other person thinks. Being able to cite function names and package identifiers from rote is not important, at all.

Turing_Machine 15y ago
From another POV, I would argue that being able to use Google-searchable resources effectively is a very important skill that should be explored more thoroughly in the modern interview process. The examples and code snippets available on the web (e.g., Stack Overflow) can save hours and hours of time (= money), particularly when the official documentation is crappy. Coupled with that, maybe some questions would be in order about how and when you're legally allowed to use the stuff you find using Google (MIT license? GPL? Creative Commons? How do I have to attribute this stuff? Do I have to release the source?).

burke 15y ago

I'm coming at this from the perspective of someone with a pretty good memory for things like this, but those particular "nano questions" seem pretty damn fair to me. They're fundamental enough that it's not really relying on random trivia; they're testing things that you need to know 90% of the time to write a program, no?

kevingadd 15y ago
You don't need to 'know' them because you can literally find them out in 500 milliseconds. There's no value whatsoever in memorizing it. It's a useless factoid. I use C# almost every day and if you quizzed me about what namespaces certain types are in, I'd probably get it wrong. That's not because I haven't been using it regularly for years (I have), it's because that shit isn't worth wasting brain cells on. Even worse, though, the modern programmer ends up using a lot of languages. I have, in the past few years, had cause to write C#, Python, C++, C, Perl, JavaScript, ActionScript, PHP, SQL, Lua, Objective C, and Ruby. All for work. Each one has its own syntax, semantic quirks, standard library, etc. Out of all of the important things for someone to understand about a language - why would you care about something as unimportant as the exact namespace/package path of a particular type? Does that matter? Would you rather know whether I know the exact namespace Adobe's JSON parser lives in, or would you like to find out whether I'm familiar with the ins and outs of the ActionScript runtime? Honestly, if you think the kind of minutiae this article mentions is a good interview question, there's no way I'd want to work for you, because you don't care about things that matter - culture, candidates' desire and ability to learn, candidates' willingness to teach others, etc.
funkah 15y ago
I just don't know what I would stand to gain by learning that the candidate can recall from memory which package the Java List class is in. It seems pointless to ask.

edw519 15y ago

Imagine interviewing carpenters: Method 1: How many ten penny nails in a pound? Who makes better screwdrivers, Craftsman or Snap-on? Why? What's your favorite toolbox? Why? How can you tell when wood has been treated? Why should you measure twice, cut once? Which end of the hammer do you hold? Method 2: Show me something you built. Describe what you did. Cut this piece of wood according to these specs. If you needed someone to build your house, which method would you choose?

deleted 15y ago
[deleted]
moocow01 15y ago
Actually know a guy who just had to completely redo his deck because the contractor used the wrong nails on treated wood. So in that regard technicalities do have some signifigance.
- matwood 15y ago
  Method 2 would have covered it with : Show me something you built. Describe what you did. When the person describes what they did that opens up questions around materials, methods, and technicalities. Just having them tell you what a certain kind of nail is would have been useless without also demonstrating they used it properly when needed.
- brudgers 15y ago
  The fact he was using nails rather than screws for a deck should have been the first clue. But neither method would have overcome your friend's lack of expertise.
DavidWoof 15y ago
If I had to deal with the fact that 85 out of 100 applicants got the "end of the hammer" question wrong, you can bet I'd always start with method 1 just to filter out the imposters. That would free up time to correctly use the method 2 with the remaining 15 applicants.

srean 15y ago

IDE dependency? Perhaps, but that isn’t necessarily a bad thing since that is representative of the tools they will be using in the office. Mine is perhaps an unpopular view. I have come to believe that a decent programmer can and should be able to work well enough without an IDE. Presence of an IDE should be a sufficient condition not a necessary condition and I see so much of the latter. IDEs are a crutch and there is a minimum level of "walking" that I expect from you without a crutch. If you have to reach for a crutch even for the simplest tasks you will earn my suspicion that you are not as comfortable as the other guy in more complicated operations. As for the claim that IDEs are a representative tool, it need not be true, more for a start up pushing the envelope. Who knows which new or non mainstream language/technology will be most suited for the job. There may not be any mature tooling available yet. I would want my co-hacker to be able to cope. To give an example, there was this guy who claims he knows scala, but loathes working on a scala project because apparently there are no mature debugger for scala in eclipse. For him a eclipse plugin is a necessary condition. I have seen too many programmers who program in the following mode - let me type something in the IDE. No errors detected ?, good. Let me test it on a few cases. Didn't work ? let me bump up the loop bound by one, no cookie ? let me decrement it by 2, didnt work, let me change the sign of this expression from positive to negative -...ad infinitum. I am more scared when such a code passes a few half assed test cases and the author cannot explain why the fix works. I am not saying IDE are universally bad, quite the contrary. I advocate IDEs, but under two scenarios - (i) you are learning a new language (ii) you are an expert in that language. It is the overly populated middle ground, where it is used as a substitute for (a) thinking about your code or (b) knowing the language, that worries me.

pnathan 15y ago
If you have to use an IDE to program, you're not programming in the language, you're programming the IDE. There are many times I have to log into remote systems and all I have are nano or vi. Not even emacs. If I have IDE-dependancy, I'm up a creek without a paddle.
- eropple 15y ago
  If you're hot-patching code in a remote environment, you have much bigger problems than "I don't have an IDE!". I use an IDE--and for many languages, ex. Java, Scala, and C#, would say I have to--because my time is worth something to me.

phatbyte 15y ago

To me, a perfect interview would be: "Here's a coding challenge, go home, write the code to solve this, come back tomorrow and tell me three things: - How you did it, - Why you pick this solution, - How it could be improved" by doing this I could see how he writes code, if he's just a google copy&paster, and what's his skills in algorithm optimization etc...and specially, how he/she thinks. Quite frankly I don't care if someone doesn't know what Polymorphism is right from his head. I didn't knew what polymorphism was until a few months ago, and yet I was applying the same principles in a lot places in my code. That's the downside of being a self-taught you don't get to know a lot of theory, but on my work I know I'm doing it right. (Also because polymorphism is a very abstract thing to be honest....) In a nutshell, get developers who can show you their code and can it explain it, don't rely on theory, you are not hiring a college professor.

raganwald 15y ago

I’m going to take the incredibly unpopular stance that nano-questions are not considered harmful. It’s true that only asking nano-questions, or emphasizing them, or thinking that a good engineer must necessarily be able to answer all of the nano-questions perfectly are all broken ways of thinking. But I look upon them as a kind of FizzBuzz. I know for a fact that while you can look them up in Google in 500 nanoseconds, experienced people doing hands-on work are going to be able to answer 2/3 nano-questions instantly. A few such questions sprinkled in the opening part of the interview are useful for weeding out the AbstractArchitectureAstronautFactoryFactories from the Programmers. I’m not talking about esoterica, e.g. “What is protected inheritance in C++?” Lots of practitioners might say, correctly, that they never use it and can easily look it up if you need to know how it works. And sometimes answering esoterica correctly has negative correlation: You end up hiring people who are SmartButTooBusyPlayingWithCoolIdeasToGetStuffDone (I’m a prize example of this). But if a programmer says he’s working with jQuery and I ask him to explain the difference between $(‘.foo.bar’), $(‘.foo,.bar’) and $(‘.foo .bar’), I don’t want to hear from him that he can look it up on the Internet, a jQuery programmer knows the answer. It’s acceptable for someone to say, “I don’t know jQuery, but I’m a smart guy, I can figure it out on the job by looking stuff up,” but if he says he’s been using it to build awesome HTML5 applications, I want to ask a few of these questions to make sure that I’m interviewing the person described on the resumé. A working programmer will know the answer to all of them, they shouldn’t be hard. Interview pressure will cause some fuzz, so I don’t expect perfect, maybe get 2/3 or 3/5 right and then we can talk about composition vs. inheritance or whatever other pet “Start a conversation with a smart person” question. I want to be incredibly clear about this: I don’t think that there is some strong correlation between memorizing things and being a good programmer. I don’t think programmers should rush out and memorize trivia just to “pass” an interview. I look stuff up all the time in my job. But I do think that if the questions are easy and obvious to the working programmer, a few of them are an appropriate FizzBuzz for weeding out the folks who have falsified their hands-on experience. By and large, interview questions are a touchy subject because they serve as a kind of metric for valuing people. So when I say I think it’s cool to ask a few of these questions, some folks are going to think that I say that I measure their worth by whether they know a handful of bits of information. That’s not the case. I’m not saying you’re unworthy if you don’t memorize things. But I am saying that if you claim to have a certain type of experience, there are some questions that are going to be dead easy for you to answer, and those questions are going to help us get to the good part of the interview very quickly. p.s. List vs Set is a funny question. I can’t imagine anyone with a degree being ignorant of the difference regardless of the programming language! It’s also a good lead-in to a more experiential question: “Okay, can you describe a time you’ve used a set of some kind? What were you trying to accomplish? ..."

XcodeNoob 15y ago

So an interviewer asked dumb questions, and sometimes they get my orders wrong at McDonalds. NEXT.

deleted 15y ago

[deleted]

jussij 15y ago

This is why as a 20 year veteran of Windows C/C++ programmer I no longer bother applying for C/C++ software development contracts. I really don't give a stuff that your Boost/STL trick question is missing a semi colon, which in reality would result in pages and pages of false compiler error messages. I really don't want to try an second guess the compiler and tell you where the missing semi colon should go. I use the compiler to detect my mistakes. I read the compiler output error messages, understand the message and fix my mistakes. But I don't pretend to be a compiler. I'm a software developer. I use the tools available to me to write software.

qwe123_troll 15y ago
There is no such language as "C/C++". In fact, when I interview programmers, saying that you program "C/C++" is an immediate red card and a thank-you-we-will-contact-you-later.

robomartin 15y ago

"A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language" Precisely. I'll take someone who can think this way before someone who can rattle-off all of the minutiae about a particular language. I've run across too many programmers who don't have a clue about project organization, MVC, data representation, optimization, etc. Yet, they can pass minutiae-filled tests about a particular language. Unless you've been programming in a single language for an extended period of time you will not have encyclopedic knowledge about that language and its libraries. Get 15 to 20 languages under your belt and the effect is more pronounced. I know exactly what it takes to write a number of sort algorithms, genetic solvers, neural networks, real-time embedded OS and more. No, I can't rattle off exactly how to write it in the language of the day. When switching to a language I haven't touched for a while it takes me two to four weeks to "task switch". I surround myself with reference books, use the IDE and any available online resource. Somewhere during that period I start to rock. I get the job done and produce clean and efficient code, fast. I would probably fail the kind of questioning the article describes. Yet I've been solely responsible for large projects using languages spanning from assembler to Forth, C, C++, Verilog, Lisp and, lately, Objective-C. Bad programmer! No doughnut!

lrobb 15y ago

On the list vs. set... This is an "easy" one if you just stick to the standard CS def, or you just know a language that has a clearly defined library offering that... But in PHP, there's technically no difference between a list and a set: An array in PHP is actually an ordered map. A map is a type that associates values to keys. This type is optimized for several different uses; it can be treated as an array, list (vector), hash table (an implementation of a map), dictionary, collection, stack, queue, and probably more. As array values can be other arrays, trees and multidimensional arrays are also possible.

icebraining 15y ago
But in PHP, there's technically no difference between a list and a set Sure there is. In a set, you can't have repeated values. PHP arrays can. Of course, you can implement a set using a PHP array.
- lrobb 15y ago
  I'm well aware of the difference between a set and a list. My point, which was apparently lost, is that the underlying implementation of these structures is the same in PHP.

trustfundbaby 15y ago

This story is a bit embarrassing to me, but I'll tell it anyway, I went for an interview a while ago, where I got asked a basic Javascript question ... problem is, I haven't actually written actual javascript in almost 3-4 years (not simple, but not really that hard either) ... I've been writing jQuery, which is supposed to be javascript, but I digress ... I know how Javascript works, scoping, hoisting blah blah blah, but I haven't written a for loop, or used an actual getByTagName or whatever in a long long time ... I told the interviewer this, and they seemed cool with that, they asked me to write in pseudo code and I did that, then they asked me to convert it to javascript ... hunh? Well, I started going through line by line and started doing just that, asking them to refresh my memory about the syntax of stuff, even how to write a for loop (yup, its amazing what spending years using jQuery.each or $.each will do to you :P). Anyway, we concluded and though I was annoyed at how out of practice I was, I thought I did okay. Well the recruiter who set it up, called me back (very nicely I might add) and gave me the feedback on the interview. The interviewer, (who had been very nice to me too btw), had eviscerated me, writing that I displayed a lack of Javascript fundamentals ... saying I didn't even know how to write a for loop. I don't blame them, because we clearly shouldn't have been talking in the first place, they were obviously looking for a hard core Javascript guy ... and not person who could just build complex front end UIs & interactions using backbone/ember/spine/jquery/whatever, which is what I was more interested in. But it also got me thinking about how some engineers fixate on syntax, and use it in judging other programmers, and I realized that in some circumstances it is pretty appropriate. For example, if you're looking for a specialized dev, then that kind of stuff probably does matter; in that, it can help you spot a star very quickly ... but I also think that over reliance on it could let you miss out on people who could easily specialize to the level you want, but might not have that immediate level of familiarity with the language. But when you have to go through 100's of candidates, is that something you're willing to take the time to look out for? Should you? Sorry for the rambling, just been thinking about it for a long time now.

barrkel 15y ago
You have your specialization / generalization axis the wrong way around, I think. Knowing what a for-loop looks like in a C-derived language is correlated with broad experience; once you know it in C, you know it in Java, JavaScript, C++, C#, etc. But someone who knows primarily jQuery / backbone / ember / spine etc. is much more of a specialist, not a generalist. They have deep specific knowledge of a narrow toolset, rather than broad general knowledge of a wide toolset. That is, knowledge of language over libraries indicates generality (if you know the language and its idioms well, you should pick up most libraries fairly easily); knowledge of libraries over language indicates specialisms, because you end up a little out of your depth when not wading through the library's DSLs.

phamilton 15y ago

I think it is important for questions to be within the scope of the resume. If the applicant claims 20 years of Java only experience, throwing in a few of those questions is just a sanity check for that claim, especially if that claim is one of the reasons you are hiring them. A sportswriter who claimed an expertise in basketball wouldn't feel it unfair to be asked a few trivia questions in an interview. If he didn't know how may winning seasons the Chicago Bulls had with Michael Jordan then maybe he isn't as expert in basketball as he claims. Where these questions are unfair is when the applicant is more of a generalist. They have worked on very diverse projects in multiple paradigms and multiple languages. Their skill lies not in knowing how to use their tools, but in approaching new tools and quickly understanding how to use them. If you are a Java shop and someone comes into the interview with little Java experience then asking questions about Java specific type enforcement is going to leave them a little flustered. Cater the interview to the applicant, not necessarily to the position. Then evaluate your understanding of the applicant with respect to the position and see how well they fit.

spiralpolitik 15y ago

There seems to be trend toward ever increasing absurdity when it comes to interviewing for Software Engineers. In fact some of the recent HN posting about interview techniques are verging on being a parody of the Knights who say Ni from Monty Python and the Holy Grail ("We want you to cut down the largest tree in the forest...with a Herring !!"). As the post says find the Person who is the best fit for your team/company. Everything else can and will be learned on the job if you get the right candidate.

chimeracoder 15y ago

The real problem is what knowledge the question is supposed to test - is it testing whether you know the answer to the question, or is it testing something else altogether? Put another way, the problem is less the specificity of the questions and more the ease with which you can expect to earn them. I haven't used Swing/AWT in two years, and I couldn't really tell you what inherits from what. But after a weekend of breaking through the rust, I'd get back into it, so it's of no consequence to any potential employer. However, some language-specific questions are very telling. For example: How many arguments does type() take in Python?[1] If you answer '1' or 'either 1 or 3', that tells me two very different things about you. The latter tells me that you may understand that Python uses prototypical inheritance, rather than 'pure' class inheritance, and it tells me that you may have done a non-trivial amount of Python metaprogramming before. If you understand Python's inheritance structure in this way, you're a much more valuable candidate to some companies than you are for simply knowing syntax errors and interpreter-specific quirks... and the opposite may be true at another company). (Of course, it's possible that you know that and have simply forgotten, or were confused by the phrasing, etc. - no question is perfect, but after enough of these, you start to piece together a picture of the candidate). The point is, the former question is something that you can reasonably learn during a training period and which asks little more than face value. As for the latter question - you all know that now, so you can also learn it during a reasonable training period. But actually applying that knowledge (which comes with the followup questions) is something that would require a significant level of familiarity with the subject in question, which is what they are really trying to get at. [1]This may not be the best wording for the question, since it tips the interviewee off to the trick beforehand, but I can imagine a way to present this question so that it wouldn't.

nachtrabe 15y ago
My standard approach to the "determining their depth" problem is to give them a problem where detailed knowledge provides an obvious (or perhaps more elegant) answer, but there are other possible answers. For example, "how would you implement a least recently used cache in Java" can provide a wide array of answers and tells me a lot about the person's knowledge of the SDK and overall algorithm design. The details of their solution and the ensuing discussion tells me a lot more, no matter what their level, than whether they simply know that LinkedHashMap.removeEldestEntry exists.

parvinsingh 15y ago

I wonder, how would someone interview a doctor. Asking him more of theoritical questions ? Or asking him to do practicals, which I believe might be completely off the books depending on the situtation :). Anyways, there are 1) people who pass the interview very well, and cannot perform the duty on the job. 2) people who do fair on the interview, but are very well executors of the duty. 3) People who really become the backbone of the feature, and become the go to guy for everything and anything, they may or may not perform at the interview.

IanDrake 15y ago

I usually open with some nano questions. Sorry, but if you say you have 5 years of experience with C# but can't tell me which namespace List<T> or Stream or SQLDataReader is in, then we're done, because you're lying.

henrikschroder 15y ago
I have eight years of C# experience, and I don't really know. I think the generic list is in System.Collections.Generic or something, but no clue on the SQLDataReader. ADO something something? I don't think I've ever written an import statement by hand, it really, really isn't important to know.
- IanDrake 15y ago
  And ya' know, that would be a fine answer, "I use resharper and haven't even had to think about that in years". I would also accept "System.Collections" as a reasonable answer. You should here some of the responses I get: What's a namespace? Uhmmm, HashTable? I don't use collections. Also, if they can't name some namespaces I'll usually ask them what classes they're familiar with for accessing a database or opening a file. If you can't name parts of the framework you use on a daily basis by namespace of class name, you're not going to be a very productive programmer. If knowing this stuff isn't important, than I'm an expert Java programmer too. I just can't name any of the packages or classes, but I can tell you all about inheritance.
  - henrikschroder 15y ago
    Fair enough. :)

blahblahhhhhh 15y ago

Great post. I felt the same way recently in a few interviews.

jebblue 15y ago

Excellent article, totally relevant, thanks.

hef19898 15y ago

Fully agree with this post, even not being a programmer 8I'm slowly asking myself why anyway...) I'm not thrilled by the prospect of answering detail questions out of my head. Things like, I already hated them back in university. Nice to check if the candidat can remember the basics, but I'd actually prefer a guy who can not only remeber them but actually use them in context. Coming more from the classical engineering fields, you don't want a guy who can write in norm script on hand written drawings, you want a guy who can use Catia (or what ever) AND can actually design good, working parts. And that actually has nothing to do with Catia skills. Nothing different to my current field in Supply Chain Management, but there I'd strongly suggest using some basic nano questions, sad as it is.