On the unreasonable reality of “junior” developer interviews

To me, this question (conform to List<T>) only makes sense as in interview question if some hand waving is allowed.

My instinct is that the question is intended to accomplish two things. First, they want make sure whoever is taking the test has to implement a linked list that works more generically for whatever object is stored, rather than just for ints, strings, and so forth - so they're going to want to see object comparison.

Also, they want to see if the candidate is aware of how to implement an interface. So implementing a few key methods would be a good demonstration of skills.

That said, my instincts have certainly failed me in the past. I figured that a big of hand waving and an explanation of the data structures to solve a problem, along with some code, would be good enough for technical interview, and I have been rejected - companies can't give too much info because of possible lawsuits and so forth, but I have been told that I didn't make enough coding progress on the technical interviews. So eh, maybe they really did expect this, I couldn't say.

On another point - I'm not really outraged by much, in terms of hiring policies. I mean, it's bad to waste people's time, but in general, I'm OK with companies having high standards and tolerating a very high false negative rate, if that's their choice.

What I can't stand is the constant complaining about how hard it is to hire from companies that do this.

Common interview outcomes: "Can the interviewee ask good clarification questions?" and "Can the interviewee break down a project into manageable pieces?".

Especially important for bootcamp grads, they need to know what they are capable of. They spent the last 12-16 weeks working 12-hour days, but that is not healthy for a person or for a company. As an interviewer, I need to assess if they can break down projects and understand how to identify an MVP with flexibility for further iterations.

That's what a question like this is about.

I think the purpose of this kind of exercise is not to have the developer implement the whole class, but rather see how far he can go, how he can prioritize the subtasks and how he deals with pressure. Of course the result also gives an idea of its programming skills. Not that I agree with the method though.

I think it is correct that it breaks down the candidates confidence. This exactly happened to me, I have a computer engineering degree, was a very competent programmer as far as my courses were concerned. I ended up taking a job in Product because of how difficult some of the interviews were, I wasn't sure my programming skills were up to snuff. I have been working on personal projects in my free time to keep my skills and think I might give it another try at some point.

I don't think the expectation was for the candidate to get through the whole thing- More to see how much they could get done in a deadline (30 minutes). Its a good method to see what a developer values in an implementation- Do they take an as many as possible, or do they spend a little more time on each one? The interviewer should have made that clear though.

I don't see a problem here. When asked to implement the interface, you don't have to know and implement every single method off the top of your head.. Sounds more like an opportunity to discuss what operations are important for the use case and implement a few.

"I’m pretty sure nobody can implement a List<T> linked list in 30 minutes. "

Absolute rubbish. Checkout the monthly challenges on hackerrank. You have an hour to implement 4 problems, and none of them are as trivial as implement this datastructure you learned and used in school.

The unreasonable reality of "junior" interviews however is people shoving the words "we work at startup pace" in your face, but suddenly going silent when you tell them what compensation you expect.