[MattGaiser]

To me the really bizarre thing is that I so rarely talk about things I have actually done in interviews. Even for system design ones, I am often repeating information out of a book that I read as that is the correct theoretical answer.

I suspect you could teach someone to pass a lot of tech interviews without them ever building a production system.

[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.

[guitarbill]

You can teach that. You can even pass most tech interviews without having ever touched version control or knowing how to use it. Maybe that's an easy thing for candidates to pick up once hired, but then so are algos you never need in day-to-day programming (like sorting), because you can simply look them up should you ever need to implement that.

It's all a bit broken. Best method I've seen so far is to sit down with candidates and pair on some code, and it's still got issues.

[ionwake]

I have nearly 2 decades of experience and when I was asked to write a console log hello world app by a teenager and the CEO , who stared at me silently - well - I just couldnt bring myself to do it, fear of failure at such a simple task in such an OTT scenario mean I quit the interview on the spot as I did not want to know what the judgement could be.

Im not saying its right, just that it didnt come naturally to me to be in that situation.

[mixedCase]

You should not be taking an interview so seriously that you freeze under such a situation.

If you feel it's out of your control, it could've just been a bad day, but you may be suffering from something like generalized anxiety or a similar problem, you might want to look into that with a health professional.

[ionwake]

It wasn't anxiety as much as knowing that if I faltered even a little that this particularly interviewer would say no. I had not written fizz buzz in a few years and decided that the fact I thought about it for a few seconds meant I had already thrown the interview away.

Im just saying its thanks to my instinct that I have been so successful in my life, and I have never lost anything by refusing fizz buzz, yet have attained good things.

Maybe its survivorship bias.

It goes against my rules to proceed in interviews I think don't lend themselves to the situation.