Recommendations for interview questions



  • I'm curious what interview questions you here at DailyWTF ask prospective new hires. I've got a couple of books that have good questions, like "Cracking the Coding Interview", but I've found that people on both sides of the interview have that book so they know what to expect.


  • SockDev

    • Variation on fizzbuzz for a coding interview
      • Tests how they think and code using quite possibly the simplest non-trivial problem possible
    • Whiteboard an inventory system for a supermarket including inventory, stock, and sales transactions
      • Then add on coupon discounts to be tracked as well to see how they change their design to cope.
    • "Your house is on fire, What is the first thing you take out?"
      • To test their reactions to the unexpected.
      • Followup: "Why?"
      • Alternate question. "Damn, I'm fresh out of gum. Follow me down to CVS to grab some more and we'll continue the interview as we walk?"
    • "What is an example of a time you failed on the job and what did you do to cause the failure?"
      • Call bullshit if they say they never failed. Everyone fails occasionally.
    • "What is an example of at time where you helped a coworker succeed when they had bitten off more than they could chew?"
      • Look for them to make the story about the situation, if they make themselves look good to the detriment of their coworker...... yeah.


  • @accalia said in Recommendations for interview questions:

    Whiteboard

    I don't know what this is but I see a lot of posts condemning it as some scary thing you don't want to have happen in an interview. If it has anything to do with handwriting, I'd fail.



  • @thebread I don't like questions. I like conversations.

    Find something interesting on their resume and start a conversation about it. Ask questions yourself. Just be a normal human being talking to another human being instead of it being some kind of horrible 19th century university oral exam.

    (Unless you're talking about coding questions specifically, I have a few good ones of those.)



  • I asked that question 2 years ago and got some pretty good suggestions.

    https://what.thedailywtf.com/topic/12999/1-hour-to-test-intern-s-mettle



  • I divide them into personality and technical.d

    Personality

    Make sure the guy isn't a belligerent asshole who will bring down team morale. "Describe a project you are most proud of" can offer some insights into whether they are a team player or an egotistical asshole who has a superiority complex. It's a boilerplate question, but I've found that a lot of assholes answer this wrong. I even had someone who answered with something along the lines of, "They were all doing it the wrong way and so I undermined them by going rogue and saved the day." That's someone you don't ever want on your team, especially if they were proud of that accomplishment enough to answer your question with that. This can even work for entry-levels, at least those who went through college, since they've worked on class projects.

    Technical

    I don't like fizzbuzz. Reason being, it's way too easy to just dump boilerplate code from past trials. The thing to understand is the worst candidates are also the best interviewers because they've had much experience interviewing. These folks have already seen fizzbuzz multiple times in their career, and have mastered it to the point where they can recite it without even thinking about it.

    Instead, I simply look through known coding examples on the Internet and cross them out as "done before." IMO it's easy to just come up with an exercise of yourself that lets someone illustrate their coding approach. The coding exercise I compose touches on some fundamental concepts:

    • Sorting
    • Filtering
    • Basic arithmetic
    • Use of classes

    The people who have mastered fizzbuzz by etching it into memory will not be able to surpass anything that they haven't come across already. I allow google for reference, and encourage use of whatever tools they'd be using on the job, since that's what I'm testing for. If 99% of their approach involves blindly copy-pasting from SO questions without thinking about it, that tells me far more about their skills than anything else.


  • SockDev

    @lb_ said in Recommendations for interview questions:

    @accalia said in Recommendations for interview questions:

    Whiteboard

    I don't know what this is but I see a lot of posts condemning it as some scary thing you don't want to have happen in an interview. If it has anything to do with handwriting, I'd fail.

    handwriting is involved but what i want to see is your thought process. what you draw on the whiteboard could be a loving rendition of dickbutt for all i care. πŸ˜›


  • Impossible Mission - B

    @lb_ said in Recommendations for interview questions:

    I don't know what this is but I see a lot of posts condemning it as some scary thing you don't want to have happen in an interview. If it has anything to do with handwriting, I'd fail.

    Yes, it's exactly what it sounds like, and just as stupid and irrelevant.


  • Impossible Mission - B

    @accalia said in Recommendations for interview questions:

    handwriting is involved but what i want to see is your thought process.

    Then have them code something--at a real computer--and look over their shoulder as they do so. That's infinitely less stressful, useless, and irrelevant than making them use a whiteboard.


  • SockDev

    Why are developers afraid of picking up a pen? πŸ˜›


  • SockDev

    @masonwheeler said in Recommendations for interview questions:

    @accalia said in Recommendations for interview questions:

    handwriting is involved but what i want to see is your thought process.

    Then have them code something--at a real computer--and look over their shoulder as they do so. That's infinitely less stressful, useless, and irrelevant than making them use a whiteboard.

    You mean i shouldn't ask you as a job applicant to use a whiteboard to design a system, such as you would do in a meeting with your coworkers when you're spitballing solutions during the early phases of problem solving as a way to figure out how you approach problem solving?

    bull shit.

    imma ask you the question because i want to see you think.

    now if i was asking you to write code that would be a different issue, but no. i'm asking you to scratch boxes and a couple of labels and some arrows to illustrate a thought process in a way you would actually do in the course of your actual jorb.

    so yeah, imma keep my whiteboard question and i will assume the worst if you refuse to answer the question.

    0_1502401305214_giphy (2).gif



  • @the_quiet_one said in Recommendations for interview questions:

    The coding exercise I compose touches on some fundamental concepts:

    Sorting
    Filtering
    Basic arithmetic
    Use of classes

    Just admit that you lifted @cartman82's fruit one. We won't judge you.

    @masonwheeler said in Recommendations for interview questions:

    @accalia said in Recommendations for interview questions:

    handwriting is involved but what i want to see is your thought process.

    Then have them code something--at a real computer--and look over their shoulder as they do so. That's infinitely less stressful, useless, and irrelevant than making them use a whiteboard.

    I understood @accalia's "whiteboarding" to mean "explain the architecture of the system and draw a diagram of it" - so more of a "big picture" thing and one where a whiteboard is pretty useful. Definitely more useful than any diagramming tool available. Seriously. They all suck.


  • SockDev

    @masonwheeler said in Recommendations for interview questions:

    @accalia said in Recommendations for interview questions:

    handwriting is involved but what i want to see is your thought process.

    Then have them code something--at a real computer--and look over their shoulder as they do so. That's infinitely less stressful, useless, and irrelevant than making them use a whiteboard.

    I understood @accalia's "whiteboarding" to mean "explain the architecture of the system and draw a diagram of it" - so more of a "big picture" thing and one where a whiteboard is pretty useful. Definitely more useful than any diagramming tool available. Seriously. They all suck.

    By Jingo, I think He's got it!!

    0_1502401429193_ce86bd08-6503-4764-aa4c-c248f356c918-image.png

    Give the man a cookie!~


  • Impossible Mission - B

    @accalia said in Recommendations for interview questions:

    You mean i shouldn't ask you as a job applicant to use a whiteboard to design a system, such as you would do in a meeting with your coworkers when you're spitballing solutions during the early phases of problem solving as a way to figure out how you approach problem solving?

    There's a massive assumption in there that is completely incorrect. Never in my entire career have I done that. No one's ever even suggested it as an idea of something we would want to do.

    imma ask you the question because i want to see you think.

    now if i was asking you to write code that would be a different issue, but no. i'm asking you to scratch boxes and a couple of labels and some arrows to illustrate a thought process in a way you would actually do in the course of your actual jorb.

    undefined I don't draw boxes and arrows in my actual job. (Do you? Seriously?) I work out the problem, sometimes opening up Notepad to jot down a few ideas in order to keep things straight or help analyze ideas. Then I pull up an editor and start coding, compiling and running along the way to double-check the validity of those ideas, and adjust as necessary.


  • SockDev

    @masonwheeler said in Recommendations for interview questions:

    There's a massive assumption in there that is completely incorrect. Never in my entire career have I done that. No one's ever even suggested it as an idea of something we would want to do.

    So, because you've never used a whiteboard, no developer has ever used a whiteboard?

    And you accuse others of bullshit…



  • @masonwheeler said in Recommendations for interview questions:

    I don't draw boxes and arrows in my actual job. (Do you? Seriously?)

    Not as formal documentation, but if you have a complex task at hand then it's good to visualize while you're brainstorming. Things like "okay, so there's this flat file drop, and the service here validates and carries those files to the mediation zone, where they're picked up by the importer and stuffed into the DB, so we need our data layer to access that DB..." - even if you can keep it all in your head, your coworkers will probably doze off if you just say words at them. And unless you're a trainee or have your hands tied with red tape, you generally do need to know and often design more than just your immediate class diagram.



  • @masonwheeler

    What kind of environment are you working in where you:
    a) don't have a project large enough to warrant drawing it out?
    b) don't have a boss (or higher) who expects a picture to explain what you are going to do?
    c) a formal process where you have to justify/explain what you are going to do before they allow you do to it?



  • And again, we're talking big picture here. Of course you don't need to draw a detailed UML class or entity diagram before you start coding. But I'd expect the developer to be able to at least lay out the application layers and the general flow of the process.

    In my experience, the laudable goal of "just coding" means about 10% chance that the developer has a general goal in mind and just prefers to keep it in their head - and 90% chance that they'll just be making shit up as they go along, the code growing little architectural warts and failed ideas that are then impossible to backtrack on without wasting a significant amount of time.



  • @raceprouk said in Recommendations for interview questions:

    Why are developers afraid of picking up a pen? πŸ˜›

    Because most developers are lefties, but society forced us to be righties, thus causing awful handwriting.


  • Dupa

    @dangeruss said in Recommendations for interview questions:

    @raceprouk said in Recommendations for interview questions:

    Why are developers afraid of picking up a pen? πŸ˜›

    Because most developers are lefties, but society forced us to be righties, thus causing awful handwriting.

    So what you're saying is that @boomzilla is a lefty? Hah!



  • @raceprouk said in Recommendations for interview questions:

    Why are developers afraid of picking up a pen? πŸ˜›

    I am not afraid of the pen, I just know that nobody (even myself) will likely be able to read what I wrote.



  • @dragoon said in Recommendations for interview questions:

    @raceprouk said in Recommendations for interview questions:

    Why are developers afraid of picking up a pen? πŸ˜›

    I am not afraid of the pen, I just know that nobody (even myself) will likely be able to read what I wrote.

    So were you born a leftie?


  • Impossible Mission - B

    @dragoon said in Recommendations for interview questions:

    @masonwheeler

    What kind of environment are you working in where you:
    a) don't have a project large enough to warrant drawing it out?

    Every environment ever. Large projects are documented with words and specifications.

    b) don't have a boss (or higher) who expects a picture to explain what you are going to do?

    undefined undefined undefined

    Ye canna be serious...

    c) a formal process where you have to justify/explain what you are going to do before they allow you do to it?

    Again, this is what specs are for.


  • β™Ώ

    @masonwheeler said in Recommendations for interview questions:

    @accalia said in Recommendations for interview questions:

    handwriting is involved but what i want to see is your thought process.

    Then have them code something--at a real computer--and look over their shoulder as they do so. That's infinitely less stressful, useless, and irrelevant than making them use a whiteboard.

    This seems backwards to me.



  • @masonwheeler said in Recommendations for interview questions:

    Every environment ever. Large projects are documented with words and specifications.

    And those don't come on stone tablets from the sky. Before you have your architectural or business process spec, someone has to write it, and before they can write it, they have to figure it out somehow.

    Besides, would you rather read this:

    @maciejasjmj said in Recommendations for interview questions:

    okay, so there's this flat file drop, and the service here validates and carries those files to the mediation zone, where they're picked up by the importer and stuffed into the DB, so we need our data layer to access that DB...

    (except in 10 times more words), or see this:

    0_1502405451900_71366cb4-07cf-4b6d-8fa2-712e4a52eb3e-image.png

    if you're just getting started with the project and need an overwiew of how it's actually doing things? Sure the diagram is not complete, and you won't know, say, how the import to the DB is done in detail, but you can already notice that - say - there's no need to have a filesystem change listener involved with the DB import when the staging area is only filled nightly anyway. Stick to the spec like it's a holy book, and you need to maintain a more complicated mechanism that isn't even necessary.


  • BINNED

    White-board, algorithm. No personality test, leave that to the next interviewer with more peoples-skills than a blakeyrat. Like a πŸ€–


  • SockDev

    @masonwheeler said in Recommendations for interview questions:

    Again, this is what specs are for.

    Yes, because what the marketing, sales, and accounts people just love to see is technical specs undefined



  • @the_quiet_one said in Recommendations for interview questions:

    These folks have already seen fizzbuzz multiple times in their career, and have mastered it to the point where they can recite it without even thinking about it.

    This is the reason that I hate people posting interview questions.

    I'll have to make sure the questions I ask are at least not the common ones.

    That means sometimes the question that I use would be... a bit strange and non-sense to the interviewer (make them ask "what's the point of doing that" or "why would ever anyone need to do that") and therefore makes me violates one rule in the designing the interview questions - test everyday problems, not something you make up for the sake of testing.



  • @cheong said in Recommendations for interview questions:

    That means sometimes the question that I use would be... a bit strange and non-sense to the interviewer (make them ask "what's the point of doing that" or "why would ever anyone need to do that") and therefore makes me violates one rule in the designing the interview questions - test everyday problems, not something you make up for the sake of testing.

    Well, it's not like fizzbuzz is something you'd ever actually use, anyways.

    But, seriously, there's an infinite number of interview questions that are realistic and a good gauge to determine one's skill. I mean, it's our day-to-day jobs, for cripes sake. In fact, a lot of the "common" interview questions, like fizzbuzz, Fibonacci, finding if a string is an anagram of another, etc. aren't at all practical.



  • @masonwheeler said in Recommendations for interview questions:

    undefined I don't draw boxes and arrows in my actual job. (Do you? Seriously?)

    Lol, you sound like those pointy haired bosses who walks into a room during a session like this and saying, "quit playing, it looks like you're just making pretty drawings. Get to work."

    Have you ever actually built a large-scale application from the ground up? Because that's where the arrows and boxes actually come in handy, whether it's for DB schemas or architecture. I haven't done it in years because the project I've been working on has reached a level of maturity where it's no longer necessary, but it certainly did help in the early stages of building it.


  • Impossible Mission - B

    @the_quiet_one said in Recommendations for interview questions:

    Have you ever actually built a large-scale application from the ground up?

    No, I've generally worked on mature products.

    But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway! That's what you have PMs for. If someone's trying to get me to write specs, something's gone very wrong somewhere.



  • @masonwheeler said in Recommendations for interview questions:

    @accalia said in Recommendations for interview questions:

    You mean i shouldn't ask you as a job applicant to use a whiteboard to design a system, such as you would do in a meeting with your coworkers when you're spitballing solutions during the early phases of problem solving as a way to figure out how you approach problem solving?

    There's a massive assumption in there that is completely incorrect. Never in my entire career have I done that. No one's ever even suggested it as an idea of something we would want to do.

    imma ask you the question because i want to see you think.

    now if i was asking you to write code that would be a different issue, but no. i'm asking you to scratch boxes and a couple of labels and some arrows to illustrate a thought process in a way you would actually do in the course of your actual jorb.

    undefined I don't draw boxes and arrows in my actual job. (Do you? Seriously?) I work out the problem, sometimes opening up Notepad to jot down a few ideas in order to keep things straight or help analyze ideas. Then I pull up an editor and start coding, compiling and running along the way to double-check the validity of those ideas, and adjust as necessary.

    This is an excellent example of the difference between a software engineer and a programmer.


  • SockDev

    @masonwheeler said in Recommendations for interview questions:

    But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway! That's what you have PMs for. If someone's trying to get me to write specs, something's gone very wrong somewhere.

    You've just lost any right to call yourself a developer. At best, you're a code-monkey, and an arrogant little shit of one at that.



  • @masonwheeler said in Recommendations for interview questions:

    But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway!

    Functional spec - maybe not, though it depends on the project (in mine, developers are in contact with the client and we often go through things with them). But even if actually drafting a spec is the product owner's job, you as a developer should still be able to comprehend it and plot it out - if only so that during brainstorming you have something to point to. I'd be scared to work on a project where the developers don't know, or don't care, what the entire product is going to do and are just concerned about their tiny slice of the system.

    Architectural spec, though? The interactions between the systems? Many projects are small enough not to have a dedicated architect, and those that do generally have the architect work things out with the developers instead of showing up and saying "do things this way" without concern as to whether it's even going to be possible to make.

    And even if you want to fully separate the duties and have the developers do nothing but write code, is there never any brainstorming between developers where you're trying to figure out how to make feature X work and which components are going to be needed? Do the developers at your company just get instructions from above and are relegated to be code monkeys filling in the blanks?


  • SockDev

    @masonwheeler if I build a ne system from scratch, the spec doesn't cover architecture, because user stories don't ever cover how it is built, merely how it should work, and there is a gulf between these things.

    However, if you only ever touch mature stuff, I can see how you would, wrongly, assume that everyone else has an experience like you.

    Also, not everyone thinks the same way you do, some people prefer diagrams rather than dry tech specs, but again, you wrongly conflate yourself with everyone else.



  • @maciejasjmj said in Recommendations for interview questions:

    Besides, would you rather read this:

    @maciejasjmj said in Recommendations for interview questions:

    okay, so there's this flat file drop, and the service here validates and carries those files to the mediation zone, where they're picked up by the importer and stuffed into the DB, so we need our data layer to access that DB...

    (except in 10 times more words), or see this:

    0_1502405451900_71366cb4-07cf-4b6d-8fa2-712e4a52eb3e-image.png

    I'd probably prefer the text version...

    I think that part of the disconnect in this discussion is that people vary hugely in how they think.

    I'm probably at the extreme non-visual end of the range - if I'm designing something I'll scrawl pages and pages of written notes for myself, probably without any diagrams whatsoever.

    I used to share an office with a guy who scribbled diagrams everywhere (usually in dry marker all over the windows) - even for trivial concepts that I wouldn't even have written down. His diagrams usually added nothing to my understanding and, conversely, my written notes meant nothing to him until he transformed them into pointless boxes...

    If I was @accalia's interviewee (which would be terrifying) then I could talk the hind leg off a donkey in the white-boarding task, but most likely wouldn't touch the board. (might write things on it, but if I tried to do a diagram it probably wouldn't make sense to anyone)



  • It might be worth trying a question about the internals of whatever language/system is relevant.

    Not to expect the candidate to be able to, say, explain exactly how MSIL functions but to have domain-specific knowledge beyond just using the whatever-it-is.

    Might help weed out people who have little interest beyond code=job.


  • kills Dumbledore

    @cursorkeys Something like how you'd optimise a method that appends to a string in a loop, which could lead to follow up questions on how a stringbuilder works and why it's better


  • Impossible Mission - B

    @raceprouk said in Recommendations for interview questions:

    You've just lost any right to call yourself a developer. At best, you're a code-monkey, and an arrogant little shit of one at that.

    undefined So it's "arrogant" to be a specialist who is really good at doing a particular thing, and knows his limitations well enough to leave other things he's not good at to those who specialize in doing those things instead of trying to insist he can do all that other stuff too?

    Funny, that really sounds like the exact opposite of "arrogant" to me...


  • SockDev

    @masonwheeler It's arrogant for you to think you know better than those who have several years more experience than you. It's even more arrogant to think that your experiences are the only ones that matter.



  • @masonwheeler said in Recommendations for interview questions:

    So it's "arrogant" to be a specialist who is really good at doing a particular thing, and knows his limitations well enough to leave other things he's not good at to those who specialize in doing those things instead of trying to insist he can do all that other stuff too?

    There's a thin line between a developer who knows their limitations and knows when to delegate, and one that throws their hands up in the air and loudly proclaims "not my job!" when faced with anything that's outside the scope of writing code strictly to spec.


  • SockDev

    @maciejasjmj and a developer who assumes everyone thinks the same way they do about everything...


  • β™Ώ

    @masonwheeler said in Recommendations for interview questions:

    But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway! That's what you have PMs for. If someone's trying to get me to write specs, something's gone very wrong somewhere.

    Oh, god, the absolute last thing you want is for a PM to do anything technical.

    I mean, fine, you're a junior guy, and want to stay that way. No problem.


  • β™Ώ

    @arantor said in Recommendations for interview questions:

    Also, not everyone thinks the same way you do, some people prefer diagrams rather than dry tech specs, but again, you wrongly conflate yourself with everyone else.

    There's also the situation of getting down to business and figuring out an implementation in someone's office or whatever, where there's 2 or 3 of you and you're plotting out how stuff will work and drawing on a whiteboard to facilitate the discussion and document what you're doing.

    If it's not part of a developer's job to plan implementation then...:headasplodes.sp:


  • Impossible Mission - B

    @boomzilla said in Recommendations for interview questions:

    Oh, god, the absolute last thing you want is for a PM to do anything technical.

    Uhh... what sort of PMs do you work with?

    I mean, fine, you're a junior guy, and want to stay that way. No problem.

    ???


  • β™Ώ

    @masonwheeler said in Recommendations for interview questions:

    I don't draw boxes and arrows in my actual job. (Do you? Seriously?)

    Er - yes. Cylinders too.

    One from ages ago from a discussion about what currently happens and what would need to change:

    0_1502459123669_whiteboard.png


    @the_quiet_one said in Recommendations for interview questions:

    Well, it's not like fizzbuzz is something you'd ever actually use, anyways.

    Black swan: https://what.thedailywtf.com/post/788915

    Ok - it was messing around with Discourse, but stil..


  • Impossible Mission - B

    @arantor said in Recommendations for interview questions:

    @maciejasjmj and a developer who assumes everyone thinks the same way they do about everything...

    Like the one who somehow can't seem to conceive of not drawing all sorts of architectural details out on whiteboards? 🚎

    Maybe it's a UK thing or something? Because I've worked at a handful of different places in several different states over several years, and nobody does that. πŸ€·β™‚



  • @masonwheeler said in Recommendations for interview questions:

    @the_quiet_one said in Recommendations for interview questions:

    Have you ever actually built a large-scale application from the ground up?

    No, I've generally worked on mature products.

    But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway! That's what you have PMs for. If someone's trying to get me to write specs, something's gone very wrong somewhere.

    You want project managers to write DB schemas? undefined Do you know what a PM even is?


  • β™Ώ

    @masonwheeler said in Recommendations for interview questions:

    Uhh... what sort of PMs do you work with?

    They're Program Managers, not engineers. Weren't you the guy just talking to us about specialization?


  • β™Ώ

    @masonwheeler said in Recommendations for interview questions:

    Maybe it's a UK thing or something?

    None of my whiteboard sessions have occurred in the UK. I've drawn on whiteboards with other developers, managers, customers, subcontractors and children. All in the US.

    Do you ever collaborate with or explain things to other people?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.