I probably wouldn't literally just up and walk out, but it would count against you. Why would I want to work for someone who can't be bothered to read my sample code or resume? There's a double-standard here, where I'm supposed to have done research on your company before showing up, but you don't necessarily have to do that for me.

Are you hiring me to recite textbook definitions to you, or are you hiring me to write code? You can't really have it both ways. By asking me to recite textbook definitions when I've clearly demonstrated that I know the basics (at the very least), then you're wasting my time and your own.

This isn't hubris or egotism -- it's pragmatism. I've already provided the answer, and you're asking me the question again. You should ask me something you can't easily find the answer. Or better yet, ask me a question that answers several questions at once.

You might ask "I noticed on your Github profile you have an application called NaNoWriMo clone. What's that all about?" and I might say "Well, it's an MVC-based application that uses third party API calls to Google Docs using cURL and...."

And you might find that I've answered all of the stupid, basic "What is MVC?" and "What's a POST request?" and "Describe how HTTP works" questions that you would have asked before, except now instead of asking me rote questions that I get at every single interview, you'll find that you're getting the answers to those questions and then some.

Just because someone has code in their repo that uses GET and POST correctly doesn't mean the person knows why it was written that way. I've talked with people who admitted "I just copied this from stackoverflow."

It's also a very easy filter question that takes about 10 seconds to answer. There are still people that show up to interview that cannot FizzBuzz.

I appreciate feeling pissed at companies that don't seem to do any research into you. I've felt that same annoyance, especially when job hunting while employed, meaning I was using my PTO to talk to you guys. (And I especially hate the recruiters who call me at 4pm saying "I got you an interview tomorrow morning at 10am." Guess what I've got for you?) But maybe your code isn't showing exactly what you do the same way you think, or maybe they are working for an organization that is lucky enough to use something besides git.

I have a long list of complaints about how companies hire people. Giving me quick tests on basics isn't one of them.

I think you miss my point. The point isn't that "What's the difference between POST and GET?" is a bad question (it absolutely is), but rather that there's a better way to find that answer out than ask that question.

Here's how tech interviews normally go for me.

Interviewer: "Hi. Tell me about yourself while I look at your resume for the first time."

Me: "I've been programming since I was 12, went to college, got a degree in X. In the past several years I've worked on Y, which was built using Z with blah blah blah."

Interviewer: "Great, great. Can you tell me what an MVC is?"

Me: (mentally groaning) "MVC stands for model-view-controller. A model is..."

Interviewer: "Great, great. What's the difference between a POST and a GET request?"

Me: (mentally groaning again) "They're both verbs used in HTTP requests. A POST is..."

Interviewer: "Great, great. Let's do some whiteboard coding. Convert this array into a binary tree."

Me: "function convert_array_to_binary_tree(foo) {..."

Interviewer: "Great, great. Well, we're all out of time. I'll bring in the next person."

Interviewer2: "Hi, tell me about yourself while I look at your resume for the first time."

How it should go:

Interviewer: "Hi, I'm so-and-so. I've been checking out your resume and I saw that on your Github profile, you wrote an application called NaNoWriMoClone. What's that?"

Me: (excited) "Oh man. So in my free time, I like to write. Every year in November I participate in a contest called NaNoWriMo, which stands for National Novel Writing Month. I like their interface so much that I wanted to be able to use it every day, even if it's not during NaNoWriMo. What I did was I started out with a custom MVC framework that I wrote a year ago. Basically, you go to the main page, and you sign in using either FB or Twitter sign-on, which use OAuth to connect. I wrote a custom OAuth implementation, which you probably saw on my profile. I can go into detail about that, if you want. Anyway, so there are two models: users and novels. There's a one-to-many relationship where one user can have many novels. As the user writes, they can update the word count on the novel, and the app will calculate progress and how many words need to be written per day."

Interviewer: "Cool! I like to write too and I did NaNoWriMo last year. It was a nice experience, but it was so hard to track words."

Me: "I know! I thought about that, too, which is why I also integrated it with a Google Docs API. What I'm doing in the Google_Api class is hitting their API with a GET request to get the contents of their novel, then I count the number of words and update their count automatically. That's one thing NaNoWriMo doesn't do -- you have to input your progress manually. I also want to add a Markdown editor in-app which would send a POST request back to Google Docs and update the novel. So they can write it in the app and store it in Google Docs!"

Interviewer: "Awesome. You mentioned you used the Google Docs API. Did you run into any problems with that? If so, how did you get around them?"

Me: "The Google Docs API is pretty straightforward, but I wound up having to make several requests to get the data I wanted. For instance, I have to make one GET request to get the list of documents my app has access to, then another GET request to get the actual document I wanted, and then a third GET request to get metadata about the document. It took me awhile to handle exceptions, such as if I was denied access to a specific document, but I finally got that working, and now if something goes wrong, I can notify the user and have them look into the permissions or whether the document actually exists and so on."

Interviewer: "You mentioned you wrote the MVC framework from scratch. Why did you do that rather than use CodeIgniter or Symfony? Did you run into any problems?"

Me: "I decided I wanted to learn how MVC worked from the ground up. I had used Symfony in the past, but I wanted something a little less complex. So I started off with..." (and so on)

Interviewer: "I see you went to X college and got a degree in Y. That's interesting. How did you transition over to programming?"

----

Anyway, as you can see, the interviewer is getting WAY more out of me in the second example. Not only does he know that I know what MVC means, I've also demonstrated that I know how to use a 3rd party API, which necessitates knowledge of GET/POST requests. Furthermore, with a follow up question like "What problems did you run into?" the interviewer can find out whether I actually wrote it myself or if I went to StackOverflow to copy and paste it.

The point isn't that "What is the difference between POST and GET?" is a bad question (though it is unquestionably an inefficient question), the point is that you can find out that information in other ways (specifically from code samples!) and get so, so, so much more out of the interview. You will not only be saving both of us time, but the experience should be much more enjoyable for both of us.

You'll also notice in the second example that I've expressed non-programming aspects about myself. I enjoy writing. Maybe my interviewer enjoys writing (everyone harbors aspirations of writing a book someday, yes?), so now we have something to connect on. I have a non-CS degree. Maybe in a topic the interviewer is interested in. It establishes that I'm a real, live person and not just a code monkey. It's something we could talk about over lunch that's not work-related. It's a huge plus, imo.

Finally, your "lucky enough use something besides git" is irrelevant. You don't have to use git to look at my Github profile. My public repositories are public, and you can view the code willy nilly without even signing up for Github. You could just as easily substitute SVN or Mercurial or whatever.

This is why articles like OPs frustrate me so much. They pile on with the simple questions that get a single answer and don't really teach you how to interview more effectively.

I agree, but I think people should still maintain politeness even if the interviewer appears to be doing a less-than-awesome job. Even if you already know halfway into the interview that you're not taking any job-offer from them... just go through it 'till the end. If nothing else, it's an experience and maybe you'll pick up more info on how to avoid those companies in the future.

Sure, I agree.

Agreed. Personally; if I'm giving an interview and the candidate were to walk out for something like that I would be thinking, "Glad they walked out; I really would rather not work with that asshole."