Oh yeah? Well, if I'm being interviewed, and someone doesn't ask me those questions, I'm going to walk right out!!

This is how we debate interview tactics, right?

Don't walk out on interviews just because you feel your time is so valuable. You're already at the interview. You planned your day for it and started it. Just politely continue 'till the end, you might learn something you didn't know before.

At the most, if you get a way out there question, like, you applied for a dev job and they ask about your proficiency in Microsoft Office, just politely say. "I've used it from time to time. By the way, I've never been asked that question in a developer interview before."...and just continue on. If you think so much of yourself that you're offended by that type of question and abort the interview, I think that says a lot about you just as much as the interviewer.

Hmm, I'm going to suggest to my company that we actually asked dev candidates that question! See what happens! (somehow, I doubt they'll do it.... but it'd be funny to get the reactions).

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.

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.

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.

You'd be surprised how many 'senior' engineers can't code their way out of a cardboard box.

Background: I've interviewed hundreds (if not thousands) of engineers.

Can you give an example of something you've seen. I just keep hearing about people who can't do fizzbuzz, but how bad are people really? Or what is it that makes these engineers so bad? How have they lasted in the industry?

that said i feel you. tbh, i have managed to impress anyone i worked with. most were people i met at hackathons, people that wanted to bootstrap their startups or general referals. on the other hand I failed most interviews i took(with a few noteworthy exceptions)

It once took me until after the interview to figure out that the guy just wanted to find out whether i understand how variable scopes work.

A lot of interview questions are questionable at best, and most code challenges are even worse. they're exactly how universities teach programming. The only problem is that universities suck at teaching programming. I know a lot of really awesome people that went to university because they thought knowing the topic they study was a good idea, but it turned out to be the opposite.

But one lady once asked me is there a special command to find out where traffic goes? I said route. Is there any special flag you would use she continued. But what she wanted was to hear route -n.

I'm pretty sure in those kinds of interviews they think i'm an idiot

I'm generally happy if they don't ask any questions and write a simple interest calculator. Most people ask some questions about when interest is calculated during the year. Then, if the questions haven't gotten us there yet, I ask them to modify it to a compound interest calculator where you can also contribute some money every year.

I've never had anyone who didn't understand the concept or what I was after. Or at least I didn't have anyone who admitted to still not understanding how it worked.

Two people stand out.

One of them immediately tried to write a recursive function and got lost. Then started over and tried to calculate a one-liner to do compound interest without looping. Couldn't get it, started over with a for-loop and failed to return in the proper place: the code was returning a value and then immediate next line was more calculation.

The second let me explain the problem and then said "I'm sure there's some library call for calculating compound interest, I'm just not sure what it is." Full stop. I explained that I wasn't asking for the library call, I was asking them to work up the algorithm and write code that did it.

They repeated the statement that there was a library call for it but they didn't know it and that if the interview was going to be about the specifics of library functions then it wasn't going to be a good interview.

In both cases these people passed a phone screen focusing mainly on experience, algorithms, design, etc... Since then I've adapted the phone screen to cover more of Steve Yegge's points [1] and I actually include a small coding question on the phone.

I don't think my system is perfect, but in the last round of hiring the people who made it through the screen were almost all good technically and weren't offered positions because of fit with the team. I'm sure there were a few people who might have been good that got filtered out by writing code over the phone but at the time I was willing to risk that vs the time commitment for the rest of my team to do on-site interviews for someone that could be DOA.

[1] https://sites.google.com/site/steveyegge2/five-essential-pho...

They've lasted because they've usually only had one or two employers, as a permanent employee (rather than a contract) and no-one code reviews until it's too late.

Have you also followed up on those failed interviewees to verify that in a real world setting they cannot perform?

If you haven't, then all I can see is a statement of "I have a standard very few can meet".

Do you have any pointers on weeding these candidates out? Our country's employment laws make it hard to fire net negative producing programmers.

> perfectionism seems to be a common thread to not delivering in my (limited) experience

I'm afraid I'm the engineer being described here. I pride myself on technical excellence, theoretical understanding and practical experience with lots of different technologies.

Yet my work history mostly consists of an unbroken trail of unfinished projects and undelivered deliverables stretching back decades.

How can I cure myself of this? Or should I switch careers?

However, assuming that you're accurate in your statement that your projects were unfinished, then it would appear that you need to question why that's the case, as we cannot infer that the traits you've ascribed to yourself are the cause of project failures without knowing more about the other variables in the equation. For instance, the projects may well all have been failures for no fault of your own: scope creep, management interference, poor teamwork (or poor team members), or any number of other variables could be responsible. But since this is not something we can address at this point, let's assume that your project failures are indeed a result of your perfectionism.

The easiest way (in my experience) to 'cure' perfectionism in software is to follow the YAGNI ("You Ain't Gonna Need It") mantra, coupled with approaching a project from a divide and conquer perspective (yeah, pg would pretty much hate this). First break the project into its key deliverables and its 'nice to haves'. Once all the key deliverables are complete, then the project is complete; 'nice to haves' aren't factored into the completeness equation for the project. Once you know what your key deliverables are, then order them in terms of dependency: if deliverable A requires that deliverable B be completed before deliverable A can be completed, then focus on deliverable B first. Now that you know what you're supposed to be working on, you can get started on the deliverable at the root of your dependency tree, but whilst working on it ensure that you're only adding the functionality necessary to complete the current deliverable. As you work your way through your deliverables, refactor the previous deliverables as necessary to make your current deliverable work. For instance, if your root deliverable wasn't required to be thread-safe when you first wrote it, but your new deliverable requires it to be thread-safe, then work your way back through your deliverables refactoring as necessary in order to meet the requirements for your current deliverable.

By sorting your deliverables into dependency tree, you can ensure that you can properly apply YAGNI. It's very tempting for a perfectionist to turn into an architecture astronaut, and spend weeks or months mapping out the entire solution and all its edge cases before they've even started to work on a single deliverable; by keeping your deliverables in a dependency tree and working from the least to the most dependent, you force yourself out of this mindset. By applying this method, you also force yourself away from analysis paralysis, because you're not permitting yourself to consider patterns or architecture until the project's current deliverable necessitates it.

It's worth noting that this method won't work for all projects, as it requires a good understanding of what the deliverables for the project actually are before you can apply it. It also may not work for you at all, since it's all down to personal experience, but I've personally found that forcing yourself to focus only on the concrete deliverables ensures that you don't end up stalling yourself in analysis, and gives you lots of little pep boosts in the form of finished deliverables and refactorings.

Nonetheless, good luck finding a cure that works for you.

No code sample? Get some. Won't provide some? Don't bring them in for an interview.

The point I'm making is that you can pre-qualify candidates in a LOT of ways before you even bring someone into the office. If I get into your office and you ask me dumb, basic questions, then you haven't screened me effectively. You should theoretically be able to make those determinations before I ever step through the front door of your office.

That seems like a reasonable idea, but we've tried that before, and it's just a terrible filter. Let me try to make a more general claim: anything that lets the candidate have outside resources or unlimited time is going to be a bad filter. In this case, the candidate can prep the code sample and be able to explain it well.

And what do I do if I don't like to release my code publicly? Should I not be hired by any company if I'm not personally a fan of open source (hypothetically)?

I don't think candidates should be excluded based on the lack of a github repo.

If you refused to send me code samples, I wouldn't bring you in for an interview.

1) Work for a company that does not allow you to post code that you write at work (fairly common)

and 2) Don't have time / don't want to spend time on homework for an interview

Combined with: a) Do not code for fun at home

or

b) Code for fun, but in something so completely unrelated that it's not useful (8 bit microcontroller code, say)

or

c) Code for fun, but not seriously with any kind of quality

If you gate your interviews on who has public code repositories, you're missing out on a LOT of qualified people.

A would rule you out as a candidate for me. Passion is almost always a requirement. B would be acceptable -- in general, language doesn't matter. It's the ability to write code and explain it that matters. C would be a tossup. If you write crap code for fun, then why would you write better code for real? But I get that. Sometimes I write code for fun just to see if something works, and I never refactor it to make it more efficient or whatever. That's understandable. Again, it's more about the ability to master the basics to begin with.

I can teach you to be a better programmer, provided you understand the basics (which your code samples should demonstrate). I don't have time to teach you the basics (unless I'm specifically hiring an intern or something.)

Also, consider that in my original post, I said this is my process and how I do things. It has worked very well for me so far. I may rule you out, but I'm willing to bet that there are others equally as good (or better) than you that are willing to do what I consider to be far less annoying than the way interviews are conducted now.

I don't want to waste your time -- nor my own time. That's the end game here. By having code samples ready for me, you are eliminating a not insignificant amount of redundancy for both of us.

"Codes for fun" is HR-compliant jargon for "20-something, no kids, willing to work unpaid overtime" and it'll be caught out as soon as some "sues for fun" lawyer can be bothered to mount a case.

And for your other argument, I have a full time job but will sometimes take very short term (5-10 hours of work) contracts for interview purposes. Usually this is a last step before getting a job offer, more as a way to gauge whether I'd work well with the team than whether I can code in general.

The candidate was understanding, and did it - he didn't have to have exact syntax, I was happy enough seeing psuedocode since I already took a peek at the Github profile that was a part of his resume.

It only wasted a few minutes of his time whiteboard coding, and it wasn't intense, so it gave him a nice easy way for him to explain his thought process. I asked relevant questions to the code that he wrote, and it lead to a good discussion on some things.

I felt that we were mutually happy with the experience, as he subsequently accepted our job offer.

On the whole though, asking stupid questions is a waste of both side's time.

IMHO, there's no need for whiteboard coding.

Having said that, if you are going to ask me to do some whiteboard coding, I would greatly prefer something like you described -- a high level response that tests my thought processes. You can see my code on Github, I shouldn't have to write some on a board. But I'll be happy to explain thought processes while solving a problem.

Not that I would have minded coding on the fly or answering stupid brainteasers - I grew up figuring those things out. Those leave me with negative impressions of the company though, and may lead me to demand a higher salary to accept a position.

Very good point, though.

As mentioned, I'm a bit skeptical that an interviewer can reliably extract that information.

I will send you code samples or show you my contributions to open source projects so that you know I can code, happy to discuss these until you are happy.

What is far more important is to find out about me, do you like me, can you work with me & tell me honestly about your dam culture - do you expect everyone to be at there desk at precisely at 8am, work a minimum of 80 hours per week? How is productivity measured? Do you expect me to attend some "team building" weekend nonsense when I could be spending time with my wife instead.

As an entry level applicant, I can't stress how important this was to gaining insight into both how I function when given a deadline and what kind of work is in store for me. It also lets me know what I might need to study in the future or what I need to study immediately.