[ertian]

Talking about past projects selects for people who are comfortable talking at length in florid language about relatively little substance, and who are maybe comfortable exaggerating or stretching the truth.

The most substantial and complex projects I've worked on can end up sounding simple and boring when I describe them. It's not that I can't discuss the details, it's just that I'm not good at _selling_ them. I tend to stick to facts and give a simple overview of the project, and I'm never sure how to approach the gritty details. And honestly, the right choice at the time was likely "Pair a MySQL db with a cron job" or something, and that sounds really underwhelming in an interview.

On the other hand, I've heard people describe projects they worked on, and you'd have thought they were leading the charge on the reinvention of Internet. But when you do the math on their resume, they were two months out of university at the time.

Those types of interviews basically and inevitably end up being "tell me a good story". Non-fiction is preferred, but interesting fiction will win out over boring reality.

[jlangemeier]

Focusing on the business need filled and results seems to be the best tactic here; we all hype ourselves, but if we were honest most of our work is boring "plumbing" to solve a business need. I mean, that's what we're hired to do, that's why we get paid; if we're not producing value for who we're working for, that relationship has broken down.

Most day-to-day "programming" can be broken down into that "Pair a datastore with a processor" idea, or "know enough about the problem to google/SO a fix or solution," so I don't think being honest about the mundane is a bad quality. Honestly, I think it's important enough, to make it at least a few of my questions on any formal interview, something akin to "what was a project that you thought would be simple but turned into something bigger, and how did you handle communication and management of it from that point forward?"

[k_sze]

At my last interview (which happened less than a month ago), I said I used to do "stupid stuff with Raspberry Pis" (my exact words) and I got hired.

Maybe I was just lucky, but I think you don't have to be all "florid", just show enthusiasm when talking about what you did, and it doesn't have to come from the vocabulary; people can tell whether you're enthusiastic from your tone.

[rescbr]

It really depends on the interviewer not wasting both our times and making it worth for everybody. I had candidates that weren't good sellers of their past experience, but I made sure to engage with them and they were in fact excellent professionals.

When interviewing you can ask the candidate for details on their MySQL + cron job and investigate how do they think, architect and build a solution and how much bullshit they're talking. Were you given a very detailed task to perform and you just did it? Or did you reach the conclusion that a MySQL DB plus a cron job would achieve the results? Why? What if the cron job failed? Draw a rough flowchart of your script, etc.

On the other hand, you can smell the bullshit of interesting fictions from a long distance when you ask those probing questions.

Now, an interview on basic CS algorithms? The only thing I would know is that you have a good memory and can recall the Cracking the Code Interview book.

[ertian]

The same thing actually applies to DS&A interviews: a person can memorize the solution to a given problem, but the interviewer can easily throw some curveballs that require deeper knowledge to handle.

It might come down to who is doing the interview: if you're a founder, or a team leader, and have done a lot of project management, you're likely to ask better questions about constraints, considerations, teamwork, etc, and get a better read on a candidate from questions about past experience. OTOH, a programmer giving an interview may not really care that much about those aspects or have a realistic idea of what a reasonable answer sounds like, and will thus tend to just jump through the interview hoops--and be more susceptible to, well, nonsense. On the other hand, they may actually be interested and invested in low-level technical questions.

I've had really good tech interviews that were challenging and even fun, and I don't think I could've faked my way through. I've never had a good experiential interview. But then, I've only ever interviewed for front-line programming jobs at large companies.