[k_sze]

I would argue that “preparing for interview” is exactly what’s wrong. Nobody should be “preparing for interview”, especially the really hardcore technical kind of interview, unless the job itself really is about hardcore technical stuff. Most of the time the job isn’t hardcore technical stuff, and so the performance during interview has zero correlation with performance on the job.

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

[mason55]

So what's the alternative? You can talk about work history but now you're locked out of the FAANG track if you don't start with an internship there because very few jobs are going to work at the same scale. Of course you could go learn about systems design at scale but now you're back to preparing for interviews.

You can just sit and chat like you're friends but that's going to bias the interview process to "people who I like" which is just "people who are like me".

I'm sure there are LeetCode questions that are more & less predictive of success but it does have the benefit of removing much of the bias in the hiring process, at the expense of requiring candidates to do some prep work. If you don't want to do the prep work then there are plenty of other places you can work.

I think one challenge in these conversations is that people talk about what the interview process should or shouldn't look like without talking about what the interview process is trying to optimize for. And each person is going to have different ideas of what they should be optimizing for in an interview so they'll have different interview solutions. Then you argue about the solutions but the reason you disagree is because you're starting with different goals.

[k_sze]

See this reply I wrote to another branch of the thread: https://news.ycombinator.com/item?id=26793636

[SamBam]

Exactly. And, just like unpaid internships, being able to invest a many hours every day into "preparing for an interview" is something that many people can't afford to do.

[k_sze]

The way I do "technical" interviews:

1. FizzBuzz, always, unironically; this easily weeds out 99% of the people who can’t program. I don’t even ask for an elegant solution, just a solution that works, in any language they choose.

2. Open question/toy problem that doesn’t involve hardcore technical knowledge, just common sense. The question is framed in a way that the candidate can grasp an actual use case - e.g. “How would you design a database for a public library?” I would explain concepts like PK and FK on the spot if needed. I even let them use the internet to look up whatever they need. The idea is not to see how much stuff they have memorized from leetcode, but to see their thinking process and whether they are resourceful and ask the right questions. Seriously, some people don’t even know what keywords, not even approximate ones, to use to Google stuff.

Resourcefulness and asking the right questions have much higher priorities on my list of things to look for in candidates.

[ionwake]

well then Im out, I refuse to do fizzbuzz and I can program so already I spot a fallacy in your statements.

[stale2002]

How else can I know that you know how to program though?

Fizz buzz is literally a couple IF statements and a loop.

As an interviewer, I need to know that you aren't just completely making everything up.

This is an actual problem. There are actually people who, for some reason or another, made up a bunch of stuff on their resume and literally do not know how to use a loop or IF statement, and there is no way to know this, unless you ask them to do it.

It is not an insult against you. It is just that an interviewer needs some small very easy check, just to make sure that you didn't completely make everything up.

[ionwake]

Why dont you test how I drink from a cup of water to ascertain that I am able to function as a normal human being?

Where is the line drawn?

If there is 20 years of programming experience it could be perceived as an insult in my opinion.

[stale2002]

> Why dont you test how I drink from a cup of water to ascertain that I am able to function as a normal human being?

> Where is the line drawn?

The line would be drawn at the place where like 20% of people who interview at places legitimately can't solve fizz buzz.

If I lived in a bizarro universe, where 20% of people that I talk too legitimately can't drink a glass of water, then I might have to test for that as well.

Fortunately, we aren't in that kind of situation yet.

> If there is 20 years of programming experience it could be perceived as an insult in my opinion.

Ok, and what about the people who put 20 years of programming experience on their resume and are just making everything up, and legitimately don't know even the basics of coding?

Thats the problem that exists in the world. That there are people who you have no way of knowing how to actually code at all, and exaggerated to an extreme degree on their resume.

How else would you suggest figuring out if the person that I am talking to basically just completely made everything up, or is instead just such a good talker that they can bluff their way into people thinking that they know what they are doing?

[k_sze]

Heh. I don't claim my method is perfect, but I believe it's reasonably better than hardcore leetcode stuff. FizzBuzz is the kind of problem that doesn't need any preparation to solve for any person who can program. In fact, if I sense that the candidate already knows FizzBuzz too well, I can skip right over it and head over to the open question/toy problem. The candidate could try to bluff me about FizzBuzz, but that's not going to help them at the open question/toy problem. :P

[ionwake]

>The candidate could try to bluff me about FizzBuzz, but that's not going to help them at the open question/toy problem. :P

Then why ask it? This is the whole reason for my stance

[rektide]

being able to reason about expense & cost, being able to appreciate the path the computer has to take, has real value, even if it's not called upon day to day. it's just more pleasant working with people who bother to develop algorithmic insight.

[k_sze]

Yes, but you don’t need to know how to “reverse a b-tree” for that. You just need to be aware of something called algorithmic complexity and big-O notation. You don’t even need to know how to determine the big-O for all the known algorithms and data structures: they can be readily looked up in reference books.

[rektide]

I agree that there's a lot of advanced data structures not worth memorizing and testing for rote knowledge is lame. and yet:

while there's a lot of other things I value in coworkers, and I want a diverse mix, I really trust a coworker much more who I know can reason through, can see how the code will execute, and understand what that implies, can find & state the significance.

there's a lot of here & now tests of ability in programming, to understand syntax, language, side effects, &c. but bring able to reason about runtimes, about this then that then that... it's the bigger picture. we have some pretty basic promise questions in our interviews, & it's so remarkable how many people get cut for now being able to understand sequencing, how a little async behavior trips so many up. not quite the classic algorithm test, but to me, they seem extremely similar in that they want the dev to be able to order & comprehend how things work.

I agree that a lot of pushback against algorithms is deserved. they are misused as a hiring bar frequently. but there is also things I value a lot, & they help elaborate whether a dev grasps coding situations or no.