This happens to me in interviews when either I'm too exhausted to be interviewing or I'm just having a really off day. It should be obvious from my Github and general OSS contributions I can code and do meaningful things but sometimes I just can't code on-demand.

Unfortunately people tire me very quickly, I have a limited budget of people time per-day and interviews frequently blow that budget early in the day yet continue into the afternoon (talking particulary onsites for bay area companies here).

I would say 9/10 I manage fine but there have been occasions especially when I have been in between jobs and taking lots of interviews when I have just bombed because a particular company stacked all the code heavy interviews late into the panel.

Separately from that speaking as a hiring manager for several roles I don't think coding on demand is a good metric. I don't expect people to do it once hired so it's not useful as a measurement of their fitness for the role either.

Design heavy interview questions on the other hand I find very useful. They generally are less specific and speak more to experience, knowledge and taste. Things that are very relevant in an engineers real-world productivity. They are very punishing vs code on-demand interviews for new grads though so if your pipeline expects to take a lot of new grads you may need a different approach.

However in my experience questions like "How would you architect a replacement of Amazons S3 service with similar durability" or "Given a smart grid reporting metrics from every home in the US how would you store this data for analysing both long-term trends and intra-day anomalies" yield by far the best signal to noise ratio.

> It should be obvious from my Github and general OSS contributions I can code and do meaningful things but sometimes I just can't code on-demand.

This isn't obvious at all - I've interviewed many people that have faked their GitHubs or were just completely incompetent at software development despite their amazing GH, OSS profiles or CVs.

People lie, a lot. I'm sorry, but having "a profile" isn't a useful signal for an interviewer :(

> However in my experience questions like "How would you architect a replacement of Amazons S3 service with similar durability" or "Given a smart grid reporting metrics from every home in the US how would you store this data for analysing both long-term trends and intra-day anomalies" yield by far the best signal to noise ratio.

Agreed, in my experience these questions give by far the best signal for a good coworker in general. Sadly they're not appropriate to interview junior developers.

Umm. It's very hard to fake actual contributes to actual OSS projects. You might be able to fill your GH account with crap that might fool some people into thinking you have a "profile" but when you say you are "Committer to X" or "Contributed X feature to Y" then that isn't fakable and is the only stuff I look for.

So yeah, it might not be useful for recruiters/sources that don't understand the technical side deep enough to evaluate but it 100% sure be good signal for an interviewer if they know the fields and projects in question you are hiring for (they probably should...).

I was often shocked by this as well, until I did an interview where I was asked a similarly trivial question, and I became that person. I completely flubbed the interview, locked up, and, whilst I could write code that did things, I just couldn’t wrap my head around the question, and no amount of effort would chill me out. Obviously I didn’t land the thing. Some things like fizz buzz are gonna be so trivially easy that anyone should be able to do it, but try to understand where your candidate’s headspace is.

(I was also a TA in a course that did these sorts of trivial challenges, and going through that experience really made me take a hard look at how I perceived those 1st year students)

I proposed to my manager (although this proposal was rejected) that we try something like putting our high performers through our interview loops. This would let us calibrate our questions and answers. If you're right, that intermittently otherwise good candidates flub simple questions, I feel like that would come up in the test interviews - and maybe there could be a good compromise that somehow takes this into account.

Unfortunately, I think that whilst it's a good idea to run a few mock interviews with "known good" people who already work well within the company, I also think that you can't replicate the stress that a potential candidate might feel where the stakes are non-existent, and a rapport already exists between interviewer and interviewee.

A good rule of thumb I've heard is that for an hour interview, you should expect people that work for you to solve and complete it in about 20 minutes. If it takes them longer than that, the question will be too difficult for candidates once stress is factored in.

I’m pretty sympathetic to this. Anybody, me included, could definitely lock up. Who hasn’t had a day where their brain refuses to work.

But the thing about interviews is that you always want to heavily bias towards false negatives. A single bad hire is just astronomically costly. I think it’s fair to say that many smaller companies have literally been bankrupted by one incompetent person. When it comes to engineering positions, this is especially true.

I’d rather nuke 20 good candidates having a bad day, then risk letting one bad engineer through the door. That’s why I’m skeptical that the interview process can even be “fixed”.

Fundamentally it’s a mis-alignment of incentives. Employers have very strong to rule out candidates at even the slightest hint of incompetence. But for the interviewee, being judged so quickly, harshly and unfairly on a such a personal level makes them feel vulnerable and hurt.

I've found that when an interview question seems too easy, I'll think "What's the catch?". That can start me down a spiral of wasting time and energy wondering if I'm missing something.

"A list containing the most frequent character."

There's only one (not counting ties), so you want a single-item list? Or if 's' is the most frequent, because there are 5 of them, do you want [s, s, s, s, s]? Or since the list just needs to contain the most frequent character, seems like [r, s, t] would be correct as well. Now that I think about it, just returning the original string would have to contain the most frequent character. Also, do capital and lowercase of the same letter count as different characters?

Just seems like a rather unclear directive.

Yes, it's supposed to be unclear because I expect the candidate to clarify the requirements. Jumping in to implementing something would be a bad move. Asking questions like these would be a good first step.

I think of it as the FizzBuzz version of getting requirements for the thing you're supposed to be doing.

>Jumping in to implementing something would be a bad move.

I would expect a skilled programmer to be be able to make intelligent inferences about the intended behavior in the face of ambiguous problem statements. FWIW, I would probably explain my reasoning as I went -- would you interrupt a candidate to say you'd rather see a different behavior (ex: my prototype would return a list with an empty string, but maybe you'd rather an empty list), or just silently judge them? Also, it look me about 2 minutes to produce a reasonable prototype -- maybe if the challenge were harder I'd expect someone to ask more questions up front, but in this case it's trivial to iterate.

If the only thing you are testing for is the instinct to clarify unclear requirements, you'll surprise people who are used to the leetcode-style, thereby getting false negatives. It's just as much a trick question then, just in a different dimension.

Oh, I hate this. I get your point but as a potential new hire of your company I'm also interviewing you. This means that if you state a problem in a very ambiguous way (like you did in your first message) that's already a red flag for me. Sure, I don't expect 100% accuracy in your problem statement, but I don't expect either lazynnes for the sake of "let's see if the interviewer asks good questions before implementing anything".

Expect professionalism from both parts.

That's fine. I don't think every job is a fit for every person or vice versa. Your reaction is a positive one for my question - if you don't want to work where you have to clarify ambiguous requirements then you wouldn't want to work for the company I'm at, and it's best we figure that out as early as possible, like in the phone screen.

Both sides have a point. Perhaps your parent runs a shop where ambiguous requirements are one of the biggest problems they face, whereas you prefer to work in roles where the requirements are already established and you focus on working within them.

Alright so give me the damn job! Covid has screwed me over, I'll start Monday

I write code like this all day long and the way you phrase the question might have stumped me.

First, I would feel like if I have to ask questions if you then I’m missing something obvious you want me to be able to deduce. And if I take too long I’d fail your test.

So I’d jump in merrily and work up a quick and dirty version before even realizing that the output has ambiguities. Hopefully at that point I’d ask how you want them resolved, but maybe I decide you want to see me to make my own decisions and I’d come up with my own way to handle them.

I dunno, I'm sympathetic to interview questions being weirdly hard cause of the stress, but that question would be something I could solve in less than 60 seconds in several languages. I think it's fair to expect people to ace it without difficulty.

Earlier this year I had an experience where I was the interviewee in the situation you describe, and it was very humbling.

I had just received offers from two FAANGs, and I was flown into the Bay Area to interview at a third. One of the interviews was mostly behavioral, with 20 mins at the end for an algorithms problem that I had done before on LeetCode. I did so badly that after 20 minutes the only thing on the whiteboard was the problem statement. I still remember the interviewer taking a picture of it, and me kind of cringing because of how bad it looked. I didn't get an offer, unsurprisingly.

A thing that happens to me is that, even though the problem is not hard, the interviewer attitude puts me off. More often than not the interviewers are arrogant and act like they don’t want to be there - and the make sure I am aware of that. That is enough to make me get things wrong and fail.

That doesn't seem like a fair restriction to put on an interviewer to me. I'm just supposed to assume the candidate knows how to write code rather than ask them to demonstrate?

I imagine if I was hiring someone to play in a band or sing in a choir it would probably be a good idea to ask them to play or sing a bit before extending an offer. If I was hiring someone to work at plumbing company, I'd probably ask them a "How would you fix..." type question or two.

Saying that these questions are forbidden just because you are sometimes tired of doing them strikes me as unreasonable. While, of course, you get to decide what signals would make a company a bad fit for you - e.g. if I asked you my question you might think my company would be a bad fit for you, the interviewer decides which answers are a bad fit for the company. I would definitely take an answer like this as indicating a bad fit for the company.

This line from your comment is interesting to me though: "I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed". I frequently ask questions where I expect the candidate to want to clarifications or challenge what I'm saying. That's part of my job, and I'm trying to test for it the best way I know how. If you're happy with your job interviewing performance, then more power to you, but if you aren't - you may consider changing how you think about instances where the interviewer is wrong. Perhaps they are presenting opportunities for you to engage with them in a productive way, and even if they aren't doing so intentionally, maybe they are doing so unintentionally.

> Saying that these questions are forbidden just because you are sometimes tired of doing them strikes me as unreasonable.

You know what's unreasonable? Interviewing a bricklayer and asking them to describe how they lay bricks over the phone. And this is why your comparison to singing is hugely flawed. The phone is literally designed for carrying and hearing voices, not for more complex things.

You act as if it's literally impossible to figure out if someone can code unless you're trying to do it over the phone.

> This line from your comment is interesting to me though: "I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed". I frequently ask questions where I expect the candidate to want to clarifications or challenge what I'm saying.

I once had someone ask me what _type_ was returned from a controller in asp.net MVC, and when I gave the technically correct response this person told me I was wrong, a view is returned, then immediately ended the call. The number of times I've seen stuff like this happen is way too high.

But more than that, I want to address the attitude in that last point. This is a _HUGE_ problem with interviewers. They often come to conclusions they ought not come to based upon the circumstances. And the defenseless interviewee's are left trying to suss out hidden requirements like "expects them to ask clarifying questions". Interviewee's come in and have to try and navigate these byzantine, hidden requirements. And the question is, why do interviewers have hidden requirements like this? Because they know if they're _HONEST_ and communicate what they're looking for, the candidate will give it to them. That by itself should be a wake up call that interview's are hostile and un-real.

I'm just in a position in my career that I have the leverage to refuse to play those games. If you do something like that, you fundamentally have no clue how to actually hire people, and I refuse to bring any value to you or your company.

Honestly, have neither of you heard of coderpad? My screens are like the GGP's question, except both I am the candidate are on the phone and on coderpad. Coderpad even had voice and video calls now. The candidate is free to Google, to use the repl, to use any language, etc. If the candidates wants, they can just share their screen in their own environment.

But asking a candidate for 30-50 lines of code is completely normal.

Yeah, we use a tool like this. I agree it would be crazy to ask someone to code by voice over the phone, I assumed it was given that we were using a tool that let them write and share code.

You act as if it's on the person interviewing to set something like that up...

No they're not, you're both talking past each other. You're talking about phone-only interviews, but I don't think ALittleLight is even seeing it because that's such an obviously stupid idea it couldn't possibly be what you're talking about, so they think you're complaining about having to code.

I've literally had people ask me these types of questions while on the phone. And I "fail" on purpose because I won't attempt them. That's the point.

The fact that the internet exists and the interviewer could have used an online utility doesn't change my responsibility in that equation, that's just nuts.