What can I learn from dumb feedback on interview rejections?

[grldd]

It's pretty hard to get feedback when rejected for a job. But sometimes it happens and in my case at least seems to be very dumb.

Some examples:

- "your code is correct and it does what we asked, but the way we write code is different"

- "you have the fundamental skills required for the role and have experience in a smaller company, but you don't have experience in a large company"

- "I don't think you would be happy in this role, I see you more of a <random_role> instead"

I almost never get feedback that I didn't have the skills. It's always some variant of I have them, but <reason>.

Any advice?

[victorstanciu]

> Any advice?

Introspection. There's no way to force the companies to tell you the actual reasons they decided to pass on you, so the only avenue left is for you to think long and hard about what you think those reasons might be.

I hope you don't mind, but I checked your (short) comment history, and you seem to have a lot of contempt for the companies you're interviewing with, both in terms of the products they build and their culture. Maybe some of that seeps out into the interview process and they're picking up on it?

[grldd]

It's only frustration with the job search.

[nonrandomstring]

Don't take any of it seriously at all. Part of HR process is sometimes to "be seen" to be giving feedback. This isn't like college where you're being marked on your presentation.

In reality someone gets tasked with the job of basically making stuff up, or sending out stock replies with the same words to everyone. If you were to take it to heart and try to change you'd become a perpetually unhappy and frustrated "pleaser".

I've interviewed many dozens of people and all one can really say is you know why you picked the one who was right. Rejection feedback is awkward for everyone, which is why so many firms just ghost you after the meeting.

I also think the sibling comment is very wise. Don't apply to companies whose values you disagree with. A successful interview should not be a deceptive act to break-in behind enemy lines, it should be like two lovers meeting for the first time. :)

[brudgers]

your code is correct and it does what we asked, but the way we write code is different

My take is that your code doesn't account for time, space, or IO. It will solve trivial examples, but doesn't consider what needs to happen when the data gets to an interesting size.

There's the Kaggle trap where the problems can be solved at the formal level with advanced Fizzbuzz. But the engineering issues are when the data is too big to fit in memory.

This is also how I take the the second example.

Good luck.

[Rounin]

#1 can perhaps be taken at face value. People do write code differently, and many people don't want to even touch code written in a different style. Learning how to write code in someone else's style can be interesting and rewarding in the right context, but working with someone who insists on having everything done according to their preferences very often isn't, so your mileage may vary here.

#2 is a well-known problem that a vast number of people have run into - You have to have a job to get a job. The best advice I can give here is that getting a job through someone you know tends to be the most effective way, having an online CV and having them call you sometimes works, and actually applying to jobs is usually a dead end, but not always.

#3 might mean that they would like you to do that job instead of the job you originally wanted, but they phrase it as something that would be in your interest, since that's what they learned to do in middle manager school. If the other job is more interesting and pays more, then fine, but what are the odds of that?

[throwaway4233]

Based on the comments you have shared and the limited context I have, I believe that they understand that you are comfortable with the language and can build feature X if it is what is asked of you. However based on the `large company` emphasis in one of the comments, it could be because they expected your code to be maintainable, extendable or because it might be even lacking tests. In case the code you showcase meets the above given the time constraints you have, then move onto your next interview and do not worry about it. There a lot of factors involving interviews that do not relate at all to you and you should try not to be bothered by advice(white lie) that does not provide any value.

[yakak]

It sounds quite possible that you have a lot of experience and if you have a better way to do some things it may cause them to have to change or threaten their authority..

You could try pre-investigating companies with very different methodology and let yourself make mistakes because you genuinely don't know their methodology.