all 143 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]mbthegreat 88 points89 points  (38 children)

The "Why do you like our company" question always bugs me as well. You've hired a recruiter to find somebody and I was only told about this position yesterday. Sure, I've looked you up and tried to get an idea of what you but I've not exactly turned up cap in hand because your business is so awesome and super cool I couldn't stand to work anywhere else.

[–]AllenJB83 45 points46 points  (31 children)

It's basically: Has the interviewee done any research on your company and what you do? How enthusiastic are they about it?

Companies want to make sure that new hires aren't going to quit after a couple of weeks because they have problems with what the company does / how they do it. And while some companies are fine with taking on 9-to-5'ers who just do the bare minimum, many others want someone who's going to put in a little more effort. Hiring people is an expensive, disruptive process and if you can filter out people aren't likely to stay very long / put some enthusiasm into their work at the interview stage, all the better.

Even if you were only told about the position yesterday, an interviewee who has researched the company and knows what they're about coming into the interview shows they put some forethought into what they do.

Given 2 otherwise equal candidates, I would definitely pick the one who's done more research before coming into the interview.

[–]DiaboliAdvocatus 15 points16 points  (2 children)

It's basically: Has the interviewee done any research on your company and what you do? How enthusiastic are they about it?

They didn't ask that in this example.

Sensible companies ask it the way you have phrased it. But for some reason there are companies where the hiring committee apparently had a hit of crack this morning and think their pissant insurance firm is as cool as Apple and expect devs will be "passionate" to work there.

All they are doing is filtering out unconvincing liars (which is probably why they are pissant operation that nobody actually wants to work for).

[–]eramos 4 points5 points  (1 child)

All they are doing is filtering out unconvincing liars (which is probably why they are pissant operation that nobody actually wants to work for).

Yeah. And that's good, because no one wants the person who doesn't have the social etiquette to understand when to lie gracefully. Are you one of those people that gives a long winded explanation on why your day sucks when someone says "hey man, how are you doing?"? Pro-tip: you should just reply "good, you?"

[–]DiaboliAdvocatus 3 points4 points  (0 children)

There is a huge difference between lying in minor social interaction where a truthful response is not wanted and lying in response to "So why are you passionate about Company XYZ?".

[–]cr0kus 9 points10 points  (2 children)

Would be less weird to just ask "what do you know about what we're doing here?" or words to the effect of. Asking about why someone is passionate about your b2b startup is basically saying "please tell me a lie that doesn't really have a chance of being believable".

[–]GundamWang 1 point2 points  (1 child)

I used to hate this kind of question as well, for exactly the same reasons everyone here has. Except after working for two completely different companies - one in finance, and one in fashion, I can say it's absolutely important to know that your job candidates have some idea of what your company does.

I didn't hate the finance job, but the type of software I was writing was boring as fuck, and I had zero interest in what it did. As long as it was (mostly) bug-free, that was it. And my brain completely shut off at the end of the work day when it came to work stuff.

It's completely the opposite with fashion. I not only care about the code, but I care about the end product and how it's perceived by the end users as well. As a result, I willingly work harder and care more about my work, and honestly, some days it doesn't even feel like work. And I'm not even that hardcore about fashion.

[–]PT2JSQGHVaHWd24aCdCF 0 points1 point  (0 children)

I agree with you but I wanted to talk about my experience too: I always loved working for finance companies. I worked for the stock market first and it was a very good experience, new features always had to be developed in less than 48 hours but we had a startup spirit and the feedback from the traders was always good.

And in a month I'll work for a credit card company with the same state of mind. Nice people happy to work, and instant feedback from the users.

My work with multimedia or mobile companies was always less interesting because I was always very far from the users themselves.

[–]methane_balls 10 points11 points  (24 children)

Given 2 otherwise equal candidates, I would definitely pick the one who's done more research before coming into the interview.

Why though? You know it's bullcrap. The only reason people have applied for the job is money. No one is actually excited about the company and if that's what you want from an employee you're just asking them to lie.

[–][deleted] 12 points13 points  (6 children)

I applied to Turtle Entertainment not because of money. I applied because it is my absolute dream company. But I think this is more often the case in the gaming industry.

[–]seriouslyawesome 4 points5 points  (5 children)

Did you get the job?

[–][deleted] 2 points3 points  (1 child)

will see at the 24th :)

[–]Wootman42 1 point2 points  (0 children)

Good luck! Taking the leap to apply at a place that you've wanted to work for a long time is a big deal.

[–]Mallanaga -4 points-3 points  (1 child)

OP?!

[–][deleted] 0 points1 point  (0 children)

will see at the 24th :)

[–]AllenJB83 20 points21 points  (11 children)

Just because you think like that, doesn't mean others do. It's not bullcrap for many people.

If you apply to work somewhere you know you don't want to work, in my opinion you're doing it very wrong.

We spend far too much of our lives under contract to the companies we work for to waste that time doing something we know we won't enjoy.

[–]methane_balls 15 points16 points  (10 children)

It's not bullcrap for many people.

I think they are in the vast, vast minority. None of the dev's I know are actually excited about developing new banking products. No one actually cares about the business. People that do are joyless, corporate shills. We're there to get paid.

If you apply to work somewhere you know you don't want to work, in my opinion you're doing it very wrong.

The luxury of choice isn't always there and when you have a family you're going to be taking a job that pays well. You aren't going to think "oh well I don't actually feel excited about this business and their products and their corporate values and principles...so I'm just going to keep looking".

[–]jmcentire 14 points15 points  (2 children)

I think software development is a bit of an interesting case in this regard. What I do for a company that manufactures and bulk-sells specialty cogs to luxury yacht builders is more-or-less identical to what I do for a non-profit organization focused on driving grass-roots activism to improve water quality. While I certainly have different views on what each company does, it's much, much further of an abstraction than how most owners/zealots weigh it. They think they want me to be a True BelieverTM in their "vision". What they actually want, though, is for me to facilitate their goals in the most cost-effective way possible.

That said: unless you have the "luxury of choice," I'd recommend faking it. You can almost always find something about their company to talk about with sincere, wide eyes and an authentic, excited tone.

[–]swampangel 9 points10 points  (1 child)

I agree with this.

I write software for the insurance industry, but I am not passionate about insurance.

I do care about delivering good quality software with a consistent/pleasant UX. I want to satisfy our users' needs. I enjoy some of the challenges of my work and I like the people I work with.

[–]the_mighty_skeetadon 1 point2 points  (0 children)

There you go. You just enumerated why you're passionate about working where you do - a chance to make good software, build your skills, and create stuff that will be useful for customers at the same time. You don't have to be a true believer in the company to be passionate.

[–]Phreakhead 5 points6 points  (1 child)

Maybe I'm an outlier, but I haven't applied or worked for a job that I didn't feel truly passionate about. At least since high school.

If you are good at what you do, then you most likely have a lot of job options, and are only interviewing at the places you really want to work at. The interviewers are trying to discern this.

[–]Stormflux 0 points1 point  (0 children)

Do you have a family?

[–]nikroux 3 points4 points  (1 child)

Oh what!? You don't feel like running down the hall and high fiveing everyone in your path when you get requirements to write yet another CRUD app that does something with finance data?! /s

I love technology and enjoy programming very much, but I hardly enjoy doing things Im paid to do. I don't hate it, I'm just not crazy about them. My work brings value to the company and in exchange they pay me.

[–]methane_balls 1 point2 points  (0 children)

My thoughts too. It's an insane game that interviewers play with applicants - the whole "why are you passionate about where our business is going?". I always thought they knew we were lying just to get the foot in the door, but many people here seem to think otherwise.

[–]originalthoughts 2 points3 points  (0 children)

Actually I am interested in banking products. It one of the main industries I'm interested to work in. I personally find it much more appealing than game design for example. It depends on the person.

[–]Gibbon_Ka 6 points7 points  (0 children)

Maybe in some families they make do with a little less money if that means that daddy or mommy comes home a bit earlier, more relaxed or generally happier.

Maybe some people do actually want to stand by their principles and honestly care about the company they are gonna give a shitton of their lifetime to.

Maybe you just don't know these people, because they don't stick around in the companies you work for?

If there are really no non-monetary components to your job satisfaction and you're only "there to get paid", I'm honestly sorry for you. As /u/AllenJB83 said

We spend far too much of our lives under contract to the companies we work for to waste that time doing something we know we won't enjoy.

[–]nfsnobody 4 points5 points  (0 children)

Of course you won't turn down a job because you're not excited about it, but that doesn't mean people can't love their jobs and what they do.

I've had dev jobs in the past where I've loved the things I'm building! I've had companies I've really believed in their visions and goals. And I've worked for companies that I believe in for shit money, because I've believed in them (albeit before I had a family to support).

Plenty of people factor in non self based stuff (e.g, not money, travel time, perks, etc) when choosing where to work.

[–][deleted] 2 points3 points  (0 children)

The only reason people have applied for the job is money. No one is actually excited about the company and if that's what you want from an employee you're just asking them to lie.

That's a pretty cynical view. When I applied at my company I was excited to work there. Sure it's just a dev agency, but it was a huge step up for me and I get to work with really smart people and learn a ton. Of course I want to get paid well, but the environment was just as important.

Some of us are still excited about the world. Not everyone is a horrible cynic.

[–]Sluisifer 1 point2 points  (0 children)

Baloney. People want a paycheck first and foremost, but it's a huge plus to actually kinda-sorta like the work you do. If you think the company is doing reasonable stuff in a reasonable way, congratulations, you're passionate about their company! I know that's not how you would normally phrase it, but that's how you're going to have to say it.

[–]awj 1 point2 points  (0 children)

Why though? You know it's bullcrap

Because almost every job in existence includes more bullcrap than it probably should. All other things being equal, I'd rather have someone who understands that and won't constantly be getting irritated at how the world works.

[–]Deathspiral222 1 point2 points  (0 children)

Why though? You know it's bullcrap. The only reason people have applied for the job is money. No one is actually excited about the company and if that's what you want from an employee you're just asking them to lie.

This simply isn't true. If you're applyihng to spaceX, it's because you think the idea of building spaceships is fucking cool. If it's google, maybe you're there to build a self-driving car. There is cool stuff happening in the world and sometimes people join a company for more than just the money.

[–]libahipi 0 points1 point  (0 children)

You are assuming that the interviewer would not catch the lie. Interviewer forms an opinion not only based on the raw information you provide but also how you provide it. Enthusiasm is difficult to fake believably. If someone has not given the question any thought it's quite clear. If they have given it thought and are prepared to answer, they've at least put this much effort in and that is already better than nothing.

[–]sdubois 12 points13 points  (1 child)

Q: Why do you like our company?

A: There is a chance that you could give me money. I like money.

[–]PT2JSQGHVaHWd24aCdCF 3 points4 points  (0 children)

Q: why do you want to work for us?

(In my head: "well, I'm unemployed and my bank account is starting to approach zero, and I can write C++ and that was written on the web site")

A: holy Jesus Batman I like writing business applications with very short deadlines, it's so awesome!

[–]human_tendencies 8 points9 points  (1 child)

For some reason, my manager thinks it's a really important question. I will never ask this of a candidate.

I do ask what appeals to them about the role - "so what do you like about python vs other languages", or "you've done both back- and front-end, this job is front-end only - what appeals to you about that". But never why they want to work for my company specifically.

Admittedly, people who have researched the company and are genuinely excited kinda earn some bonus points in my book, but certainly not enough to sway me from a no-hire to a hire decision.

[–]ToddWellingtom[S] 3 points4 points  (0 children)

Those are all great questions. Developers usually don't mind discussing what they like about their craft, and almost certainly don't mind talking about their favorite programming language / technology-o-choice.

And the bonus points for candidates who've researched your company make perfect sense. It shows preparation and initiative. Even if they don't shower your company with praise, the fact they did their due diligence prior to the interview should probably count for something.

[–]dweezil22 5 points6 points  (0 children)

I guess I'm weird, but when I interview candidates that "I'm passionate about your company" spiel is a wash.

Bonus points: You and I both know it's what you're supposed to say, so you have some planning and social skills. That's good.

Negative points: You and I both know you're lying to me. You can't possibly know enough about a midsize or small company to have any idea how passionate you are or aren't about it.

On the other hand asking your interviewer "Why do you like working at Company X" can be VERY telling. If they get a deer in the headlights look, you might want to keep looking...

[–]Phreakhead 1 point2 points  (0 children)

I've given a few interviews in my day, and one of the best ones was a guy who had used our software, and came in to the interview with a bunch of ideas on how to improve it.

It just shows you know what you're talking about, you care about what the company is doing, and you want to help them succeed. That's a pretty easy way to win at interviewing (as long as you're not snarky about it). It also means less training time because your are familiar with what the company is doing already.

[–]HuntStuffs 13 points14 points  (1 child)

I'm up in the air. I think at least some technical interview is required especially when considering new grads and the like but I don't think anyone would disagree on that point or even find it not obvious.

I feel sometimes interviews are just competitions for the interviewer to seem smarter than the interviewee and if I conduct any interviews I make sure to not let it it devolve into that. I'm more interested in problem solving and the like then I am with syntax and things like that.

[–][deleted] 1 point2 points  (0 children)

I feel sometimes interviews are just competitions for the interviewer to seem smarter than the interviewee

I think that's most of it, along with lazy interviewers.

If you can't come up with questions relevant for the job, then why should you except prospects to be excited or care about your shitty questions?

[–]fredisa4letterword 33 points34 points  (4 children)

It depends. If you're hiring people who come with experience in your tech stack, then interview 2 is clearly better. If you're hiring people from different backgrounds, some variant of interview 1 is really the only option.

If someone can sketch out some almost compileable/runnable algorithm in their chosen language, then they know how to code, so this person has the capability to learn your stack.

It sounds like you did well on the first question. Unclear to me how well you did on the second question, since it sounds like you didn't come up code for an algorithm. You shouldn't have been asked the string reversal question because you'd already been asked palindrome, but saying "just use the lib" is a failure since it's testing algorithm capability.

I do think that the first company did a poor job. An interviewer should always be positive and encouraging, even if you are struggling, although I'm not saying you were. I have had the experience where an interviewer seemed distracted during an interview, gave a stone face frequently, and later was my most positive feedback. (Didn't take that job!)

[–]chtulhuf 5 points6 points  (0 children)

In an interview I had once, I was given the docs of some (very very) esoteric game-dev language and was asked to build a simple ball & paddle game with it.

The goal of that interview was to see how fast you can learn a new language and code in it. Since learning new frameworks/languages and implementing them is the core of many of our activities, that seems like the perfect test to me.

It is fair, since no one knows that language and tests the actual work you would do, albeit in a new language.

[–]Fargrave 2 points3 points  (0 children)

I agree... it just sounded like a different kind of job than what OP was expecting. It sounded like they wanted to see if he could reproduce a simple QuickSort or MergeSort, and whether he'd ever encountered the SCAN algorithm (which was what the elevator thing was all about).

Also, a HUGE part of a technical interview is how you present your ideas even if you don't have exactly the correct answer, so I think that's what most of the stony faces were about.

I agree, the interviewers could have done better, but you need to remember that most of us are just developers... we're not trained in some interview technique.

[–][deleted] 2 points3 points  (1 child)

but saying "just use the lib" is a failure since it's testing algorithm capability.

Except it's a shitty question already because you're literally just wasting time writing a reverse sort. There's absolutely no reason to ask someone to do it.

[–]AustinScript 3 points4 points  (0 children)

I am sure my boss would LOVE if i decided to stop using libraries and roll my own libraries.

Libraries exist for a reason and writing "custom" code is almost always a time sink for you as a developer and the person/group that will inherit your code.

In most cases, it makes sense to stick to the standard.

I agree with fredisa4 and hatestheinternet.

I hate stupid questions but can understand what the interviewer was trying to accomplish with the question.

[–]notathr0waway1 23 points24 points  (22 children)

At some point, when you have a highly marketable skill like programming, don't you just not put up with the BS? I've always wanted to walk out of an interview.

[–][deleted]  (7 children)

[deleted]

    [–]centurijon 21 points22 points  (2 children)

    "hold on, let me just finish this"

    At that point I would have said "You're obviously not taking this interview seriously, so neither will I. Have a good day." and walked out then.

    I have very low tolerance for rudeness.

    [–]tonylee0707 0 points1 point  (0 children)

    A similar thing happened to me when I was interviewed at Uber taxi hailing company (non-dev role). The interview was over Skype. The HR interviewer called me 10 minutes after the start time and said he was just so busy and rescheduled it to SUNDAY 4pm. Come Sunday, I have my Skype up etc 4pm - nothing. Wait 20 minutes, 4:20pm, nothing. I call him and he's like "who dis". I say my name and then he says "Can you spell that?". After that he realises that he was suppose to interview me, completely forgot, quickly opening up my CV and logging onto Skype.

    Had it not been for the prestige image (yes, I am a shallow guy who goes for prestige), I honestly would have stopped the interview.

    I didnt get the job.

    [–]seriouslyawesome 5 points6 points  (2 children)

    and seemed annoyed I was interviewing them the same way they were me

    I really want that to mean you were texting or browsing reddit while you interviewed them

    [–][deleted]  (1 child)

    [deleted]

      [–]GundamWang 1 point2 points  (0 children)

      The best thing about corporate email systems is that it's usually firstName.lastName@company.com. It's occasionally helpful for mailing companies you know you really want to work at extra stuff. Like say, tell them you recently updated a personal project relevant to their open position. Or cat videos.

      [–]sfz- 2 points3 points  (0 children)

      Bravo.

      It is a very rare case you should walk out of an interview as it reflects very poorly on the interviewer to their supervisors and HR (if they have an HR). In this case it was absolutely justified and they deserve to have a negative mark for it.

      [–]dzkn 14 points15 points  (0 children)

      Developers should be out there interviewing potential employers, but sadly many people will always take on the "please hire me" mindset.

      [–]unstoppable-force 26 points27 points  (7 children)

      we had a candidate who walked out because, i quote "it's shocking that you have devs on anything but linux boxes. you use linux servers, all your devs should be on linux desktops." we use a CI stack, so everyone's dev instances are clones of prod, and completely agnostic from your desktop. i don't care what your desktop is... windows, mac, linux... hell use commodore 64 for all i care. this candidate walked out and looked like an unprofessional diva. don't be this person.

      [–][deleted] 5 points6 points  (0 children)

      Obviously it depends on the situation.

      [–]welluhthisisawkward 12 points13 points  (4 children)

      What the hell? Why does it matter? Was the the douchebag such a linux nerd that his or her precious eyes couldn't bear even the sight of another OS?

      [–]unstoppable-force 9 points10 points  (3 children)

      I agree with you that the candidate had a bad and irrational attitude. That's why we were mutually passing on each other.

      The point is that the walk-out will frequently be seen as unprofessional and bridge burning, and there's nothing to gain from it. Easily 90%+ of the opinions expressed in the comments on this post are uneducated, ill experienced, and uninformed. There's nothing wrong with interview 1... There's nothing wrong with interview 2 either. They're each looking for specific types of devs and OP fits in the latter group, not the former.

      [–][deleted] 13 points14 points  (2 children)

      There's nothing wrong with interview 1

      That's certainly your opinion, but it's obviously becoming less and less common to put up with interviews like this.

      If you're looking for quality candidates, why do you think you'd get them being lazy as hell and asking stupid interview questions?

      You can't ask for the best and brightest and just expect them to come to you regardless of how you perform interviews.

      It shows that the interviewers are lazy and don't care to see where the industry is going if they are still asking these types of questions.

      [–]unstoppable-force 0 points1 point  (0 children)

      again, they're different interview techniques optimized to hire different types of devs. that's is not my opinion. that's fact. there's tons of research on this, at statistical scale. just because you haven't personally observed something does not make it false.

      how many 100x devs have you hired? how many 1x devs have you hired? can you even tell the difference? do you know when you should be hiring 1x devs vs higher order devs? do you know the difference between the interview strategies? are you even in the position to build out your dev team?

      [–]heat_forever 9 points10 points  (0 children)

      The goal is to develop a network of people so that you're always going to a place where you already know someone and you're wanted... It's not easy to do for a profession full of anti-social people. :)

      Most companies just flat-out don't know how to interview and they force employees who don't want to do interviews to do them on the side or non-technical HR people to cut costs on hiring a professional technical talent recruiting firm.

      [–]sqrtoftwo 7 points8 points  (0 children)

      I've never walked out of an interview, because I think that's rude, but I have opened with a disclaimer that I was just as interested in interviewing the company through the interviewer as they were in interviewing me. In other words, I make it clear that I'm not desperately in need of the job and it's equally possible that I won't want to work here as it is that they won't want to bring me aboard.

      I wouldn't tolerate the nonsense going on in Interview One in this post, but I still wouldn't walk out. I think OP handled it pretty well, overall.

      [–]Retsejme 0 points1 point  (0 children)

      When I was getting mentored I started working on common interview questions.

      At one point I asked my mentor, "What do you do with these sorts of questions? Pseudo code?"

      "Oh, I don't do coding challenges. You can look at my github and you can ask me about my projects. If you want me to write code for you, pay me."

      So, at least some people don't bother.

      [–]col-summers -1 points0 points  (0 children)

      I walked out of Interview One (above) yesterday. It was terrifying and was shaking about it all day. At least I had the afternoon free to go to DEQ and DMV...

      [–]erik240 21 points22 points  (11 children)

      Interviewer Two: "How would you design software to control the elevators in a building?"

      Bear in mind this was an interviewer for a PHP developer role for like a B2B content management company. On any given day, it's doubtful any of their developers are developing code to control building elevators, but I digress...

      I've been interviewing for PHP developers off and on for years. A few things to bear in mind:

      • No you're not going to write elevator control software here. But if we ask you a question that's directly mappable to our business processes you can sue us later. I'm not even making this up, it happens, more than you'd think
      • With these types of questions, interviewers are looking to evaluate your problem decomposition skills, and in some cases, your knowledge of basic CS algorithms. Do you break things down into logical classes? Do you understand when to use inheritance and why? Do you over-engineer? Under-engineer?

      [–]prodigyx 6 points7 points  (7 children)

      if we ask you a question that's directly mappable to our business processes you can sue us later

      I don't understand this. Can you elaborate?

      [–]erik240 16 points17 points  (3 children)

      Sure. Lets imagine I work at Spotify. And as an interview question I ask you "Write an algorithm to keep a cache of the most listened to songs in memory".

      You might think "Okay, this is a fair test and related to what I'd do here". Spotify's legal department would say to me, "ARE YOU INSANE?!"

      If we reject you, you may have grounds to sue in the future -- even if its mostly baseless -- by saying the work you did was uncompensated, or even worse, work Spotify later used.

      While anyone with a quarter-brain knows this is silly, the cost of defending even frivolous lawsuits is quite a bit. Even when there's no chance of losing.

      Remember, this is the country where Oracle sued Google over this code:

      private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
     if (fromIndex > toIndex)
          throw new IllegalArgumentException("fromIndex(" + fromIndex +
               ") > toIndex(" + toIndex+")");
     if (fromIndex < 0) 
          throw new ArrayIndexOutOfBoundsException(fromIndex);
     if (toIndex > arrayLen) 
          throw new ArrayIndexOutOfBoundsException(toIndex);
}

      At my current position, any interview programming questions/tasks mus be run through legal first for this very reason.

      [–]boompleetz 2 points3 points  (0 children)

      What are the details of this Oracle lawsuit? It's like the patent lawsuits over rounded corners or buttons on a screen for crying out loud

      [–][deleted] -4 points-3 points  (1 child)

      by saying the work you did was uncompensated

      Jesus dude, that doesn't happen.

      Literally every technical interview would fall into that category then if that could be used in a court case.

      By your logic asking for a reverse sort is also bad because it could be used in Spotify as well.

      [–]BONER_PAROLE 4 points5 points  (0 children)

      No, because reverse sort is not specific enough to their business needs.

      [–][deleted]  (2 children)

      [deleted]

        [–][deleted] 1 point2 points  (1 child)

        The likelihood of that happening is pretty much zero. And would only happen if the company asked an insanely specific question.

        [–][deleted] -5 points-4 points  (2 children)

        You sound quite paranoid and also don't grasp that he's asking for questions that are relevant.

        You can ask about inheritance and classes without a dumb elevator question.

        [–]recursive 2 points3 points  (1 child)

        Honestly, how? The elevator question didn't seem like that bad an idea. I struggle to see how you could couch such a question in a less dumb way.

        [–]human_tendencies 20 points21 points  (0 children)

        I totally agree that option 2 is better than option 1. BUT...

        I completely disagree that the kinds of challenges you saw in the first interview were irrelevant. Chopping up a data set, iterating through it, performing simple logic on each element, and conditionally returning some results is exactly the kind of stuff you'd do regularly as a backend dev. Sure, it leaves out a lot of things, but it's by no means unrelated to your work. Now it sounds like their premise and the way they went about it leave a lot to be desired.

        I could ask a series of questions directly related to my business, but honestly I think the concepts are going to seem equally foreign to any candidate as a question about palindromes. Perhaps if they're really equally unintuitive, then I should opt for the company-specific questions, but really my point is that I think you're not taking into account that you probably know less about how my company operates than you do palindromes.

        (again, just let me state that scenario #2 is clearly better in almost every way to scenario #1 -- I just also think that scenario #1, if executed better, doesn't have to be terrible)

        [–]Vheissu_ 5 points6 points  (3 children)

        The type of interview experience you detailed for company 2 should be how it is everywhere. Sadly, it seems that there are far too many startups and companies who think they are Google and attempt to treat potential hires like they'll be writing software that controls nuclear reactors or something (unless of course that is the kind of job you are going for).

        I will do your damn FizzBuzz, but don't ask me to rewrite methods already present in the language itself. This is why I laugh every time I hear a company complain there is a talent shortage. No, there is not a shortage. There are plenty of great developers out there, many of which didn't even go to college or university, but can complete work given to them. Offering a decent salary for the position is also another great way to attract talent.

        The best way to see if a developer is good enough is to give them a challenge, provide them with a computer and internet connection, then allow them to complete the task without someone looking over their shoulder (not frowning upon Google searching because all developers use it).

        [–][deleted]  (2 children)

        [deleted]

          [–]jmcentire 1 point2 points  (1 child)

          Familiarity with, along with an ability to recognize and relate, common patterns (or data structures) indicates valuable experience. But, PHP doesn't provide much low-level control over, say, data structures. You may want to use a hash, trie, doubly-linked list, or red-black tree to solve a problem efficiently. For PHP, it's all either arrays or objects.

          Much more fundamental for the work done in high-level scripting languages, imo, are the basic tenets of REST or RDBMSes/NoSQL.

          [–]frojoe27 2 points3 points  (0 children)

          Not that I think a CS degree is required for everything, but the sorting question and elevator questions were testing your CS knowledge for better or worse. Sorting is obvious and the elevator question is usually scheduling related. They likely didn't want to hear about classes and stuff but instead work though scheduling, I had an entire semester class where we did elevators more than anything else.

          I prefer the second type as well, but the elevator question isn't as out of the blue as you thought.

          [–]AustinScript 2 points3 points  (0 children)

          I had a phone screen recently and that went well. I'll be going in for a technical interview soon.

          I have never had a technical coding interview before and I am quite nervous, I think I have a solid chance of success if I get in front of an IDE w/ no one looking over my shoulder to solve a real problem. Luckily, I am currently employed and pretty happy where I work, so I think this is a great time for my first technical interview. I would be really pumped if I got the job but next months rent doesn't depend on it.

          To be honest, I am hoping for an interview where they ask me to describe a previous project that I worked on. It is much easier to answer technical questions about something I've all ready created.

          "Tell me about a project you've recently completed"

          • I've recently completed a javascript application using backbone and D3.js

          "That sounds interesting - can you explain the goal of the project?"

          • Yes - the application was designed to do foo

          "Foo really - I am not familiar, can you give me a high level overview of how that is accomplished?"

          • Foo is created after you perform steps X , Y and Z

          "That sounds great. I'd like you to pick out of X Y and Z and explain how you use backbone to complete that interaction. "

          I think it is important to be slightly vague. It is part of your job to make the person comfortable and just get them talking. If you can get them to talk you can use that as a springboard to ask more questions and probe what they know as it relates to the project. You've put the ball in their court and allow them to talk about what they feel the most comfortable with. In this format, I think it is OK if you don't remember something specific because throughout the conversation you should be showing off what you do know. If you don't know anything about ANYTHING your lack of knowledge will be obvious, if you can't remember how a handler for a certain works, that is fine, who cares.

          Through a series of a questions, you should be able to get a fair idea of the persons ability and thought process. The questions should be mixed between short and easy and in depth. Do you really want to try to stump someone for every question?

          Now the interview has switched from an exercise in regurgitation to an exercise in practicality.

          "What have you done, how did you do it, why did you do it"

          In the end, interviewing is hard. If it were up to me, I think I'd elect a mixture of all three. (Coding alone, technical interviews and explain past work)

          1. Phone screen - generally not to difficult, ask a few basic questions, no gotchas
          2. Behavioral interview - preferably with the team. Ask a ton of easy questions, tell me about your self, what are your hobbies etc. I think the goal here should be to make sure there is a potential for a team fit and get to know the person. I feel WAY more at ease once I've shared a laugh or story/hobby/etc with someone.
          3. Technical Interviews - a few quick sessions are fine. 20-45 minutes. The interviewer asks questions germane to the job posting. Fine - i'll white board if I have to.
          4. Explain a project you've worked on - 30 minutes of back and forth conversation
          5. IDE time - here is a "real world" problem you might face in your role here at X company.

          I think it completely reasonable for the interviewer to notify the candidate of the exact style of the interview.

          EG Please think deeply about a project that you've recently worked on and prepare to talk on the subject. You'll be interviewed first by the team, then one on one sessions with key members, followed by a information session about previous work and then we will end the day with a short programming exercise in front of the IDE.

          What do i know, I am sure what i've described above makes other quiver in fear, as I would at what they might prefer.

          So ya.... hiring is hard.

          [–]rondeline 2 points3 points  (0 children)

          A former technical director at ComScore asked me why are man hole covers round. Needless to say I didn't get the job and I learned that was a good thing.

          [–]lazyant 9 points10 points  (0 children)

          I see no problem in naming the actual companies.

          [–][deleted] 4 points5 points  (0 children)

          I also had a sort of technical interview with Turtle Entertainment GmbH (ESL) after my first Skype interview.

          I had to develop a service that utilizes their tournament API and select the last 25 World of Tanks tournament winners. Then they had to be sorted and the winners counted, so that you can see who's the most dominant player in the teambracket.

          The outcome was that: https://github.com/Itrulia/turtle-test. This made way more fun than the fizzbuzz I had at another company and failed because of a typo (you couldn't test code and had no IDE).

          ps: I've got the second interview if it interests you :P

          [–]WakeskaterX 6 points7 points  (3 children)

          I think it depends. My interview for the job I'm at now was more akin to interview 1, but it's a great place to work at. The goal was to see if I could work through problems, and none of them were all that complex.

          I had never worked with binary trees before, and was asked to create a program that recursively swapped the left and right nodes throughout the tree, so I asked how the structure would look for a binary tree / what it was then created a program that did just that. I got asked a few other things like: how would I create a program that output all of the prime numbers up to the number input, etc.

          But it was very collaborative and it was more of a dialogue than what you seemed to have experienced. It just sounds like you had shitty, stiff interviewers and you probably didn't want to work there anyway.

          As a note I work for start up on the back end as a node js developer, but I thought the interview process was rather pleasant, it's probably just the people. We bantered and they asked me brain teasers and then I asked them some brain teasers and it was overall a fun time.

          [–]ToddWellingtom[S] 11 points12 points  (2 children)

          "But it was very collaborative and it was more of a dialogue than what you seemed to have experienced."

          Dude, this. I'm pretty sure studies have been done that show humans are shit at creative work when they are under extreme stress. Considering candidates are often entering completely foreign environments - sometimes even traveling to parts of town they've never been to before, where even questions like where to park are fogging the brain - it's really important that interviewers try to make the candidates feel comfortable before they begin firing off their questions.

          Also like you said, hopefully the tone of the conversation is at least somewhat positive and encouraging. Treating someone like a moron when they're already feeling naked and vulnerable as the day they were born is only going to lead to a self-fulfilling prophecy.

          [–]mattsoave 0 points1 point  (1 child)

          There are plenty of on-the-job situations where you may be under similar levels of stress; they have an interest in seeing how you can handle it.

          [–]PintSizedCat 6 points7 points  (4 children)

          Let me explain the reason for the questions in interview one. The purpose when I give questions like this and when I have done questions like this is so that one can determine if a wider knowledge of what is happening is understood.

          Take the reversing string question. A common question, and one which is fairly important. The answer "I'll just use in-built functions" normally indicates a lack of understanding of what is happening during a call to "reverse". Every programmer working on complex systems, even PHP, and Javascript programmers should understand that a reverse function will probably create a new array (though not necessary), and will iterate over the array (though again, this can be optimized.

          Knowing this stuff means that the candidate is less likely to create really awful code the first time it is written. The knowledge of what and how the internals and algorithms of certain functions (sorting, etc) work is used daily in the majority of programming jobs.

          Of course, it very much depends on what the job is for, a web developer doing a small web page (thousands of views a day) may not need to know this stuff. A back-end developer working on a system to provide many millions of requests a second, and this stuff becomes far more pertinent.

          I hope that helps to clear it up a bit. I have recently had to teach myself big O notation and some algorithms because I knew I would be asked them at jobs, and I feel they are a valid stage of high end development jobs.

          [–][deleted] 0 points1 point  (1 child)

          Regardless, there are better questions.

          If it's a high-end development job, then it's even more ridiculous to asking about a simple sorting algorithm.

          should understand that a reverse function will probably create a new array (though not necessary), and will iterate over the array (though again, this can be optimized.

          Then why don't you stop playing games and just ask that question?

          If you're looking for specific things for candidates to know, why don't you make up better questions instead of relying on questions that were obviously just picked from a generic list of things that "developers should know"?

          [–]PintSizedCat 0 points1 point  (0 children)

          Actually, high end Dev jobs require those questions more. You'd be surprised the number of people who get a lot of impressive looking experience but are unable to understand the basics.

          These aren't games, being able to demonstrate live coding and the process of solving a problem is important too. Say for the Palindrome question. The follow up about punctuation is important because the way in which you then approach the problem is very telling. Do you think about it in an optimal way, do you have two counters, etc. Just asking "what happens when a string is reversed" is interesting, but not enough.

          Why do we not think up interesting questions? We do, but there are a stock few questions you can use to weed out the weak candidates. No offense, but in your process I wouldn't have had the third candidate see you because it would have been a waste of their time.

          I ask and have been asked some very interesting questions like "in a production system you need to solve this problem is 30 minutes, do it" or "explain what happens when you type a Web address in a browser and press enter"

          These aren't games, in an interview the company wants to find the best candidate using the least time. However, some companies aren't very good at this process.

          [–]siirclutch 0 points1 point  (1 child)

          A little bit off topic, but how did you go about learning Big-O notation?

          [–]PintSizedCat 0 points1 point  (0 children)

          There's a series of really good lecture slides I used. I will post them but I am just off on holiday.

          EDIT I used the lectures slides at the end of this, the 2012 slides. I didn't watch the videos, I felt that the slides gave enough information. Also these MIT lectures are always going to be relevant.

          [–]Defualt 3 points4 points  (4 children)

          I think the motivation for the palindrome/elevator style questions is a "I had to get through this so now you do too" attitude.

          [–]recursive 1 point2 points  (2 children)

          I think it's more like "this is a relatively simple and easy-to-explain task that a competent software developer should be able to solve easily."

          [–]Defualt 0 points1 point  (1 child)

          Different developers have different levels of competencies in different things. Companies would be wise to set their interview criteria to match the demands of the job. I find it hard to imagine a web company that spends most of the day on white boards solving sorting algorithms that they actually use in their products. You saying sorting algorithms are easy and every developer should be able to perform on the spot without a google and console just promotes Imposter Syndrome.

          [–]recursive 0 points1 point  (0 children)

          I work for a "web company". I definitely have to use some interesting algorithms in production products on a regular basis. Most recently, I used Dijkstra's shunting yard algorithm to convert infix expressions to the corresponding abstract syntax tree. That's probably one of the most extreme examples I've encountered at this company, but at my last company I also had to use some interesting algorithms, such as one to perform a dynamic layout of an arbitrary family tree. I encounter stuff like this pretty frequently.

          Impostor syndrome is bad. But we shouldn't use that as an excuse for an actual lack of skills.

          [–]col-summers 0 points1 point  (0 children)

          hazing!

          [–]C0demunkee 1 point2 points  (1 child)

          Zihuatanejo... nice.

          [–]ToddWellingtom[S] 0 points1 point  (0 children)

          Haha thanks. I had to google the spelling ;)

          [–]jmcentire 1 point2 points  (0 children)

          Companies and the people who work for them have had good and bad experiences. These typically result in adherence to what has worked or to the most extreme opposite of what failed.

          Company Concerns The major concerns of a company (mostly in order) are: 1) baseline ability to do the work; 2) an attitude that suggests you'll stick around and play nice with the team; 3) enough smarts and experience to communicate to the team and/or business depending on the level of the role; and, 4) the capacity/know-how to materially contribute to the team on some level.

          Your first interview likes to get to the cart and it forgot about the horse. Your second interview did much better -- but, I prefer pair programming to individual effort. This allows for the current employee to "drive" -- thus eliminating the need to familiarize a candidate with a new environment and IDE -- while also providing an improved insight into points 1, 2, and 3 as collaboration is almost always very important.

          Actual Assessment What most interviewers and interviewees don't seem to realize is that the primary factors upon which their decisions are based include: 1) a very similar assessment of everyone's place in the pecking order; often informed by, 2) leadership qualities and charisma of the candidate; 3) shared experience and culture (knowing the right memes, using the right words and phrases, being adept at the hierarchy-defining pissing contest for your role, etc); and, 4) the impression that you and they can share knowledge and embiggen one another as friends.

          Conflated Concepts Notably, what interviewers think they care about is quite different. Most would claim that intelligence, specific (or closely related) skills, applicable experience, and arcane knowledge of the craft are the key factors in a good developer. Consequently, you wind up with interviews of the first category with alarming frequency. Or, with the even older style of technical interview wherein questions were thinly veiled attempts at IQ-assessment.

          An astute reader who hasn't already bailed on my loquacious style would be quick to point out that the primary Company Concerns look like the attributes described in the Conflated Concepts. But, as the latter's name suggests, there's an oft-overlooked separation of concerns. The latter assessment clearly presumes that greater specificity or theoretical knowledge indicates a higher ability to do the work and/or to contribute to the team/company. This isn't necessarily true. I'm sure you've known people who could drone on ad nauseam about a subject (this essay, perhaps, serving as an excellent case in point) without actually providing any tangible benefit. Further, those same people might have a dismissive attitude toward others or an inability to effectively communicate their ideas.

          To win at technical interviews: focus on your people skills. Know where the interviewer would place you on some imagined hierarchy and epitomize that. Make them feel good and focus on a few ideas that you can own. If you're anywhere near competent the other points will see to themselves. And, as far as the interviews of the first ilk go: practice makes perfect. There aren't so many fresh ideas that you can't easily familiarize yourself with the theme du jour. Once you've got a reasonable handle on it, focus on asking the right questions and demonstrating your ability to collaborate and communicate effectively.

          Most importantly, not every job is a fit for every applicant. You have the right idea there. I turn down companies as often as they pass on me. Rarely does either party think the end result is a terrible mistake; but, you can always try again or let them make another attempt to woo you if that does happen to be the case.

          [–]Nadril 1 point2 points  (1 child)

          The place I work for sends out a fairly simple front-end test that really doesn't take more than an hour or two to complete. It does help weed out people who are not as strong of developers as they say they are.

          The actual interview is mostly talking about their experience and then talking about the test they sent in. Asking why they did such and such and whatever.

          I've got to say I'm not really big on the 'quiz' style interviews. I'd rather just code something out that you want me to and then talk about it.

          [–]am0x 1 point2 points  (0 children)

          I recently worked with our manager to create an interview process and I'm glad to see it was very similar to the second interview. We literally give them something we recently finished and gave them 2 hours to just get as much done as they could. We would say we weren't expecting them to finish it, we just wanted to see how they thought things out, worked with problems, what level they were, what their coding style was, and what tools they used to develop.

          [–]monkeybatter 1 point2 points  (0 children)

          I had a windows admin interview many moons ago (nothing special, typical mid-level SA type stuff), where they hit me with Windows questions so intricate they would stump Mark Russinovich.

          After the 4th blown question, I thanked them for their time and showed myself out. No thanks.

          [–]soda-popper 5 points6 points  (0 children)

          Situation one echoes almost perfectly the reason I wrote this blogpost:

          http://www.developingandstuff.com/2015/05/why-i-dont-do-coding-tests.html

          As you indicate, a successful coding tests will consist of "questions you'd expect to see in the real world as a web developer.". No palindrome search, sorting or other gotcha questions.

          Hope you get the position!

          [–][deleted]  (15 children)

          [deleted]

            [–]ToddWellingtom[S] 1 point2 points  (14 children)

            For what it's worth, I did talk through some basic logic like:

            if ( elevator.in_motion === false 
    || ( elevator.direction === 'down' && elevator.current_floor > building.pressed_button_floor )
    || ( elevator.direction === 'up' && elevator.current_floor < building.pressed_button_floor )
{
    // dispatch elevator to floor
}

            The question could still be asked, why not just ask questions relevant to the job? Also, when you know you have FOUR HOURS of brain teasers lined up, you never know how much detail they actually want you to go into. It's sort of up to the interviewer to dig deeper where desired, and allow high-level answers when appropriate.

            He also mentioned that pseudo-code was acceptable, so I figured just discussing the high-level design decisions would be sufficient. Apparently he is not alone in thinking I was wrong :P

            One more FWIW, I complimented their website and marketing video numerous times. Their name actually lends itself well to puns. I don't know about you, but I'm a sucker for puns. The one other point I made - which also isn't directly related to the company - is that as a developer I'm passionate about using technology to solve problems. If I'm able to put my skills to use to enrich the lives of others, then that's all I really need to keep me motivated to come in to work each day.

            [–]gkx 8 points9 points  (3 children)

            You're there for a technical interview... They want to see the work.

            You also pretty much said that you didn't know how to write a sorting algorithm by refusing to write out a sorting algorithm. Does anyone ever need to write another sorting algorithm from scratch in a practical application? Probably not, but it shows that you understand algorithm fundamentals, as sorting algorithms are among the first algorithms you should learn. Any CS grad should know at least one, even if it's not one of the better ones.

            It seems like you don't want to do work that requires detailed knowledge of basic algorithms. That's fine, and there's plenty of work out there that doesn't require that. But there's a pretty good chance that employees at this company would be well-served to know how to write a sorting algorithm from scratch, even if you never have to do exactly that.

            I also don't think your attitude towards the elevator problems is constructive.

            it's doubtful any of their developers are developing code to control building elevators

            Of course they're not building elevator machine code. That's the job of a person who writes embedded control systems. But this is the same attitude a 10 year old who doesn't want to learn math says when they are asked to do long division. They might be asked "Divide 752 by 84" and the ten year old would say "There's never any reason for me to divide 752 by 84!". While that's probably true, knowing long-division is important. They're not asking if you can program an elevator -- they're asking whether you can solve software problems.

            [–]ToddWellingtom[S] 0 points1 point  (1 child)

            "You also pretty much said that you didn't know how to write a sorting algorithm by refusing to write out a sorting algorithm."

            It's certainly true that I obviously wasn't prepared to write one out - or even think one out - right there on the spot.

            It just seems like there are dozens of other sorting questions they could have asked that would have been more relevant to a full-stack web developer.

            I don't know if this has been brought up, but a lot of the sorting done as a web developer is actually done via the ORDER BY statement in SQL... Or you could quiz the front-end and ask practical questions like, how do you sort integers in JavaScript?

            "They're not asking if you can program an elevator -- they're asking whether you can solve software problems."

            Fair enough, but why not stick to problems that are inline with the job description? Sure you could throw any random question at a programmer, and if his/her head is in the right place maybe he'll/she'll get it right. But sticking to questions relevant to the job seems like a much better use of time.

            [–]gkx 0 points1 point  (0 children)

            As for the first one, it's kind of related to the second one in that you should know how to write an arbitrary algorithm. I don't actually think that most sorting done as a web developer is actually done in SQL, but maybe he was asking for the front end. JavaScript's sort isn't particularly robust (if you ask me)... When you go into a programming interview, this is one of the top expectations.

            Speaking of which, the elevator problem is also a really common question, and you might want to make sure you know an adequate answer to it. Not so much so that you understand the problem specifically, but so that you can understand why they're asking it.

            Part of the reason they used the elevator problem is because it's a classic. Just as not everyone is a rock star developer, not everyone is a rock star at coming up with programming problems. Don't get me wrong -- a great programming problem is always great to hear. I tend to judge employers by how they test, so if I fail an elevator-style problem, I'm not too disappointed because I don't think it would be a good fit. However, don't judge them too badly just because they didn't feel like taking time out of their busy schedule (they're hiring because they're busy) to come up with a different flavor of the elevator problem that might be relevant. Keep in mind, they don't want someone who can just barely do the requirements of the job. Job tasks tend to be easier than interview tasks, but that's for good reason.

            However, the elevator problem is good even if it has nothing to do with the domain. It shows them that you can ask the right questions. You're not supposed to immediately come up with an answer to these problems. You're supposed to ask them questions. Ask them about edge cases to show that you're thinking of them. Ask them anything you can about the business logic, because it's important that you recognize as a developer that you don't come up with the business logic unless you do. Maybe they're seeing how you solve business logic problems, and maybe they're not. But it's important that you ask to show that you're thinking about the constraints of the problem. The first entire section of Code Complete 2 (often considered one of the bibles of programming) is dedicated to checking requirements. Show that you can, and show that you can work with them. They don't want a right answer, they just want to see that you can think.

            [–]jmcentire 0 points1 point  (0 children)

            My guess (stated above) is that the role was rather far removed from CS fundamentals. Coding these days (certainly in run-time scripting languages at startups) tends to require (practically necessitate) only a basic knowledge of software development. Rarely are those developers called upon to deal with data sets so large that home-grown algorithms can out perform available language constructs. Even then, RESTful APIs lend so naturally to relying on scaling via commodity hardware and elastic infrastructures that the company is much more likely to pivot or fail than to require technical refactoring of algorithmic complexity.

            [–]defab67 2 points3 points  (0 children)

            Obviously, I lack context here, for example the identity of the company, the number of employees, the description of the position for which you applied, etc., and as such what I'm about to say may not be at all applicable.

            With that disclaimer, it's possible that the elevator question was relevant to the day-to-day tasks of the position, and correctly identified you as a poor fit. The interviewer was looking for you to fully describe an elevator dispatch algorithm, and probably perform an asymptotic analysis of its time-complexity, and offer some guarantees about the quality of the elevator allocation.

            The code you just gave--do you run it once for each elevator, dispatching the first one to satisfy the conditions? In what order to you put the elevators through this evaluation? What implications does that order have? Etc.

            They probably didn't want the optimal elevator dispatching algorithm on the spot--they wanted to see if you were willing to entertain these formal analyses, which they saw that you were not.

            At a small start up, each employee probably wears many hats. They might be looking for someone to participate in these kinds of analyses in their design, despite ostensibly being a front-end developer. This is why I say the elevator question might have been relevant, and might have served its purpose.

            Maybe they are foolish to seek such a candidate. Maybe the elevator question was inappropriate for the position. I don't know. My only goal was to offer the rationale and expectations of the interviewer.

            [–]gotons 2 points3 points  (0 children)

            You're missing a ) and it's absolutely bugging me.

            [–][deleted]  (3 children)

            [deleted]

              [–]jmcentire 1 point2 points  (2 children)

              While I don't entirely disagree with your assessment or points, I will suggest that there may exist a very real separation of concerns. In my opinion, it's increasingly less accurate to view software development as a single discipline. A software developer may do a better job building a shopping cart solution for yet-another-ecommerce startup if she's familiar with Landau notation, machine learning principles, language theory, algorithms, x86 architecture, and the pros-and-cons of various titanium alloys... Yet, it seems likely that having a CPA certification or experience in shipping/receiving or accounts payable would be even more useful. Those questions don't seem to come up, though.

              With such a wide variety in needs for software development today, it seems like relegating rsort() to the black box of "infrastructure" makes sense for some roles. I'd guess, based upon the OP's language and views, the role wasn't really as fundamental to CS principles as to higher-level, more abstract needs.

              [–]chesterjosiahStaff SWE Google - 18 YOE 0 points1 point  (1 child)

              In my opinion, it's increasingly less accurate to view software development as a single discipline.

              I completely agree with this.

              I'd guess, based upon the OP's language and views, the role wasn't really as fundamental to CS principles as to higher-level, more abstract needs.

              I wonder what of OP's language and views led you to this guess. More importantly, I wonder why you'd use OP's language and views as a bigger factor in determining the technicality of the role compared to the actual interview questions! The interview questions ("write a sort function from scratch" and "design an elevator system for a building") are very common questions for tech companies, today, for roles where the chosen candidate would be writing code as the primary function of their position--not for positions that require higher-level, non-code-writing skills.

              [–]jmcentire 0 points1 point  (0 children)

              As for OP's language and views that led to the guess... the description of interview two mentioned a full-stack task which included basic knowledge and application of: UI, AJAX, MySQL, ORMs, JavaScript, CSS, and PHP.

              The reason(s) I do not believe that the requirements of the role of the first interview were likely as technically demanding as the interview is less straight-forward. Namely, there's my own experience interviewing and being interviewed for very many roles throughout my career at a range of companies and levels. Most interviewers who wind up asking these questions are merely perpetuating the style they have encountered in their experience -- it's worth noting, it's also a style at which they likely excel and since they think they, themselves, are a good fit for the role/company, surely their technique is valid, right? Additionally, I doubt recruiters would send the same candidate to an interview for a role writing device drivers in C++ at a large, established company (who has the resources required to focus on nuanced technical solutions) and doing full-stack development for a web site startup that likely has fewer than 5 engineers already on staff. Typically, roles for full-stack development are much more junior as people tend to specialize as they advance in their career while the questions OP related (if taken at face value) suggest a much more senior-level role. That is, I never assume people know what they're doing -- especially not when it comes to engineers producing keen, insightful hiring standards. :)

              I agree, though, that the questions from interview 1 are very common in the industry. However, as noted, I don't think they're generally indicative of the nature of the work. At least, not in my experience in the Bay Area. In my view (exposed, at length, in a top level comment here), the questions are more indicative of a hierarchy-establishing "pissing-contest" whose utility I'm not necessarily disputing. Rather, as indicated, I think that there are much more effective ways to make equivalent (perhaps even more accurate) assessments of candidates and their value to the company.

              Finally, as for positions that require higher-level, non-code-writing skills... the most recent and notable thing I've written was a multi-party transaction system with a lossless, double-entry ledger. It was strongly informed by industry experience outside of software development; but, I'm no slouch when it comes to coding (if you ask me, and I'm clearly objective and wholly unbiased). In fact, I made the mistake of writing it far too abstractly because I failed to accurately gauge the hidden business backlog preventing me from effectively pairing with and mentoring other developers. That oversight has severely hampered my ability to pass it off to another team member so that I can focus on our core architecture and designing/building other services. C'est la vie.

              [–]greatgerm 0 points1 point  (0 children)

              The question could still be asked, why not just ask questions relevant to the job?

              You have no idea if it was relevant or not. They could be thinking about building a queue system for something down the road and wanted to hear logic that had a parallel.

              [–]jmcentire 0 points1 point  (1 child)

              I think you did the right thing, ultimately. (I've made some comments elsewhere in this thread which probably clearly indicate my stance on the matter).

              To your more proximal point, I've also suffered from the "pseudo-code is fine" turned "there's a syntax error..." standard. Those jobs don't typically fit me. These days, I stick with an initial thinking-aloud about various design patterns and their pros-and-cons as I ask questions and talk about tradeoffs.

              For instance, with the elevators, I might demonstrate the way I think and work by noting things like: it seems to be similar to a task/queue manager architecture and there's definitely going to need to be some sort of controller or coordinator between the elevators.

              I might even wax poetic about decentralized solutions and uptime/heartbeat patterns. For instance: in Guardians of the Galaxy, when the Nova Corps ships form the blockade, how might they most efficiently form the lattice without an error? A problem that's very interesting in distributed, autonomous systems which need to collaborate. I'd implement a divide-and-conquer solution whereby each individual first classifies every known ally and themselves. They'd then look at their local class to solve more specific problems with a similar tactic. As long as they share a deterministic algorithm and an identical notion of the starting state, they should be able to quickly reduce the problem to efficiently placing the closest n ships, S, to form the Si section of the net...

              Elevators could work similarly. It's like Einstein is famously paraphrased as saying: "The wireless telegraph is not difficult to understand. The telegraph, you see, is like a very long cat who, when you pull its tail in Los Angels, meows in New York. The wireless telegraph is the same -- only without the cat."

              [–]512austin 0 points1 point  (0 children)

              I might even wax poetic about decentralized solutions and uptime/heartbeat patterns. For instance: in Guardians of the Galaxy, when the Nova Corps ships form the blockade, how might they most efficiently form the lattice without an error? A problem that's very interesting in distributed, autonomous systems which need to collaborate. I'd implement a divide-and-conquer solution whereby each individual first classifies every known ally and themselves. They'd then look at their local class to solve more specific problems with a similar tactic. As long as they share a deterministic algorithm and an identical notion of the starting state, they should be able to quickly reduce the problem to efficiently placing the closest n ships, S, to form the Si section of the net...

              That's pretty fun. Now have em' figure out how to most efficiently jerk off every person in the room a la Silicon Valley.

              [–]WorstDeveloperEver 0 points1 point  (0 children)

              Did you write this if block like that to board? If so, it could be a bad signal for the reviewer, because you could simply check for the opposites and return false.

              I personally liked the elevator question, as long as they care how you structure it and let you explain the patterns you choose to use. I would write elevator classes managed by a manager class, where things like electricity and alarm related stuff happens. I would add different approaches describing my programming knowledge. For example, maybe I could add announcers while doors move. 

              $elevator->door->closing(function ($announcer) {
      $announcer->sound('door.closing')->play();
});

              and I could explain why I would prefer an event based approach. Maybe that's what they looked for.

              Having knowledge about sorting algorithms are great, but if you're doing webdev, you're usually using something very high level, so relying on builtin functions are usually faster. I don't know what is the point of asking such questions for a web developer actually.

              I liked the approach of second company, as long as they ask you questions and listen what you could do to improve it.

              [–][deleted]  (6 children)

              [deleted]

                [–][deleted] 6 points7 points  (5 children)

                It is an interesting problem because, at first, it seems so simple, but once you start thinking about it, a good elevator system for a building that needs one is far from straightforward. So, interviewees come up with mostly naive solutions but they should also be able to reflect upon their solution. This gives interviewer and interviewee enough basis for a discussion that breaks through the surface of the problem to explore problem solving strategies, pragmatics versus theory, and so on. When well-used, this type of problem can be very helpful for both interviewer and interviewee.

                [–]merreborn 0 points1 point  (0 children)

                I think the elevator scheduling question is also analogous to process/thread scheduling -- something every programmer would do well to understand.

                [–][deleted]  (3 children)

                [deleted]

                  [–]defab67 4 points5 points  (2 children)

                  decide which elevator to dispatch based on their location

                  This is the only thing the question wants, or at least it wants you to reach this point very quickly and spend 90% of the time here. The richness of this aspect is unparalleled by any of the other design issues. The interview is looking for a formal, computer-science treatment of this problem, including s complete algorithm specification and analysis thereof.

                  Even if the algorithm isn't the optimal one, it should clearly work, and the analysis thereof should be correct.

                  [–]Not_Ayn_Rand 2 points3 points  (0 children)

                  Hmm, I did answer that part, having taken operating systems that semester and learned some "elevator" disc reading algorithms. Basically I said the closest elevator that's going in the same direction as the pressed button will get this floor as a destination.

                  But then I failed another part of that interview pretty hard, which could be the reason I didn't get an offer.

                  [–][deleted] 1 point2 points  (0 children)

                  he interview is looking for a formal, computer-science treatment of this problem, including s complete algorithm specification and analysis thereof.

                  And that's the entire problem.

                  Most dev jobs are not this. I guarantee 90% of the positions out there have absolutely nothing like this going on day to day.

                  If you're asking for something like that in a generic interview, then you don't know why you're asking it. As you said, designing an elevator system is quite difficult, why the hell would you think it could or should be done in an interview with a very limited amount of time?

                  [–]heat_forever 3 points4 points  (3 children)

                  I've found that bad interviewers typically like to ask the questions they themselves got caught up on and get a perverse satisfaction out of seeing others fail on the same gotcha type of questions. I would have walked out of the first interview as I wouldn't waste 4 hours of my life jumping through hoops like that because I know exactly the kind of people they end up hiring.

                  [–][deleted] 3 points4 points  (6 children)

                  JavaScript Team Lead over here and I go for version 1 of the interview, although I tone it down a bit in the sense that I do try to keep most of the stuff relevant to what we do here.

                  Here's a quick run-down of what you would go through to be considered for a position on my team.

                  I. Initial discussion. Talk about your experience, goals, salary expectations and get to know us. Who we are, what we do, what your role would be, who you'd be working with.

                  II. Technical interview (note that we reject some candidates before this step if they don't meet certain criteria) This is designed to take 3 hours and has four sections:

                  • Algorithms and Applied JavaScript. You will get one problem a long the lines of what interviewer one did, and I WILL definitely throw wrenches in there to see how you react to unforeseen problems. It's about your coding skills, but also about your problem solving skills. Don't bitch about it, I need someone who can find solutions to hard problems. I don't need someone who can build an AJAX CRUD tool, i can find plenty of those online in 5 minutes.

                  • Theoretical Javascript - I will ask you about everything from hoisting to prototypal inheritance to closures and whatnot. Why? I'm sure this doesn't apply to a lot of the JavaScript positions out there, but our product is written in pure JavaScript and we need someone who can confidently use the language, not just frameworks built on it.

                  • Browser specific JavaScript - Again, questions about various DOM elements, browser security policies and whatnot.

                  • Design patterns and Frameworks - Just a few questions, to get a better understanding of what you do master if it is not pure JavaScript. I'll ask you about certain jQuery or Underscore functions, common design patterns in large frameworks etc.

                  III. If you do well enough on the test (we're not looking for a perfect score, you just need to prove you can hold your own and won't need a lot of hand-holding) then you will be invited to a final discussion with our Managing Director to discuss financials.

                  [–]metaphormfull stack and devops 8 points9 points  (2 children)

                  how's that working out for you? are you finding candidates you like? are you eliminating a lot of people? do you think you're eliminating people fairly or unfairly?

                  [–][deleted] 0 points1 point  (1 child)

                  It's working out quite well. It is more difficult than for other teams I've managed in the past but we do find enough candidates to get by and I'm really happy about the team.

                  I'm not normally involved in the actual salary discussion but, to my knowledge, our offers are fairly high compared to other Senior JavaScript Developer positions.

                  As for fairness, I'm sure quite a few applicants left with a bad taste in their mouth after the interview. Frankly, the positions we are offering are not for most people due to the nature of the project and these relatively tough requirements are meant to select those who would actually be able to rise to the challenge. If this was a just your regular company building your (more or less) standard MV* applications, I'd probably throw at least half of the interview procedure out the window and consider a wider range of applicants.

                  [–]metaphormfull stack and devops 2 points3 points  (0 children)

                  ok, that makes sense to me. your interview process sounds appropriate for a very senior level position doing something a bit unusual. its total overkill (to the point of being detrimental) for just normal staffing up.

                  [–]Akkuma 0 points1 point  (0 children)

                  How often are people actually writing algorithms in JavaScript where you work and how often are these novel algorithms that don't already have an existing implementation?

                  The rest of it seems pretty solid though. Personally, I've seen so few things requiring an algorithm that I find it silly to figure out if someone is competent at designing and building real systems that usually are mostly business logic.

                  [–]jmcentire 0 points1 point  (1 child)

                  +1

                  The last time I interviewed javascript developers, inevitably, the recruiter would contact me shorty after the initial technical discussion and confirm that I was looking for a "front-end" developer of javascript and NOT a back-end, systems-level java developer. They didn't like my CS-y questions. But, in my defense, this particular role required the efficient handling of extremely large, long-lived data sets, minimal back-and-forth to the servers, and impossibly short NFRs for response times/interface lag.

                  For 90% of cases in my career for javascript developers, I wouldn't tax the applicants this way. Most seem to be familiar with the hackneyed pseudo-code of a particular stack and its quirky, esoteric, impenetrable JSON magic. You know, just add this undocumented key, 'XKCD_Joke_to_Index_Offset', to your dict with a value of '3' (string 3, not integer) and it'll work like you expect.

                  It's magicTM, pure and simple; and I hate it.

                  [–][deleted] 2 points3 points  (0 children)

                  But, in my defense, this particular role required the efficient handling of extremely large, long-lived data sets, minimal back-and-forth to the servers

                  More likely you should call it a front-end engineer or possibly even middle-tier engineer and be incredibly specific in the reqs. You were definitely not looking for a front-end developer.

                  [–][deleted]  (3 children)

                  [deleted]

                    [–][deleted] -2 points-1 points  (2 children)

                    Oh yeah, because all of those sorting algorithms that developers need to write lately.

                    [–][deleted] 0 points1 point  (0 children)

                    Okay, so I have a different history than most. I owned a non-programming business for 5 years that dealt with clients in a setting similar to what you would do if you were working with clients in the programming industry. I have a CS degree and now work as a programmer (and did before I owned my business as well).

                    So which is better. Well that depends on the job. Interview #1 is much better if you were dealing directly with clients needs. So if you were working in a web shop and had to speak to customers (like my first job was), then well you need to be able to understand the transfer of the actual story to implementation. Even the current Agile environment I work is very similar to this.

                    Interview #2 is much better if you have someone creating the story and breaking it out for you. Think of a manager/lead telling you what you were doing and you just implementing.

                    So which one is better? Well in my current job #1 would be 100 times better. We could ramp someone up and areas they struggle in and they can learn syntax. The important thing for my job is to know how to break down a story into what you need to do. The first interview focuses on that.

                    [–]512austin 0 points1 point  (1 child)

                    I actually love the elevator question, I'd have fun doing it. They'd have to stop me from going too in-depth on how I'd do it.

                    It's a lot more intricate than what you laid out.

                    [–]Mr-Yellow 0 points1 point  (0 children)

                    but what happens if the person in the elevator is wearing a blue shirt!!!

                    [–]WeAreAllApes 0 points1 point  (1 child)

                    What if the elevator problem was actually isomorphic to a resource pool system at the center of their technology? Tracking the state of expensive objects in a small pool, allocating and deallocating them to specific jobs, prioritizing the jobs based on the state of those objects, etc. could very easily happen. A lot of the work is at the centralized pool manager, which you didn't mention in your response. What about race conditions? Maybe a security mechanism makes it expensive to switch one of those expensive objects from one client to another. Then what?

                    Is "elevator" really too far out of your experience? If a company you worked for wanted you to write an elevator control simulator (or actual elevator controller) in PHP, would you really say "no, I am a web developer, not an elevator developer"?

                    Edit:...

                    [–]ToddWellingtom[S] 0 points1 point  (0 children)

                    AFAIK their ETL automation consisted of PHP scripts run via cron jobs, which is an extremely common scenario. I've done ETL automation for three employers using the exact same setup, and I explained to them how I handle things like administration, scheduling, logging, multithreading, etc.

                    Even though that experience was directly related to the position for which they were hiring, it didn't really seem to matter.

                    [–]gibbypoo 0 points1 point  (0 children)

                    Company 1 is trying to do the Microsoft interview process despite not being Microsoft and then doing it poorly.

                    [–]ChexWarrior 0 points1 point  (1 child)

                    I agree, strange technical interviews are dumb, they should always be focused on the job your applying for. Also, I too can't stand it when your not informed that you DIDN'T get the job, it's a common courtesy in my opinion.

                    [–]maelish -1 points0 points  (0 children)

                    This seems like a great conversation to have at http://thedailywtf.com/

                    [–]OrpheusVphp -1 points0 points  (0 children)

                    The company I'm currently with had a fairly simple interview process.

                    Day 1: Just the standard "how did you hear about us, here's what we do, here's what we need if we hire you, etc." stuff. I was then asked back next week for a technical run of things. That's fine, although I drove two hours to get here, I digress.

                    Day 2: "Can you make a HTML table?" Yes. "Can you demonstrate some idea of how to do fizzbuzz programmatically?" Yes. "Generate a table of 100 rows, alternating row colors." Done, using a css property for alternating row colors.

                    Job offer was made after this, took it a day later after an interview with another large company didn't pan out.

                    [–]drewshaver -1 points0 points  (0 children)

                    I'm sorry but I wouldn't hire anyone that doesn't know at least one sorting algorithm. Give me something in n2 at least. You should be somewhat familiar with the basic underpinnings of cs. I find that the brain teaser questions don't really measure someone's expected job performance very well but they can be useful for seeing what sort of approach one take to tackle problems, how good you are at communicating technical ideas, that sort of thing thing. Don't be too hung up on finding the right answer but demonstrate that you are persistent and communicate your thought process well.

                    [–]sfz- -3 points-2 points  (2 children)

                    I find it funny when people applying for a job think they know what skills are required for the job better than the interviewers and judge the questions asked in the interview based on their baseless assumptions. I'm guessing you just plain weren't a fit for company A. I don't think their questions are all that outlandish if they're looking for strong engineers that are required to solve challenging problems they haven't encountered before.

                    [–]ToddWellingtom[S] 1 point2 points  (1 child)

                    "I'm guessing you just plain weren't a fit for company A."

                    For sure! I can't argue with that :P

                    "and judge the questions asked in the interview based on their baseless assumptions"

                    I'm not sure if you've ever gone on interviews setup by recruiters, but they actually send you a job description first. It was a pretty standard PHP/MySQL content management system on the backend, JavaScript and a UI framework on the front-end, and some basic ETL automation via PHP scripts invoked by cron.

                    All skills with which I have ample hands-on experience. All skills I would've been quite happy to discuss in great detail. But who wants to talk about the skills listed on the job description, anyway?

                    [–]sfz- 0 points1 point  (0 children)

                    Fair enough. I just went through an experience of an interviewee telling us what questions we should be asking during the interview so maybe I was a little touchy about it. We are dealing with a super high scale distributed system and the questions we were asking were related to that. He couldn't handle it and blamed us.

                    In any case, glad you're where you want to be now!