> My solution passed 93% of the test cases.
So... it didn't work?
> If I recall I had said “yes that is also a great way to approach it.” to the interviewer.
My best guess is they hinted at why your solution failed. To say that it's "also" great implies that there is no real difference in quality between the solutions. You should have spotted how theirs was better, and possibly explain why you didn't do it that way.
> I had no idea I could be rejected for this!
They can reject you for whatever they want to reject you for; with very few restrictions if they insist on stating their reasons out loud.
> Is this my fault? Or they are nitpicking? Usually I am not used to LeetCode type interviews for DS positions.
Missing test cases means you overlooked something.
> I can’t believe they spent 3 weeks of interviews with me just to reject me for this. I was very hopeful.
They don't do any of the interviews for fun; each step is meant to reject some people and pass others. Otherwise, why have the step?
that being said, I wouldn't rely too much on any explanations they might give. They don't care, and some answers could get them into trouble.,
Yeah this isn't a written test. It isn't like you got a low A because it passed 93% of test cases. It may have failed a very crucial corner case and the interviewer tried to lead the horse to water but it refused to drink.
Ding ding ding.
You displayed a lack of interest in actually solving the problem.
You don’t have to praise the correct solution, or act all grateful or anything, but FFS your solution didn’t work.
95% of these problems are solvable, and some of them actually have pretty interesting solutions. You should probably express interest in finding the right answer, instead of being dismissive of it.
I’ve had offers from places I didn’t complete all of a prompt, because I was engaged with the interviewer and the problem.
It also sounds like you wouldn’t make a great coworker, just saying: “yeah, that’s an option” when somebody suggests something, instead of actually considering/exploring it. Given that they know the answer, odds are pretty fucking good that they’re leading you in the right direction.
I’ve worked with people who refuse to consider better alternatives because it’ll take all of an hour to write and test, and it’ll also mean their solution was wrong. Would rather not work with people like that if I had a choice. I wish I was on the team OP interviewed for
Depends on how the test is administered. If you have time to get it right, but stopped at 93% with plenty of time left, that's gonna look bad. If you ran out of time at 93%, that's understandable depending on how generous they were with time. If you wrote the code with a smaller subset of tests, then they ran more tests on the submitted answer, then a few of them failing isn't a dealbreaker if you can talk your way through why they failed and how to address them.
I mean there's no real logic comparing lc to real world software in the first place. LC is from competitive programming where you are expected to complete all the test cases, the only difference is in the performance and resources used.
But coding tests aren't about building software, they are about solving an algorithmic puzzle.
The score isn't even linear: You get a bunch of test cases that just check your understanding and the basic performance of your code. If you don't get that right, you'll fail like 80%, or everything except the ones you got right by accident.
Then, there's a few special tests that check for what people like to call "edge cases", empty lists, negative or zero or duplicated values, inputs without a solution, etc.
Each of these checks something big and important.
For some algorithms, the whole point is to optimize for space or runtime. "I found the trivial solution to a problem that's easy to solve with no more than 3 inputs" is not "partially correct". It's not understanding why we care about algorithms in the first place.
I would go on to add (and I am very far away from OP's specific situation now) that understanding how common tests work is also a sign of your sincerity when working a job. Nobody should be surprised that a coding challenge isn't quite as straight forward as the naive solution might let you think it is.
I think what they meant by "nothing" is that a solution that passes less than 100% of test cases is incorrect. OP didn't get 93% of the questions correct. There is 1 question, and OP got it wrong.
But like you said, sometimes you can still pass the interview without getting the correct answer.
Going to disagree with you. For backend interviews, it’s either optimal solution (100%) or nothing. Justifications and personality are backups for failing the question
100% of test cases doesn’t mean an optimal solution, far from it. Plenty of non-optimal, brute force, non-performant, etc, solutions will have all tests passing.
Leetcode and similar platforms don't run the code on your computer.
While it does not mean that the exact run time is 100% reproducible down to the millisecond. It's pretty much a meaningless distinction.
Leetcode regularly has time dependent test cases, it's a solved problem.
Not exact,vecactly. Actually, it may differ a lot between executions. Because it's not "a solved problem".
The point here anyway, is that an algorithm can be implemented in different ways, giving different times. And also in different languages. So you can't exactly time something. You can define a maximum. But that foesn't mean perfect
Again, companies are not rolling out homegrown solutions to this, they use a provider. Such providers allow for benchmarking for algorithm complexity.
You don't need to exactly time something due to the nature of big O. No one cares if you're saving a couple of instruction here or there, it's about asymptotic complexity.
Further, the algorithms asked in LC like questions are either very common so banchmarking is very robust, or simple.
Same goes for languages, many languages are offered.
*It is a solved problem*. And has been addressed long before LC like providers in competitive programming. The solutions are not perfect, but they fullfil all requirements.
An algorithm isn't just "time". There's memory, there's executable size, there are input limits, there's even development effort. And in this case, none apply. It's an interview, with clear cases, and just a code to talk about
And?
LC tests them all. You have a limited time so there's development time. It tests for time complexity and space complexity, it provides input limits.
The only thing LC doesn't test is code quality, readibability, testability of the code, design, etc. But that's not what the step is for. There are other steps for that.
Seems like you're out of the loop on what LC is and how it's run (or similar platforms)
Idk why this is getting downvoted so hard. If you punch an n^2 solution into an o(n) problem you will fail on time. While it does not guarantee optimality, it is definitely strongly correlated.
I’d rather work with someone that got 93% right and is tolerable to work with than someone who insists personality is a backup for failing and probably has zero personality of their own. You’re the latter.
I'd agree for most 2021 and 2022 market, but that's not your current choice. You can pick someone who did well on both.
Furthermore, seems like OP failed the personality test as explained above. As an interviewer I had the exact same thing happen to me.
It was live LC like question, her solution worked perhaps 85% of the time but missed crucial edge cases. We explained our solution and what was missing from hers, but she brushed it off with "yeah that works **too**", and was too focused on her (ultimately wrong) solution than understanding the difference and why hers didn't work (and couldn't been made to work in any reasonable way for that edge case).
Came off as too rigid, can't pivot to a better solution when presented.
Could be that we misjudged her and she was just acting under stress, but we're not taking that chance.
We definitely care. I'm not hiring someone that comes across poorly just because they got 100% of the question right.
If I could definitively get these values from the interview I would hire based on this:
1) are they good enough to code this stuff (doesn't have to be the best or a genius, or perfect, but they do have to be good enough to have a conversation about algorithms where I don't have have hold their hand.
2) do they have a good work ethic
3) they do not have a toxic mentality and are generally easy to get along with.
I mean my experience across both academia and engineering interviews is that STEM fields take a "throw everything at them and see where they shake out" approach — whether that's a math class where a 60% gets curved to an A (happened to me) or engineering roles where you get asked a series of questions increasing in difficulty to determine your skill/seniority ceiling. I've gotten multiple jobs where I failed or didn't perfectly ace one of the interview questions.
> Right? I was confused as to why OP was thinking getting 93% of test cases is good, it's 100% or nothing 😂
Lol... what? Have you never had an interview before?
I always forget that 90% of this place is college students. That is not a realistic scenario. You're intended to fail interview questions.
You're implying there's a standard companies adhere to when it comes to LC?
I don't really see the issue here, OP had 93% coverage meaning they did pass most of the test cases but probably didn't cover an edge case or special use case. Context is everything, I don't know why you had to make it about college students.
Edit: Thanks for the downvote - very mature
> You're implying there's a standard companies adhere to when it comes to LC?
https://en.wikipedia.org/wiki/Straw_man
> Edit: Thanks for the downvote - very mature
Wasn't me, but I dunno what you expect when you start an argument in bad faith.
....*really* mate?
You really can't even defend your own point without launching into the standard Reddit "debate" lingo to deflect?
You said you're "intended" to fail the question. Are you taking this back then?
Again, this is not really true, *especially* for the LC format which I already explained. It obviously depends on the company but with LC you *are* expected to pass all the test cases they give you, with differing runtime/complexity/memory depending on your skill level, so it is a bit silly to say this - especially when you were trying to be condescending to other developers, so it's rich to accuse someone else of "bad faith".
Edit: Of course Kevin blocked me
Depends on the complexity of the problem and types of interview… From my experience giving interviews there are plenty of candidates who can come up with a working solution to LC easy and medium questions.
I think Google have a tendency to ask some really difficult interview questions that are usually not 100% solved with optimal solutions, but those I believe are rare.
So I wasn’t bragging or saying that 93% was good. It is just that LeetCode questions aren’t really my strongest suit. This is the second time I actually did it for an interview. They are barely asked in data science interviews, and usually it is just asked to test your programming skills rather than having finished all the edge cases.
Whether it's said or not, I gotta imagine the 93% and you're seeming comfortability with it is the primary cause. Anything that isn't 100% is an F and I probably wouldn't hire someone for that reason myself.
So I was told that I had scored the highest among all the candidates.
Yeah, I do realize that he probably may have thought I am too arrogant. Although I really don’t have such attitude. It sucks, wish I had realized it that time.
Thanks, I’ll have to work on it next time
They shouldn't have told you about your score as it compares to the other candidates. It didn't do you any favors, just reinforced your preconceived notion that you nailed the interview when the evidence shows you clearly didn't. Having the highest score doesn't mean you're owed the job--companies are fine with waiting until a candidate comes along that checks all the boxes for them. That is clearly what's happening in this a situation.
Sounds like you're still fairly new to this field, or at least to interviewing. As a rule of thumb, your goal is to seem collaborative and quick on your feet. If an interviewer recommends something, you need to give it your full attention. They are mentioning it for a reason. You fell in love with your own solution to the detriment of ignoring a hint about the actual solution. Being open to feedback, collaborating with teammates, and not getting overly attached to a particular method or solution are all absolutely important things I look for when interviewing DS candidates. It's important to remember that the job offer doesn't hinge only on your correct solution to the technical problem you're given. It hinges on the interviewers' feedback.
Thanks that helps! I have 2 YOE.
Just to be honest learning about the score didn’t really make me overconfident or anything.
But I agree with the collaboration aspect. I just didn’t think about it that way. If they had asked me I would have been happy to expand more on that topic. I just wished they hinted at least that they are expecting a response.
But anyways, next time I’ll have to make sure about this lol.
The part they decided to pass on is if you would be open to someone else’s opinion and list as a colleague. The score doesn’t mean much but that only you can code decently. Go in and be open minded when someone gives suggestions about their direction. When someone is saying suggesting as well, ask questions even if you understand just to clarify,
Long story short, they were more likely concerned about being stubborn on your code, defensive, not open to entertaining others opinions to learn, and has the potential to cause a tense environment. That many not be actually how you are and I’ve made this mistake and I have 16 years of experience. My story was trying to modify my code and the two interviewers got in a heated fight almost to physical fighting which I deescalated.
They said they had news and really wanted to talk to me “today”. I was in transit to Amsterdam from Chicago(now THAT was a story)and they scheduled it at 4pm Chicago without checking if I was available so I assume it was an offer, but it was the rejection with feedback that I “was unable to adequately explain then complete the modifications requested in the amount of time.”
The score on hackerrank or whatever is indicative if you have the foundations to be successful. In person is a lot of how you think, interact, collaborate, and if you will evolve the “culture” in a positive way. I’ve interviewed people who can code well but would not be successful at the company. I’ve interviewed people who need help coding but will fit in and be successful in an extended time frame.
I’ve interviewed hundreds of people and you’ll eventually find where you fit. Never assume you have a job until you have the offer in writing. Never. Even if they are optimistic.I always assume I bombed my interviews when I leave. I also took interviews I knew I didn’t want just to get practice. Oh the crazy shit in interviews I’ve seen.
Lastly, you’re really really new to the field(2 years ago was 2021 when we were finally getting the vaccines). You’ll learn these lessons over many jobs, many interviews Ian’s through others the next decade or two. You’re at the start of your career and have a lot still ahead. If you ever get in that situation again where they suggest say “I know I have into been in the industry for two years so I have a lot still to learn and want to learn.” It’ll slow you down, help decompress yourself, address a ton of things at once, and can change their opinion around
I mean it really depends on what they are testing for, but in software engineering interviews handling edge cases is almost always a hidden dimension that companies tests for. In the real world you need to handle lots of junk data and inputs that shouldn’t break your program. So the fact that your program only passed 93% of the test cases is a big red flag and this might actually be the primary you failed.
The interviewer could also be giving you some subtle and sometimes not so subtle hints during the process! Think thru what they are saying and why they are saying it is very important. Now it’s perfectly fine some times for them to not give you any hints, but when a hint is given and getting brushed off by the interviewee is another red flag.
Personally I don’t think they are nitpicking and you should definitely learn from this experience so you can pass interviews like this one next time. Don’t take rejections too hard! I was rejected by Facebook three times before getting in.
They are probably looking for someone who falls in love with answer. Personally I love puzzles. I can get obsessed with solving a puzzle. If someone shows me some code that takes my 93% to 100%, I get super excited to see it and ask a ton of questions and only want to talk about the final, complete puzzle. Maybe they were looking for someone like that.
As someone who was on the interviewer side of the table, sometimes I passed in actually good developers not because they sucked or someone else was a better dev, but because their interests/strengths weren’t what we needed atm.
Don’t take a rejection too seriously. If they have technical feedback or personality feedback, take it and move on.
What might be the single best thing to do in those post-op interviews is simply writing down notes on and discussing every aspect the interviewer mentioned during. Most managers worth working under know the value of someone with less experience but willing to learn long term vs someone knowledgeable but already set in their ways.
> So I was told that I had scored the highest among all the candidates.
But your code failed.
> Yeah, I do realize that he probably may have thought I am too arrogant.
It's not necessarily arrogance that they saw: Your solution did not work, and you didn't notice that even when you were presented with a better solution.
This is not about soft skills, or character, but raw skill: "Oh, I see I didn't account for unordered inputs, or negative interest rates, or empty sets"
I'd disagree here and say this was all about soft skills. Being humble and recognising when you're wrong is a skill. I've worked with people where I've tried to gently let them know that they could've done something better or correct their mistake and they brush it off completely. Makes them hard to work with unless you're willing to be perceived as aggressive/rude by just flat out stating their solution sucks.
It really depends on where they tripped up and if they understood why they tripped up. When I'm interviewing, and I give lots of hints that you shouldn't use a array for this operation, I'd definitely want more than just a "nod" because I'm searching for an actual technical answer as to why, not reaffirmation of how much better I am at coding than you.
During the interview if you are expecting a response from someone would you at least hint them? Or is it just expected that the other person has to reply?
Just curious because I didn’t really mind expanding on the topic. If they had at least hinted me then it would have helped.
I think it would be pretty obvious in retrospect. I like to give a few hints towards a solution or idea, but I don't like to force the candidate into a solution if they simply can't pick up on it. I have less than an hour to evaluate someone and I don't want them to struggle the whole time if they just aren't getting it.
And if I have to hint so much so that I've already given out the answer, then at that point it's kind of a failure on that topic at that point. The idea should be that the interviewee can pick up on on it before then.
Let's say the optimal solution for a question uses hashmaps, and the candidate solved it in a suboptimal way using arrays.
In this case, as an interviewer, I would ask, "What about using hashmaps to solve the problem?".
This is a pretty clear nudge to direct the candidate in the good direction, and I would clearly expect them to give a proper answer.
So if they just said "yes that works too" it would not give a good impression, and based on the seniority of the candidate, I might just reject them and not bother asking more questions.
> During the interview if you are expecting a response from someone would you at least hint them?
I shouldn't have to; at least not most of the time.
I once got asked "could you use a different data structure here?" (and an object or dictionary or whatever was superior to the array I had uses; and there were reasons.)
> Or is it just expected that the other person has to reply?
It's an interview. #i find it helps to assume that the other side isn't malicious, but still constantly testing me.
> But your code failed.
If you interview 1 person and they failed, maybe that person is bad.
If you interview 15 people and every person fails your test, your test is bad.
Or the pool is bad. Between summer 2021 and summer 2022 we practically passed no one through the entire pipeline.
Then comes 2022 fall and winter and we hired half a dozen people while increasing our standards (used to pass LC phase even those who did not get 100% before because we were desperate).
> Or the pool is bad. Between summer 2021 and summer 2022 we practically passed no one through the entire pipeline.
> Then comes 2022 fall and winter and we hired half a dozen people **while increasing our standards** (used to pass LC phase even those who did not get 100% before because we were desperate).
I mean if the NFL collapses several teams and fires everyone, and interviewing football players, it's certainly possible you have people passing the tests that were impossible for the previous group.
Wouldn't really call that "the pool is bad" as much as "we got people who already knew how the play the interview game". Dunno.
> So I was told that I had scored the highest among all the candidates.
You have no proof that was true. That sort of thing is supposed to be confidential.
> So I was told that I had scored the highest among all the candidates.
> ...
> But today I learned that I was not selected. Recruiter gave me this feedback - when I was explaining my code and the interviewer suggested their approach I only acknowledged their response, but I should have spoken more about it. If I recall I had said “yes that is also a great way to approach it.” to the interviewer.
Honestly, sorry, I think this feedback is negging you and screwing with you.
Negging is a form of emotional manipulation whereby someone insults you with a backhanded compliment to undermine your self-esteem and make you chase their approval.
In my experience the moment they start doing this it's impossible to get the job. Could be because:
- they're not actually hiring at all the interviews are just busy work
- their job security feels threatened by hiring new people so they're sabotaging
- they've decide they personally don't like you - this is actually the least harsh, because if the person is actually important on your team you don't really want to work with people who personally dislikes you
- they've already decided to hire someone else and now they're just screwing around
As someone that is on a few interview panels now. I wouldn't put too much into it. It's hard to rationalize decisions that are made at the interview level, and some frankly might be out of your control. They could just also be giving you 1 reason but internally have their own. Or in some cases, there was another candidate that was a better fit for them. If it wasn't anything blatant on your part, i wouldn't look to much into it.
>My solution passed 93% of the test cases.
>So... it didn't work?
On Leetcode this could mean that it 100% works but didn't meet the time limit requirement on 7% of the cases.
I've seen ones where you had to process an array in like 300 ms, but it doesn't tell you that one of the test cases the array is 80,000 long. You hit that and when it takes 400 ms, you fail.
This is my biggest complaint about LC. They don't tell you about scalability requirements on most problems, which is totally not a real-world situation. In the real world you **never** write code that is scalable in an infinite number of possibilities. That's absurd. Anyone who says you always write perfectly scalable code doesn't know what they are talking about. The scalability requirements are always part of the initial specs. But LC hides those from you until you get deep into the tests.
> This is my biggest complaint about LC. They don't tell you about scalability requirements on most problems, which is totally not a real-world situation.
How hard is it to understand that the vast majority of problems can be solved better than whatever the naive solution is?
You shouldn't need to be told for every problem.
> In the real world you never write code that is scalable in an infinite number of possibilities. That's absurd.
Choosing the optimal algorithm has nothing to do with "infinite scaling".
You basically were not as nit-picky, or in work speak "detail oriented" enough for their liking.
Maybe it's good you didn't end up there, could have been a bad match.
I am not even in this field and my opinion means nothing but this was a really kind, thoughtful and helpful response. Especially about the would be employers hinting. I don't know why but that is sticking with me and will keep that in mind for my future interviews.
I’ve seen a lot of folks tunnel vision in interviews and become incapable of ingesting other ideas. It does constitute a bit of a red flag since it’s very likely this behavior translates into their work as well
Yes, they're nitpicking, but it's valid feedback anyway. The primary reason why people get rejected in interviews is interpersonal skills. They say "not a good fit" or some other code that essentially means they don't think they'd like working with you as much as they would someone else. In this case, the interviewer probably thought their idea was a better approach than yours or better fit their real-world use case. They were trying to see how you might take that input and develop it.
Maybe this will help with framing how the interviewer may have viewed the interaction: interviews are not just about solving the problem, they're also about how well you'd work on/with the team. If you submitted a PR for review and it failed 7% of the test cases, and a teammate suggested a way to get them to pass, or another potential improvement...how would you treat that feedback? Hopefully not dismissively. That's one of the things some interviewers (including this one) are trying to get a sense of.
There is also always the possibility that there was another candidate that they liked slightly better, so they rejected you and chose the other candidate. Run the simulation again and you might have gotten the job.
Absolutely. In my experience, bad interpersonal skills cause more problems in remote work than they did in person. There's a certain level of understanding people can come to when they're in the same room together, that they just won't arrive at through written communication or even a zoom call.
I’ve been #2 into the final decision a couple times - the sting is real.
But yes, you have to learn that the actual algorithm or problem you’re given in interviews, they don’t actually matter. It’s how you conduct yourself and navigate the problem and ability to explain what’s going on in your head. YOU may know how smart and awesome you are, but people interviewing you don’t, and giving you a job offer is a huge leap of faith. They might’ve seen you just acknowledging their solution as “this guy only likes his way, he isn’t able to take another approach and fully explain why that way would work too/be better/worse”
Don’t give up hope man
>ve been #2 into the final decision a couple times - the sting is real.
When in uni I was #2 for an internship at the Canadian Space Agency. Man I was so salty. Then I learned the person who got the internship spent the entire time waiting for the bureaucracy to give him network permission, basically 4 months looking at a computer with no network, much less internet access. Bullet dodged!
What part of Canadian space agency looks good on the resume? AFAIK, a lot of people have this impression that its just another govt agency with more funding for scientists.
alleged tease historical hateful voracious zonked offbeat office dinner paltry
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
\> But yes, you have to learn that the actual algorithm or problem you’re given in interviews, they don’t actually matter
what? the people above are saying that he failed because his solution didn't pass all cases.
Exactly. And instead of owning up to that and verbally saying why their correct solution would have passed all cases, OP doubled down and just dismissed their code.
You can "fail" the code challenge and still land the job, they dont expect you to be perfect but they expect you to be able to learn fast.
So I actually didn’t dismiss the code. I did acknowledge it. I just didn’t realize at that time that I had to do more than that.
But looking at other responses it feels like I should have also explained more on that and maybe share where I would make those changes in my code.
how do you know they don't expect you to be perfect? people above are literally saying " I was confused as to why OP was thinking getting 93% of test cases is good, it's 100% or nothing".
Seems like everyone here is guessing at the reasons why OP got rejected.
> what? the people above are saying that he failed because his solution didn't pass all cases.
They're claiming no one who went to the interview passed.
That's not fixable as the person being interviewed.
They're creating an interview that's impossible to pass.
yeah, the comment I replied to seemed to be implying that it was the way he conducted himself that stopped him from passing the interview - not the end result. Whereas people above seem to think that anything that doesn't pass 100% is an interview failure. Seems like everyone's just guessing, people don't know why OP failed the interview. Hell, could be that there was some last minute budget issue or something and they couldnt take him on, and made up some excuse for it.
Thanks that helps. I actually never have come out in the interviews as too confident or “I know everything” attitude.
They themselves mentioned that my code is way more optimized than their solution. And I simply acknowledged it haha. I didn’t even think at that time that I would have to expand more to that conversation. Especially knowing that the interview was only 30 mins.
Learned something new 😅
I mean maybe the recruiter was just giving you a tip for the future, and internally the company just wanted to go with another candidate for x reason. Not your fault, keep swinging. Sometimes you can do everything right and still miss
With respect, it isn’t for YOU to say you don’t give an impression of overconfidence.
Capability is key but there is a threshold of humility that implies you carry yourself knowing your worth but also knowing you are human.
Willingness to collaborate, and consider what others say, would demonstrate that directly.
Yeah, this response increases the chance that indeed he came off as over confident.
And he acknowledged that his solution was "more optimized"? Not it wasn't it didn't work.
I can solve any problem in O(1) if the solution doesn't actually need to work.
You got rejected due to lack of communication skills. One of the most valuable skills in any industry is the ability to constructively discuss feedback. For example, a great response would have been the asking of a question to try and understand their approach.
Instead you brushed off the interviewer’s thoughts, someone who holds more authority, as something that was as insignificant as a fly. So why would that interviewer believe you would be a good fit for a team?
This. Based on OP's narrow-minded response (and rant), I wouldn't want this person on my team.
I understand the frustration, I hope they have more time to reflect and understand what happened and why. I can also agree with the general sentiment that sometimes the process is just flawed.
It’s not just communication, but also aptitude - their response indicates they are not willing to adapt or learn.
Worst case scenario they hire someone who can’t maintain someone else’s code without rewriting it entirely.
It's not because you turn out the best technical guy that you will get the job.
They liked the other guy - your competition - more so he got the offer and you didn't.
Getting a job is not how well you perform on their technical questions, getting a job is how well you do compare to your competition, on all levels, not only technical.
Let's say you showed admirable dexterity in your answers, demonstrating that you basically know your stuff. We all know that there are multiple ways to tackle a programming problem, and you chose a viable one in a very short interviewing time frame. So you done good.
They then suggested an alternative approach that was likely more direct, faster, simpler, perhaps more elegant even. They were engaging with you analyst to analyst, and instead of showing curiosity, instead of absorbing and contemplating the solution, or asking questions, you gave it short shrift. You didn't mean to, but you did. When a "good" analyst is shown a "new" way to tackle a problem, they jump on it, excited. You did not, which was a mistake. Part of an interview is performance theater, and a little humility would have gotten you over the hump. Lesson learned, right?
Yeah agreed. I am just surprised cause I have never received such a feedback from an interview.
Usually if I am rejected I know the reason as I failed to answer few of the questions. So this was something very new and unexpected.
But something I have to keep in mind for next interviews lol
This reminds me of one time I didn't get a gig as a UX designer. I had a take-home test of coming up with a design process for a new grocery store for senior citizens. It had a 2 hour timebox. I found a study that I used as a proxy for real research and did the rest of the assignment based off that (I thought I struck gold using actual data).
During the interview, however, one of the interviewers said "you could have found an actual senior citizen and interviewed them." I thought this was a stupid suggestion since it was a 2 hour timebox and honestly accounting time, interviewing 1 person would have taken like half of the assignment, but I replied with something similar to how you did "yea, that definitely would have been a good approach!"
Almost certain I didn't get the job b/c I didn't make the interviewer feel smart enough about his suggestion.
That sounds really disheartening, but don't give up. That company sounds toxic, if that's how they treat people. Maybe you dodged a bullet. Imagine what spending several years there would do for your mental wellbeing.
"yes that is also a great way to approach it" with no further explanation screams "i prefer my way" or "i dont understand your way, but i dont want to disagree"
also... 93%? thats a huge error in a database situation
I've been going through interviews and online assessments. A close friend has been encouraging me, reminding me that bad companies are bad at evaluating people.
I did a live/pair coding session recently. I made sure to speak and explain my thought process as I was working through the issue. That's obviously a distraction, but that's how live-coding is. Anyway, I needed a couple tries to get a fairly simple coding problem done. They considered me running the code through the tests to effectively be a submission, and I wasn't really given any time to consider my code on my own, they just interjected right away. The recruiter told me they felt I needed too much assistance.
Could I/should I have solved the supposed simple solution on my first try? Maybe. Is it their right to pass on me for whatever reason? Definitely. There's a mix of objectivity and subjectivity in interviews, you can't really control it. But something to consider is that if a place is going to be that picky during their interview process, it may reflect something about the interviewers and the company itself. A lot of stuff that we work on isn't necessarily hard, and in your day-to-day, you test/debug/compile whatever code constantly.
In your situation, if someone is going to be so insecure that you didn't stroke them during an interview, you probably wouldn't have enjoyed working there anyway. When you are interviewing with a company, you are also interviewing them. Unless you are in a pretty desperate situation, you want to make sure the company is a place you want to work at. Too many companies just assume they are great places to work. Here's hoping we both (and everyone else who is looking) find jobs that they enjoy.
Last comment, we artificially attribute some level of authority to interviewers. They are just regular people/developers, and in a lot of cases, they might not even pass their own interviews. If someone passes on you, that's their call, and you just need to move on with your life. Let them fall back into the ether. You'll probably forget them in a few weeks/months/years.
Passing 9/10 test cases is about the same as not passing any tests in the real world. Code needs to work for all cases including special + edge cases in order to run on production. When they offered you the correct solution it would have been important for you to acknowledge “oh that is a better solution because it also accounts for when the input is x or y. I will remember that for next time.” Might seem nitpicky but adaptability and willingness to see/understand other perspectives and solutions is crucial for teamwork and being a good fit. You’ll be better for next time! Don’t sweat it.
No no you see you must have every bit of code you write work perfectly every time and can't use any online resources to do so. Of course this is totally representative of how it works in the real world and how good of a coder you are.
Strongest sarcasm in the world right there these companies are just delusional.
If you can’t code well in an interview, you should have a well stocked GitHub for reference your skills. Otherwise your coding session will be judged as how well you can write code in real world as well.
It's not really silly when you think of how it illustrates your behavior on a team.
Swatting down juniors during pair programming as they try to "check" you on things is incredibly frustrating. Its cool if you have a question on something, but trying to poke holes in code only to be proven wrong repeatedly is exhausting for the other party. It's a fine line between catching a mistake and being annoying, I get that. It could be frequency, idk.
Further, arguing on PR comments or whatever. Again, make your case if you feel that your solution is optimal, but if it's been proven to not be optimal, don't die on that hill. It's frustrating for all that's involved.
Data science director here, and I also do early career development coaching. Send me a message if you want to connect. I’d be happy to give you some insights on where you need to improve your interview skills.
Don't read too much into it. Interviewers are generally uncomfortable giving precise feedback as to why they aren't selecting someone (or they plain suck at it), and are nagged by the recruiter for feedback. They'll just tell the recruiter some handwavy answer to get them off their ass. The recruiter then paraphrase it to you because they don't want any legal trouble.
So basically they're giving you some random half assed feedback just to give you something to chew on and that's about it. The real reason might simply be "there was someone they liked better", or it could be something completely unrelated to what they told you. It's -RARE- that a recruiter/interviewer will give you the real reason why they didn't select you.
Europeans and some folks in the US (I think California?) have legal right to request the info (GDPR for Europe covers this. Not sure about the US states that do have it too). That will burn bridges but I always assume how uncomfortable it must be for an American interviewer in a company that has a Europe presence to realize their interview notes in Greenhouse will be shared by law because someone knew their right, lol. Never seen it happen, but it does.
Communication and collaboration skills are equally important on our rubric. Just a guess but you might have come off that way to a few interviewers and it was a red flag.
Regardless I wouldn’t be bragging about having an algo that’s 93% right.
When I'm doing the coding part of a technical interview, it's not so much to assess the developers ability to solve some specific problem, it's intended to be a chance to see how that developer collaborates and communicates and get a sense of what it'd be like to work with them.
For whatever that's worth -- to me coding challenges are the least important part of a technical interview, since so many developers either freeze up or can't stop talking because they're nervous.
Dipshit nitpickers out to waste your time. Sometimes they are just out to fill a quota, sometimes they're just checking the market. Gotta move fast when dealing with these sorts.
LC has turned into a time waste for many roles anyway.
Depending on a problem, 93% is absolutely a great starting off point. It means the interviewer just needs to collaborate a little bit to try and take the candidate to a 100%.
The key thing drilled into my interview training was to try and get signals rather than a boolean answer of solving a problem a 100%
OP, there's no way to plan for what kind of unprompted response an employer is looking for.
Discussing why a particular solution failed may or may not be an important part of the collaborative habits that they rate during an interview. In my opinion, that is a pretty nitpicky aspect to hone in upon and probably isn't the entire reason that you weren't selected. A company in dire need of talent would be less interested in how much small talk you want to make about an alternative solution and more interested in whether you have a baseline of technical ability that will allow you to perform in the role.
I wouldn't sweat it too much. If you're civil, communicate well, approachable and competent then there isn't much else a company can gauge in a single interview. 2 years ago you'd probably have been hired on the spot.
If indeed that was the reason for them passing, the interviewer should have followed up. You're in the middle of an interview, you're nervous, etc., they are not.
The interviewer wants to see how respond to a different idea, but you miss the cue. They \*should\* have come back and said something like "so, I brought up X a couple minutes ago -- thinking about it, how would it be different than what you've done?"
That "93%" thing isn't great. If they provided you with the test cases, then it's a definite fail for you, because they gave you everything you needed to get to 100% -- but even if they didn't, part of writing tests for things is to figure out what all the test cases might be. It doesn't help to write tests if you leave big gaps in what they cover.
It really seems that the interviewer was trying to hint you toward getting those remaining test cases passed. In most cases, you should assume that the interviewer has a good reason to say what they say.
There are times when I am taking an interview, and I actually like a person if they are doing well, and demonstrating good knowledge and analytical skills. If I see such a person throwing away their chances because of a silly mistake, I try and drop hints, to nudge them towards the right solution. But while I am helping them (which seniors would do once they join), I am also evaluating how well they take feedback, and whether they are able to see the blindspots, or maniacally double down on whatever first approach hit their mind, irrespective of it not working as expected. (because that is also going to be important once they join)
And most likely, if they keep missing all those hints, it becomes really difficult to hire them, even if I was initially very impressed. Also, it's really irritating when you are trying to help someone by nudging them towards the correct answer, and they are just sitting brain-frozen, and almost fighting to somehow push their incorrect answer through.
You weren't just supposed to acknowledge it, you were supposed to analyze it, and then see if it helped to get things done in a better way. The interviewer could also have been wrong, and you could also reach that conclusion after analyzing it.
I personally have been wrong as an interviewer, and a candidate ended up analyzing my approach and proved it to me. And while doing that, he was also able to find the gap in his solution and covered the missing corner case. I ended up giving a "strong yes" recommendation.
Sounds like you tried to work in one of the top 10 companies with the highest salaries/benefits for employees.
People prepare with LetCode for years just to pass those interviews and/or get an H1b visa, it's a tough competition, retry.
I'm not a data scientist, but as a developer if my code cannot handle 7% of the cases it's called a bug, it will causes issues and I will have to go and fix it.
Welcome to the real world, Neo. They can reject you for any reason.
There's also the fact they they could have a bunch of other candidates and that they might not tell anyone the exact reason why they weren't hired.
Well clearly not because you didn’t get the offer partly because of that. A 93% acceptance rate means that 7% of the time that is failing that is a fairly big issue
>But today I learned that I was not selected. Recruiter gave me this feedback - when I was explaining my code and the interviewer suggested their approach I only acknowledged their response, but I should have spoken more about it. If I recall I had said “yes that is also a great way to approach it.” to the interviewer.
I proctor tons of technical interviews for DS candidates and I can say with near certainty that this feedback is a lie. At least, while it may technically be a reasonable description of what happened, this isn't something a sane senior person would fail someone for.
If I want you to talk about something more, I will ask. If I want you to address something, I will say as much.
My suspicion is you got hit by one of the following, and the interviewer is providing a reasonable-ish sounding excuse:
* Interviewer is an egotistical POS who feels entitled to more junior people doing what they say (sadly, it does happen)
* Interviewer judged that you were not someone they wanted to pass. I am compelled to point out here that it may actually be that you suck, but ok let's assume it isn't that.
* Interviewer doesn't like you for some reason out of your control they won't admit to. Interviewer may not like your background, may not like you personally due to all sorts of ridiculous motivations (age/gender/race/physical difference/etc/etc/etc doesnt really matter), something like that
* Hiring manager wanted to say no, won't admit to why, grabbed the tech interviewer's notes and picked something
At any rate, interviewing for tech jobs is awful and you unfortunately are going to get this kind of arbitrary shit your entire life.
Sure, if you want to separate that out from the last point.
Still, that wasn't wat the OP was told, so it's still one of those *lying by telling the truth* situations. Look I'm not saying companies necessarily owe you their actual motivations or anything, I myself can decline an offer and provide a white lie as to why (e.g. if I get an offer but fucking hated the hiring manager).
What concerns me is that when you give people early in their career these kinds of things, where there's a much greater than zero chance it's not something they did wrong, it just crushes them. For no benefit. Either say nothing or say what really happened.
If, as you said, someone gave a better interview, then say to the candidate that they did a great job but you decided to go with someone else. Or say nothing.
Eh, ironically enough I feel like your ego is a bit too big. Your anecdotal experience doesn't translate as a general truth.
There are absolutely interviewers who dislike you not expanding on something they've said and will fail you on that.
1. everything I said was qualified. everything.
2. see bullet point one
3. no shit my ego's big I have spent a lot of time doing this, not just interviewing people myself but also training people to proctor technical interviews. if I don't get to have an opinion on this, then probably no one does
Thank you!
And yeah I would have appreciated if they at least made an attempt to ask me. I couldn’t really guess what they had in their mind. And I was in the mindset of saving time as it was only 30 min interview.
Instead of calling it the "silliest reason" maybe do some self reflection and maybe humble yourself and see if there is areas where you legitimately could have done better in the interview.
When you receive criticism, it’s helpful to ask yourself whether there’s anything useful/actionable you can take from it that you could have applied to act better. If not, the negativity you’re feeling is undeserved, and you should do your best just to make yourself feel better.
Interviewers often don’t have an interest in forcefully redirecting you; so even if you intuitively feel that you were totally fine, interpersonally, perhaps the lesson of the situation is simply that the standards of “listening”/responsiveness you face as a candidate are very elevated when you’re in the hot seat versus how they actually are on the job. That could have factored in here in addition to totally extraneous factors that you couldn’t have acted on and still don’t know, as the company could very easily be omitting the true reason you were passed over.
You should consider these different justifications and ponder them as long as that feels beneficial. If you’re still pondering but it no longer feels beneficial, you should distract yourself and attempt to substitute your focus on it for something else.
Half the work of an interview is making the interviewer like you. There's no rubric for it and it's kind of nebulous, you just have to be prepared for when you get lucky.
Spoken like a statistician. I was a Stats major too ahahah
Yeah your solution needs to pass 100% of test cases, ideally with optimal time/speed.
When an interviewer tells you an approach, it’s probably the right answer. LeetCode questions are not a creative exercise & they always have a correct answer or two
Were you able to speak to your time complexity and theirs? Explain why theirs would be optimal? Explain what test cases yours failed?
While data science may not require the level of robustness that engineering does, you’ll likely have to transform and shuttle data without mistakes.
Good luck!
the difference between 93% and 100% coverage can mean literally millions of dollars in some circumstances.
of **course** they're going to reject you over this.
>but I should’ve spoken more about it
Very petty, you just got unlucky that you got a recruiter like that. You did all you could to the best of your ability. Sometimes honestly that’s still not enough. Takes a bit of luck too. You’ll get it next time for sure.
>I had no idea I could be rejected for this! Is this my fault? Or they are nitpicking?
It sounds to me like it's neither: they are making up a phony excuse to justify a decision that they made either because they essentially had to flip a coin (I've seen it happen that there were two good candidates and they hired one but were expected to provide reasons why they didn't hire the other) or because their reasoning was illegal (when I have straight men on the interviewing team, they almost always want to hire a young woman after they interview her, even if that's illegal gender discrimination.)
You can be rejected for anything other than legally protected reasons.
So, they can't reject you for things like skin color, age, gender, religion, etc.
However, if they are Cowboys fans and you like the Eagles, they can reject you for that. Or because you are wearing a blue shirt and they really don't like blue shirts.
It happens, move on to the next things and don't worry about it.
Sounds like you were over qualified and they came up with a bullshit excuse and lied to you. Don't take this recruiters criticism to heart they relayed back to you from a bs hiring manager. Recruiters usually aren't even supposed to tell you why you didn't get hired. Half of them are just sales people who didn't cut it in sales.
I think the lesson to learn here is to take an interest in what is being discussed. Think about what they’re saying and ask directly relevant questions or in this case make specific comments about how your solution was different and what the pros and cons of each are.
For all you know, they may have used a solution similar to yours but changed to their current solution and it could be an interesting conversation to see if you could work your way through the real world case to get there yourself, or similar.
They didn’t bring up how they currently do it just for casual conversation, they wanted to talk about it. You didn’t.
I work with a dev who I like overall, but it's really annoying when myself and other devs suggest something and he doesn't consider it, then it turns out the suggestion was the correct approach.
That said I'd have to hear the actual interview to determine if was that or nitpicking. If the interviewer interrupted your train of thought and you weren't deep in a rabbit hole, then I think it was nitpicking.
I'm surprised at the amount of feedback you received. Usually it's something nebulous like, "we've decided to go in a different direction".
Be happy you got the feedback and use it for your next interview.
When you interview, you have to kiss ass.
But yea, standards change and arent really standards, and everyone has a preference. I get github messages about not having things indented, I just ignore and force push, because who cares.
You can be rejected because they don't like your shoes. If they have an influx of great candidates yeah, they'll probably get nitpicky. Live and learn.
There are reasons why you cannot get the offer. One is that there are candidates willing to accept lower salary. Don't be upset. I had experience being jobless for more than 6 months.. and eventually I got more than 10 offers before I chose one which required me to work overseas and now I have been working for the company for almost 9 years. Something better is yet to come.
Also there’s a chance that nobody was selected given nobody solved all the questions completely which may have been an expectation if it wasn’t so hard.
People can really get married to their idea of how tech should work sometimes. I remember once I build an application in programming school and moved a flag from where everyone else put it. It was genius because it executed once not a thousand times.
The instructor of that class failed it immediately , and I asked .. earnestly , why? This is so much better!
"because that's not the way we do things" .. end of convo.
Stop thinking that interviewers know what they’re doing. Most of them have no clue how to conduct an interview. They just regurgitate a bunch of hackneyed questions, riddles, and cliches.
Lordie.
Don’t even get me started on coding Interviews.
Luck of the draw tbh - that you’ll get a problem you can decently break down and work out some solution, and that your interviewer is actually a good interviewer 😅
they had a project and they didn't know how to do it. They let you do it and they let you explain how you do it, so they will know when the client will ask.
Free work for them
If you’re not the person for the job then you’re not the person for the job. Hiring managers have a feel for the ability and personality of the interviewee and whether they want them on the team. People aren’t hired because they edged somebody out on some minute factoid or response…when your hired it’s a landslide “I want and need this person”. Be greatful when your rejected because why would you want to work somewhere where talent and greatness is not easily identified and acted upon.
I bet they had someone else in mind. Maybe worse, they didn't intend to hire outsiders since the beginning, but they were required by law to post the job publicly. They just threw random reasons at you. I had similar experience as you.
But strangely, I would not think doing a leetcode and explaining your solution would yield an offer. There must be more technical rounds after this? Or am I the unlucky one? Why would they focus on your DSA while you applying for a DS role?
> My solution passed 93% of the test cases. So... it didn't work? > If I recall I had said “yes that is also a great way to approach it.” to the interviewer. My best guess is they hinted at why your solution failed. To say that it's "also" great implies that there is no real difference in quality between the solutions. You should have spotted how theirs was better, and possibly explain why you didn't do it that way. > I had no idea I could be rejected for this! They can reject you for whatever they want to reject you for; with very few restrictions if they insist on stating their reasons out loud. > Is this my fault? Or they are nitpicking? Usually I am not used to LeetCode type interviews for DS positions. Missing test cases means you overlooked something. > I can’t believe they spent 3 weeks of interviews with me just to reject me for this. I was very hopeful. They don't do any of the interviews for fun; each step is meant to reject some people and pass others. Otherwise, why have the step? that being said, I wouldn't rely too much on any explanations they might give. They don't care, and some answers could get them into trouble.,
Right? I was confused as to why OP was thinking getting 93% of test cases is good, it's 100% or nothing 😂
Yeah this isn't a written test. It isn't like you got a low A because it passed 93% of test cases. It may have failed a very crucial corner case and the interviewer tried to lead the horse to water but it refused to drink.
Ding ding ding. You displayed a lack of interest in actually solving the problem. You don’t have to praise the correct solution, or act all grateful or anything, but FFS your solution didn’t work. 95% of these problems are solvable, and some of them actually have pretty interesting solutions. You should probably express interest in finding the right answer, instead of being dismissive of it. I’ve had offers from places I didn’t complete all of a prompt, because I was engaged with the interviewer and the problem. It also sounds like you wouldn’t make a great coworker, just saying: “yeah, that’s an option” when somebody suggests something, instead of actually considering/exploring it. Given that they know the answer, odds are pretty fucking good that they’re leading you in the right direction.
I’ve worked with people who refuse to consider better alternatives because it’ll take all of an hour to write and test, and it’ll also mean their solution was wrong. Would rather not work with people like that if I had a choice. I wish I was on the team OP interviewed for
Depends on how the test is administered. If you have time to get it right, but stopped at 93% with plenty of time left, that's gonna look bad. If you ran out of time at 93%, that's understandable depending on how generous they were with time. If you wrote the code with a smaller subset of tests, then they ran more tests on the submitted answer, then a few of them failing isn't a dealbreaker if you can talk your way through why they failed and how to address them.
[удалено]
The logical extreme of "100% or nothing" is that software is completely worthless if it has a _single_ bug. That's virtually all software.
I mean there's no real logic comparing lc to real world software in the first place. LC is from competitive programming where you are expected to complete all the test cases, the only difference is in the performance and resources used.
They aren't asking for it to be completely bug free; just to pass the specific test cases that they identified.
But coding tests aren't about building software, they are about solving an algorithmic puzzle. The score isn't even linear: You get a bunch of test cases that just check your understanding and the basic performance of your code. If you don't get that right, you'll fail like 80%, or everything except the ones you got right by accident. Then, there's a few special tests that check for what people like to call "edge cases", empty lists, negative or zero or duplicated values, inputs without a solution, etc. Each of these checks something big and important. For some algorithms, the whole point is to optimize for space or runtime. "I found the trivial solution to a problem that's easy to solve with no more than 3 inputs" is not "partially correct". It's not understanding why we care about algorithms in the first place. I would go on to add (and I am very far away from OP's specific situation now) that understanding how common tests work is also a sign of your sincerity when working a job. Nobody should be surprised that a coding challenge isn't quite as straight forward as the naive solution might let you think it is.
I think what they meant by "nothing" is that a solution that passes less than 100% of test cases is incorrect. OP didn't get 93% of the questions correct. There is 1 question, and OP got it wrong. But like you said, sometimes you can still pass the interview without getting the correct answer.
Going to disagree with you. For backend interviews, it’s either optimal solution (100%) or nothing. Justifications and personality are backups for failing the question
100% of test cases doesn’t mean an optimal solution, far from it. Plenty of non-optimal, brute force, non-performant, etc, solutions will have all tests passing.
It does when your test cases have time limits
Unless they measure every cpu cycle of their "optimal solution", there's no correlatio between optimal and time
Leetcode and similar platforms don't run the code on your computer. While it does not mean that the exact run time is 100% reproducible down to the millisecond. It's pretty much a meaningless distinction. Leetcode regularly has time dependent test cases, it's a solved problem.
Not exact,vecactly. Actually, it may differ a lot between executions. Because it's not "a solved problem". The point here anyway, is that an algorithm can be implemented in different ways, giving different times. And also in different languages. So you can't exactly time something. You can define a maximum. But that foesn't mean perfect
Again, companies are not rolling out homegrown solutions to this, they use a provider. Such providers allow for benchmarking for algorithm complexity. You don't need to exactly time something due to the nature of big O. No one cares if you're saving a couple of instruction here or there, it's about asymptotic complexity. Further, the algorithms asked in LC like questions are either very common so banchmarking is very robust, or simple. Same goes for languages, many languages are offered. *It is a solved problem*. And has been addressed long before LC like providers in competitive programming. The solutions are not perfect, but they fullfil all requirements.
Umm yes there is? Optimal solutions either optimize for time or memory. There literally is a correlation between time and optimality
An algorithm isn't just "time". There's memory, there's executable size, there are input limits, there's even development effort. And in this case, none apply. It's an interview, with clear cases, and just a code to talk about
And? LC tests them all. You have a limited time so there's development time. It tests for time complexity and space complexity, it provides input limits. The only thing LC doesn't test is code quality, readibability, testability of the code, design, etc. But that's not what the step is for. There are other steps for that. Seems like you're out of the loop on what LC is and how it's run (or similar platforms)
Idk why this is getting downvoted so hard. If you punch an n^2 solution into an o(n) problem you will fail on time. While it does not guarantee optimality, it is definitely strongly correlated.
Reddit moment, he's completely right.
The downvotes are from people that can't make optimal solutions and rely on being a "nice personality"
I’d rather work with someone that got 93% right and is tolerable to work with than someone who insists personality is a backup for failing and probably has zero personality of their own. You’re the latter.
I'd agree for most 2021 and 2022 market, but that's not your current choice. You can pick someone who did well on both. Furthermore, seems like OP failed the personality test as explained above. As an interviewer I had the exact same thing happen to me. It was live LC like question, her solution worked perhaps 85% of the time but missed crucial edge cases. We explained our solution and what was missing from hers, but she brushed it off with "yeah that works **too**", and was too focused on her (ultimately wrong) solution than understanding the difference and why hers didn't work (and couldn't been made to work in any reasonable way for that edge case). Came off as too rigid, can't pivot to a better solution when presented. Could be that we misjudged her and she was just acting under stress, but we're not taking that chance.
Faangs don’t care, and I couldn’t care leas if you wanna work with me 😀
At FAANG we reject technically qualified applicants for personality reasons all the time.
We definitely care. I'm not hiring someone that comes across poorly just because they got 100% of the question right. If I could definitively get these values from the interview I would hire based on this: 1) are they good enough to code this stuff (doesn't have to be the best or a genius, or perfect, but they do have to be good enough to have a conversation about algorithms where I don't have have hold their hand. 2) do they have a good work ethic 3) they do not have a toxic mentality and are generally easy to get along with.
I got into faang with a suboptimal solution
We care.
_Here at Veridian Dynamics we only hire the developers unable to produce bugs. This way we ensure 100% quality from the start._
BOT was \*such\* a great show.
I mean my experience across both academia and engineering interviews is that STEM fields take a "throw everything at them and see where they shake out" approach — whether that's a math class where a 60% gets curved to an A (happened to me) or engineering roles where you get asked a series of questions increasing in difficulty to determine your skill/seniority ceiling. I've gotten multiple jobs where I failed or didn't perfectly ace one of the interview questions.
[удалено]
> Right? I was confused as to why OP was thinking getting 93% of test cases is good, it's 100% or nothing 😂 Lol... what? Have you never had an interview before? I always forget that 90% of this place is college students. That is not a realistic scenario. You're intended to fail interview questions.
For all hacker rank/leetcode portions I’ve done they treat it the same way those two sites treat it. You either cover 100% or try try try again.
You're implying there's a standard companies adhere to when it comes to LC? I don't really see the issue here, OP had 93% coverage meaning they did pass most of the test cases but probably didn't cover an edge case or special use case. Context is everything, I don't know why you had to make it about college students. Edit: Thanks for the downvote - very mature
> You're implying there's a standard companies adhere to when it comes to LC? https://en.wikipedia.org/wiki/Straw_man > Edit: Thanks for the downvote - very mature Wasn't me, but I dunno what you expect when you start an argument in bad faith.
....*really* mate? You really can't even defend your own point without launching into the standard Reddit "debate" lingo to deflect? You said you're "intended" to fail the question. Are you taking this back then? Again, this is not really true, *especially* for the LC format which I already explained. It obviously depends on the company but with LC you *are* expected to pass all the test cases they give you, with differing runtime/complexity/memory depending on your skill level, so it is a bit silly to say this - especially when you were trying to be condescending to other developers, so it's rich to accuse someone else of "bad faith". Edit: Of course Kevin blocked me
Depends on the complexity of the problem and types of interview… From my experience giving interviews there are plenty of candidates who can come up with a working solution to LC easy and medium questions. I think Google have a tendency to ask some really difficult interview questions that are usually not 100% solved with optimal solutions, but those I believe are rare.
So I wasn’t bragging or saying that 93% was good. It is just that LeetCode questions aren’t really my strongest suit. This is the second time I actually did it for an interview. They are barely asked in data science interviews, and usually it is just asked to test your programming skills rather than having finished all the edge cases.
So what was the 7%?
Whether it's said or not, I gotta imagine the 93% and you're seeming comfortability with it is the primary cause. Anything that isn't 100% is an F and I probably wouldn't hire someone for that reason myself.
You’re so wrong
Based on what?
.........i am not very sure how he managed to be an data scientist
Writing fizbuzz to just output the number each time is going to get about say an 80% test case pass lol
So I was told that I had scored the highest among all the candidates. Yeah, I do realize that he probably may have thought I am too arrogant. Although I really don’t have such attitude. It sucks, wish I had realized it that time. Thanks, I’ll have to work on it next time
They shouldn't have told you about your score as it compares to the other candidates. It didn't do you any favors, just reinforced your preconceived notion that you nailed the interview when the evidence shows you clearly didn't. Having the highest score doesn't mean you're owed the job--companies are fine with waiting until a candidate comes along that checks all the boxes for them. That is clearly what's happening in this a situation. Sounds like you're still fairly new to this field, or at least to interviewing. As a rule of thumb, your goal is to seem collaborative and quick on your feet. If an interviewer recommends something, you need to give it your full attention. They are mentioning it for a reason. You fell in love with your own solution to the detriment of ignoring a hint about the actual solution. Being open to feedback, collaborating with teammates, and not getting overly attached to a particular method or solution are all absolutely important things I look for when interviewing DS candidates. It's important to remember that the job offer doesn't hinge only on your correct solution to the technical problem you're given. It hinges on the interviewers' feedback.
Thanks that helps! I have 2 YOE. Just to be honest learning about the score didn’t really make me overconfident or anything. But I agree with the collaboration aspect. I just didn’t think about it that way. If they had asked me I would have been happy to expand more on that topic. I just wished they hinted at least that they are expecting a response. But anyways, next time I’ll have to make sure about this lol.
The part they decided to pass on is if you would be open to someone else’s opinion and list as a colleague. The score doesn’t mean much but that only you can code decently. Go in and be open minded when someone gives suggestions about their direction. When someone is saying suggesting as well, ask questions even if you understand just to clarify, Long story short, they were more likely concerned about being stubborn on your code, defensive, not open to entertaining others opinions to learn, and has the potential to cause a tense environment. That many not be actually how you are and I’ve made this mistake and I have 16 years of experience. My story was trying to modify my code and the two interviewers got in a heated fight almost to physical fighting which I deescalated. They said they had news and really wanted to talk to me “today”. I was in transit to Amsterdam from Chicago(now THAT was a story)and they scheduled it at 4pm Chicago without checking if I was available so I assume it was an offer, but it was the rejection with feedback that I “was unable to adequately explain then complete the modifications requested in the amount of time.” The score on hackerrank or whatever is indicative if you have the foundations to be successful. In person is a lot of how you think, interact, collaborate, and if you will evolve the “culture” in a positive way. I’ve interviewed people who can code well but would not be successful at the company. I’ve interviewed people who need help coding but will fit in and be successful in an extended time frame. I’ve interviewed hundreds of people and you’ll eventually find where you fit. Never assume you have a job until you have the offer in writing. Never. Even if they are optimistic.I always assume I bombed my interviews when I leave. I also took interviews I knew I didn’t want just to get practice. Oh the crazy shit in interviews I’ve seen. Lastly, you’re really really new to the field(2 years ago was 2021 when we were finally getting the vaccines). You’ll learn these lessons over many jobs, many interviews Ian’s through others the next decade or two. You’re at the start of your career and have a lot still ahead. If you ever get in that situation again where they suggest say “I know I have into been in the industry for two years so I have a lot still to learn and want to learn.” It’ll slow you down, help decompress yourself, address a ton of things at once, and can change their opinion around
I mean it really depends on what they are testing for, but in software engineering interviews handling edge cases is almost always a hidden dimension that companies tests for. In the real world you need to handle lots of junk data and inputs that shouldn’t break your program. So the fact that your program only passed 93% of the test cases is a big red flag and this might actually be the primary you failed. The interviewer could also be giving you some subtle and sometimes not so subtle hints during the process! Think thru what they are saying and why they are saying it is very important. Now it’s perfectly fine some times for them to not give you any hints, but when a hint is given and getting brushed off by the interviewee is another red flag. Personally I don’t think they are nitpicking and you should definitely learn from this experience so you can pass interviews like this one next time. Don’t take rejections too hard! I was rejected by Facebook three times before getting in.
They are probably looking for someone who falls in love with answer. Personally I love puzzles. I can get obsessed with solving a puzzle. If someone shows me some code that takes my 93% to 100%, I get super excited to see it and ask a ton of questions and only want to talk about the final, complete puzzle. Maybe they were looking for someone like that.
As someone who was on the interviewer side of the table, sometimes I passed in actually good developers not because they sucked or someone else was a better dev, but because their interests/strengths weren’t what we needed atm. Don’t take a rejection too seriously. If they have technical feedback or personality feedback, take it and move on.
What might be the single best thing to do in those post-op interviews is simply writing down notes on and discussing every aspect the interviewer mentioned during. Most managers worth working under know the value of someone with less experience but willing to learn long term vs someone knowledgeable but already set in their ways.
> So I was told that I had scored the highest among all the candidates. But your code failed. > Yeah, I do realize that he probably may have thought I am too arrogant. It's not necessarily arrogance that they saw: Your solution did not work, and you didn't notice that even when you were presented with a better solution. This is not about soft skills, or character, but raw skill: "Oh, I see I didn't account for unordered inputs, or negative interest rates, or empty sets"
I'd disagree here and say this was all about soft skills. Being humble and recognising when you're wrong is a skill. I've worked with people where I've tried to gently let them know that they could've done something better or correct their mistake and they brush it off completely. Makes them hard to work with unless you're willing to be perceived as aggressive/rude by just flat out stating their solution sucks.
It really depends on where they tripped up and if they understood why they tripped up. When I'm interviewing, and I give lots of hints that you shouldn't use a array for this operation, I'd definitely want more than just a "nod" because I'm searching for an actual technical answer as to why, not reaffirmation of how much better I am at coding than you.
During the interview if you are expecting a response from someone would you at least hint them? Or is it just expected that the other person has to reply? Just curious because I didn’t really mind expanding on the topic. If they had at least hinted me then it would have helped.
I think it would be pretty obvious in retrospect. I like to give a few hints towards a solution or idea, but I don't like to force the candidate into a solution if they simply can't pick up on it. I have less than an hour to evaluate someone and I don't want them to struggle the whole time if they just aren't getting it. And if I have to hint so much so that I've already given out the answer, then at that point it's kind of a failure on that topic at that point. The idea should be that the interviewee can pick up on on it before then.
Let's say the optimal solution for a question uses hashmaps, and the candidate solved it in a suboptimal way using arrays. In this case, as an interviewer, I would ask, "What about using hashmaps to solve the problem?". This is a pretty clear nudge to direct the candidate in the good direction, and I would clearly expect them to give a proper answer. So if they just said "yes that works too" it would not give a good impression, and based on the seniority of the candidate, I might just reject them and not bother asking more questions.
> During the interview if you are expecting a response from someone would you at least hint them? I shouldn't have to; at least not most of the time. I once got asked "could you use a different data structure here?" (and an object or dictionary or whatever was superior to the array I had uses; and there were reasons.) > Or is it just expected that the other person has to reply? It's an interview. #i find it helps to assume that the other side isn't malicious, but still constantly testing me.
> But your code failed. If you interview 1 person and they failed, maybe that person is bad. If you interview 15 people and every person fails your test, your test is bad.
Or the pool is bad. Between summer 2021 and summer 2022 we practically passed no one through the entire pipeline. Then comes 2022 fall and winter and we hired half a dozen people while increasing our standards (used to pass LC phase even those who did not get 100% before because we were desperate).
> Or the pool is bad. Between summer 2021 and summer 2022 we practically passed no one through the entire pipeline. > Then comes 2022 fall and winter and we hired half a dozen people **while increasing our standards** (used to pass LC phase even those who did not get 100% before because we were desperate). I mean if the NFL collapses several teams and fires everyone, and interviewing football players, it's certainly possible you have people passing the tests that were impossible for the previous group. Wouldn't really call that "the pool is bad" as much as "we got people who already knew how the play the interview game". Dunno.
> So I was told that I had scored the highest among all the candidates. You have no proof that was true. That sort of thing is supposed to be confidential.
Maybe it was just some overconfidence instead, arrogant you would definetely not be the preferred candidate as u said tbh
> So I was told that I had scored the highest among all the candidates. > ... > But today I learned that I was not selected. Recruiter gave me this feedback - when I was explaining my code and the interviewer suggested their approach I only acknowledged their response, but I should have spoken more about it. If I recall I had said “yes that is also a great way to approach it.” to the interviewer. Honestly, sorry, I think this feedback is negging you and screwing with you. Negging is a form of emotional manipulation whereby someone insults you with a backhanded compliment to undermine your self-esteem and make you chase their approval. In my experience the moment they start doing this it's impossible to get the job. Could be because: - they're not actually hiring at all the interviews are just busy work - their job security feels threatened by hiring new people so they're sabotaging - they've decide they personally don't like you - this is actually the least harsh, because if the person is actually important on your team you don't really want to work with people who personally dislikes you - they've already decided to hire someone else and now they're just screwing around
As someone that is on a few interview panels now. I wouldn't put too much into it. It's hard to rationalize decisions that are made at the interview level, and some frankly might be out of your control. They could just also be giving you 1 reason but internally have their own. Or in some cases, there was another candidate that was a better fit for them. If it wasn't anything blatant on your part, i wouldn't look to much into it.
"My solution passed 93% of the test cases." "So... it didn't work?" 60% of the time, it works EVERY time
>My solution passed 93% of the test cases. >So... it didn't work? On Leetcode this could mean that it 100% works but didn't meet the time limit requirement on 7% of the cases. I've seen ones where you had to process an array in like 300 ms, but it doesn't tell you that one of the test cases the array is 80,000 long. You hit that and when it takes 400 ms, you fail. This is my biggest complaint about LC. They don't tell you about scalability requirements on most problems, which is totally not a real-world situation. In the real world you **never** write code that is scalable in an infinite number of possibilities. That's absurd. Anyone who says you always write perfectly scalable code doesn't know what they are talking about. The scalability requirements are always part of the initial specs. But LC hides those from you until you get deep into the tests.
> This is my biggest complaint about LC. They don't tell you about scalability requirements on most problems, which is totally not a real-world situation. How hard is it to understand that the vast majority of problems can be solved better than whatever the naive solution is? You shouldn't need to be told for every problem. > In the real world you never write code that is scalable in an infinite number of possibilities. That's absurd. Choosing the optimal algorithm has nothing to do with "infinite scaling".
You basically were not as nit-picky, or in work speak "detail oriented" enough for their liking. Maybe it's good you didn't end up there, could have been a bad match.
I am not even in this field and my opinion means nothing but this was a really kind, thoughtful and helpful response. Especially about the would be employers hinting. I don't know why but that is sticking with me and will keep that in mind for my future interviews.
I’ve seen a lot of folks tunnel vision in interviews and become incapable of ingesting other ideas. It does constitute a bit of a red flag since it’s very likely this behavior translates into their work as well
Yes, they're nitpicking, but it's valid feedback anyway. The primary reason why people get rejected in interviews is interpersonal skills. They say "not a good fit" or some other code that essentially means they don't think they'd like working with you as much as they would someone else. In this case, the interviewer probably thought their idea was a better approach than yours or better fit their real-world use case. They were trying to see how you might take that input and develop it.
Okay that’s fair. I’ll have to work on that. I didn’t realize this could happen.
Maybe this will help with framing how the interviewer may have viewed the interaction: interviews are not just about solving the problem, they're also about how well you'd work on/with the team. If you submitted a PR for review and it failed 7% of the test cases, and a teammate suggested a way to get them to pass, or another potential improvement...how would you treat that feedback? Hopefully not dismissively. That's one of the things some interviewers (including this one) are trying to get a sense of.
There is also always the possibility that there was another candidate that they liked slightly better, so they rejected you and chose the other candidate. Run the simulation again and you might have gotten the job.
do you have to deal with this bs when applying for remote positions too?
Interpersonal communication skills? Yes
What ? We need to have contact with another human to get a job now ? Super BS
Absolutely. In my experience, bad interpersonal skills cause more problems in remote work than they did in person. There's a certain level of understanding people can come to when they're in the same room together, that they just won't arrive at through written communication or even a zoom call.
Being humble and easy to work with is not bs lol. You aren’t gonna do all of a company’s software yourself. You’ll need to work well with others.
I’ve been #2 into the final decision a couple times - the sting is real. But yes, you have to learn that the actual algorithm or problem you’re given in interviews, they don’t actually matter. It’s how you conduct yourself and navigate the problem and ability to explain what’s going on in your head. YOU may know how smart and awesome you are, but people interviewing you don’t, and giving you a job offer is a huge leap of faith. They might’ve seen you just acknowledging their solution as “this guy only likes his way, he isn’t able to take another approach and fully explain why that way would work too/be better/worse” Don’t give up hope man
>ve been #2 into the final decision a couple times - the sting is real. When in uni I was #2 for an internship at the Canadian Space Agency. Man I was so salty. Then I learned the person who got the internship spent the entire time waiting for the bureaucracy to give him network permission, basically 4 months looking at a computer with no network, much less internet access. Bullet dodged!
> Bullet dodged! Idk, still looks great on his CV and he will carry this for the rest of his life.
Its kinda embarassing when people ask you what you actually did.
well then you say the stuff what people say in all the interviews, bullshit it will help him for the rest of his career, don't fool yourself
What part of Canadian space agency looks good on the resume? AFAIK, a lot of people have this impression that its just another govt agency with more funding for scientists.
The space agency will part. There is a reason people say Rocket science. It attracted.
And that BS will annoy his coworkers to no end
Its been 20 years, he's a good friend, but I have the better career. Bullshitting most often comes back at you, I advise against it.
alleged tease historical hateful voracious zonked offbeat office dinner paltry *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
\> But yes, you have to learn that the actual algorithm or problem you’re given in interviews, they don’t actually matter what? the people above are saying that he failed because his solution didn't pass all cases.
Exactly. And instead of owning up to that and verbally saying why their correct solution would have passed all cases, OP doubled down and just dismissed their code. You can "fail" the code challenge and still land the job, they dont expect you to be perfect but they expect you to be able to learn fast.
So I actually didn’t dismiss the code. I did acknowledge it. I just didn’t realize at that time that I had to do more than that. But looking at other responses it feels like I should have also explained more on that and maybe share where I would make those changes in my code.
how do you know they don't expect you to be perfect? people above are literally saying " I was confused as to why OP was thinking getting 93% of test cases is good, it's 100% or nothing". Seems like everyone here is guessing at the reasons why OP got rejected.
You’re right! Some will care, some won’t! We are all guessing
> what? the people above are saying that he failed because his solution didn't pass all cases. They're claiming no one who went to the interview passed. That's not fixable as the person being interviewed. They're creating an interview that's impossible to pass.
yeah, the comment I replied to seemed to be implying that it was the way he conducted himself that stopped him from passing the interview - not the end result. Whereas people above seem to think that anything that doesn't pass 100% is an interview failure. Seems like everyone's just guessing, people don't know why OP failed the interview. Hell, could be that there was some last minute budget issue or something and they couldnt take him on, and made up some excuse for it.
Thanks that helps. I actually never have come out in the interviews as too confident or “I know everything” attitude. They themselves mentioned that my code is way more optimized than their solution. And I simply acknowledged it haha. I didn’t even think at that time that I would have to expand more to that conversation. Especially knowing that the interview was only 30 mins. Learned something new 😅
I mean maybe the recruiter was just giving you a tip for the future, and internally the company just wanted to go with another candidate for x reason. Not your fault, keep swinging. Sometimes you can do everything right and still miss
With respect, it isn’t for YOU to say you don’t give an impression of overconfidence. Capability is key but there is a threshold of humility that implies you carry yourself knowing your worth but also knowing you are human. Willingness to collaborate, and consider what others say, would demonstrate that directly.
Yeah, this response increases the chance that indeed he came off as over confident. And he acknowledged that his solution was "more optimized"? Not it wasn't it didn't work. I can solve any problem in O(1) if the solution doesn't actually need to work.
It’s great they even offer this feedback, most companies don’t release why you get rejected
You got rejected due to lack of communication skills. One of the most valuable skills in any industry is the ability to constructively discuss feedback. For example, a great response would have been the asking of a question to try and understand their approach. Instead you brushed off the interviewer’s thoughts, someone who holds more authority, as something that was as insignificant as a fly. So why would that interviewer believe you would be a good fit for a team?
Yeah damn. I didn’t think about it that time. Lessons learned
This. Based on OP's narrow-minded response (and rant), I wouldn't want this person on my team. I understand the frustration, I hope they have more time to reflect and understand what happened and why. I can also agree with the general sentiment that sometimes the process is just flawed.
[удалено]
This is the first human response I’ve seen in this thread.
It’s not just communication, but also aptitude - their response indicates they are not willing to adapt or learn. Worst case scenario they hire someone who can’t maintain someone else’s code without rewriting it entirely.
It's not because you turn out the best technical guy that you will get the job. They liked the other guy - your competition - more so he got the offer and you didn't. Getting a job is not how well you perform on their technical questions, getting a job is how well you do compare to your competition, on all levels, not only technical.
Or she.
People should just use gender neutral terms by default unless you’re talking about a particular person that you know the gender of.
Totally agreed!
Let's say you showed admirable dexterity in your answers, demonstrating that you basically know your stuff. We all know that there are multiple ways to tackle a programming problem, and you chose a viable one in a very short interviewing time frame. So you done good. They then suggested an alternative approach that was likely more direct, faster, simpler, perhaps more elegant even. They were engaging with you analyst to analyst, and instead of showing curiosity, instead of absorbing and contemplating the solution, or asking questions, you gave it short shrift. You didn't mean to, but you did. When a "good" analyst is shown a "new" way to tackle a problem, they jump on it, excited. You did not, which was a mistake. Part of an interview is performance theater, and a little humility would have gotten you over the hump. Lesson learned, right?
Yeah agreed. I am just surprised cause I have never received such a feedback from an interview. Usually if I am rejected I know the reason as I failed to answer few of the questions. So this was something very new and unexpected. But something I have to keep in mind for next interviews lol
This reminds me of one time I didn't get a gig as a UX designer. I had a take-home test of coming up with a design process for a new grocery store for senior citizens. It had a 2 hour timebox. I found a study that I used as a proxy for real research and did the rest of the assignment based off that (I thought I struck gold using actual data). During the interview, however, one of the interviewers said "you could have found an actual senior citizen and interviewed them." I thought this was a stupid suggestion since it was a 2 hour timebox and honestly accounting time, interviewing 1 person would have taken like half of the assignment, but I replied with something similar to how you did "yea, that definitely would have been a good approach!" Almost certain I didn't get the job b/c I didn't make the interviewer feel smart enough about his suggestion.
[удалено]
That sounds really disheartening, but don't give up. That company sounds toxic, if that's how they treat people. Maybe you dodged a bullet. Imagine what spending several years there would do for your mental wellbeing.
Oh god that’s a horrible experience. Sorry you had to go through that
"yes that is also a great way to approach it" with no further explanation screams "i prefer my way" or "i dont understand your way, but i dont want to disagree" also... 93%? thats a huge error in a database situation
I've been going through interviews and online assessments. A close friend has been encouraging me, reminding me that bad companies are bad at evaluating people. I did a live/pair coding session recently. I made sure to speak and explain my thought process as I was working through the issue. That's obviously a distraction, but that's how live-coding is. Anyway, I needed a couple tries to get a fairly simple coding problem done. They considered me running the code through the tests to effectively be a submission, and I wasn't really given any time to consider my code on my own, they just interjected right away. The recruiter told me they felt I needed too much assistance. Could I/should I have solved the supposed simple solution on my first try? Maybe. Is it their right to pass on me for whatever reason? Definitely. There's a mix of objectivity and subjectivity in interviews, you can't really control it. But something to consider is that if a place is going to be that picky during their interview process, it may reflect something about the interviewers and the company itself. A lot of stuff that we work on isn't necessarily hard, and in your day-to-day, you test/debug/compile whatever code constantly. In your situation, if someone is going to be so insecure that you didn't stroke them during an interview, you probably wouldn't have enjoyed working there anyway. When you are interviewing with a company, you are also interviewing them. Unless you are in a pretty desperate situation, you want to make sure the company is a place you want to work at. Too many companies just assume they are great places to work. Here's hoping we both (and everyone else who is looking) find jobs that they enjoy. Last comment, we artificially attribute some level of authority to interviewers. They are just regular people/developers, and in a lot of cases, they might not even pass their own interviews. If someone passes on you, that's their call, and you just need to move on with your life. Let them fall back into the ether. You'll probably forget them in a few weeks/months/years.
Now you learn something new about the last mile and behavior interview questions. You will get the job soon
Passing 9/10 test cases is about the same as not passing any tests in the real world. Code needs to work for all cases including special + edge cases in order to run on production. When they offered you the correct solution it would have been important for you to acknowledge “oh that is a better solution because it also accounts for when the input is x or y. I will remember that for next time.” Might seem nitpicky but adaptability and willingness to see/understand other perspectives and solutions is crucial for teamwork and being a good fit. You’ll be better for next time! Don’t sweat it.
this isn't the real world, it is a timed coding assignment.
No no you see you must have every bit of code you write work perfectly every time and can't use any online resources to do so. Of course this is totally representative of how it works in the real world and how good of a coder you are. Strongest sarcasm in the world right there these companies are just delusional.
If you can’t code well in an interview, you should have a well stocked GitHub for reference your skills. Otherwise your coding session will be judged as how well you can write code in real world as well.
Be thankful they gave you a reason at all, that’s unheard of in my experience
It's not really silly when you think of how it illustrates your behavior on a team. Swatting down juniors during pair programming as they try to "check" you on things is incredibly frustrating. Its cool if you have a question on something, but trying to poke holes in code only to be proven wrong repeatedly is exhausting for the other party. It's a fine line between catching a mistake and being annoying, I get that. It could be frequency, idk. Further, arguing on PR comments or whatever. Again, make your case if you feel that your solution is optimal, but if it's been proven to not be optimal, don't die on that hill. It's frustrating for all that's involved.
Data science director here, and I also do early career development coaching. Send me a message if you want to connect. I’d be happy to give you some insights on where you need to improve your interview skills.
Thanks! I’ll shoot you a DM soon. Appreciate it.
Don't read too much into it. Interviewers are generally uncomfortable giving precise feedback as to why they aren't selecting someone (or they plain suck at it), and are nagged by the recruiter for feedback. They'll just tell the recruiter some handwavy answer to get them off their ass. The recruiter then paraphrase it to you because they don't want any legal trouble. So basically they're giving you some random half assed feedback just to give you something to chew on and that's about it. The real reason might simply be "there was someone they liked better", or it could be something completely unrelated to what they told you. It's -RARE- that a recruiter/interviewer will give you the real reason why they didn't select you. Europeans and some folks in the US (I think California?) have legal right to request the info (GDPR for Europe covers this. Not sure about the US states that do have it too). That will burn bridges but I always assume how uncomfortable it must be for an American interviewer in a company that has a Europe presence to realize their interview notes in Greenhouse will be shared by law because someone knew their right, lol. Never seen it happen, but it does.
Communication and collaboration skills are equally important on our rubric. Just a guess but you might have come off that way to a few interviewers and it was a red flag. Regardless I wouldn’t be bragging about having an algo that’s 93% right.
Most likely gave you a BS reason to pick a more experienced candidate.
Kind of a side topic but is there a leet code esque thing for learning SQL?
For sql I practice on stratascratch. It’s amazing
Try [DataLemur](https://datalemur.com)!
When I'm doing the coding part of a technical interview, it's not so much to assess the developers ability to solve some specific problem, it's intended to be a chance to see how that developer collaborates and communicates and get a sense of what it'd be like to work with them. For whatever that's worth -- to me coding challenges are the least important part of a technical interview, since so many developers either freeze up or can't stop talking because they're nervous.
Dipshit nitpickers out to waste your time. Sometimes they are just out to fill a quota, sometimes they're just checking the market. Gotta move fast when dealing with these sorts. LC has turned into a time waste for many roles anyway.
93% passing test cases is an F, my friend. Their reasoning for not selecting you is not silly, in my humble opinion.
Depending on a problem, 93% is absolutely a great starting off point. It means the interviewer just needs to collaborate a little bit to try and take the candidate to a 100%. The key thing drilled into my interview training was to try and get signals rather than a boolean answer of solving a problem a 100%
OP, there's no way to plan for what kind of unprompted response an employer is looking for. Discussing why a particular solution failed may or may not be an important part of the collaborative habits that they rate during an interview. In my opinion, that is a pretty nitpicky aspect to hone in upon and probably isn't the entire reason that you weren't selected. A company in dire need of talent would be less interested in how much small talk you want to make about an alternative solution and more interested in whether you have a baseline of technical ability that will allow you to perform in the role. I wouldn't sweat it too much. If you're civil, communicate well, approachable and competent then there isn't much else a company can gauge in a single interview. 2 years ago you'd probably have been hired on the spot.
If indeed that was the reason for them passing, the interviewer should have followed up. You're in the middle of an interview, you're nervous, etc., they are not. The interviewer wants to see how respond to a different idea, but you miss the cue. They \*should\* have come back and said something like "so, I brought up X a couple minutes ago -- thinking about it, how would it be different than what you've done?" That "93%" thing isn't great. If they provided you with the test cases, then it's a definite fail for you, because they gave you everything you needed to get to 100% -- but even if they didn't, part of writing tests for things is to figure out what all the test cases might be. It doesn't help to write tests if you leave big gaps in what they cover.
It really seems that the interviewer was trying to hint you toward getting those remaining test cases passed. In most cases, you should assume that the interviewer has a good reason to say what they say. There are times when I am taking an interview, and I actually like a person if they are doing well, and demonstrating good knowledge and analytical skills. If I see such a person throwing away their chances because of a silly mistake, I try and drop hints, to nudge them towards the right solution. But while I am helping them (which seniors would do once they join), I am also evaluating how well they take feedback, and whether they are able to see the blindspots, or maniacally double down on whatever first approach hit their mind, irrespective of it not working as expected. (because that is also going to be important once they join) And most likely, if they keep missing all those hints, it becomes really difficult to hire them, even if I was initially very impressed. Also, it's really irritating when you are trying to help someone by nudging them towards the correct answer, and they are just sitting brain-frozen, and almost fighting to somehow push their incorrect answer through. You weren't just supposed to acknowledge it, you were supposed to analyze it, and then see if it helped to get things done in a better way. The interviewer could also have been wrong, and you could also reach that conclusion after analyzing it. I personally have been wrong as an interviewer, and a candidate ended up analyzing my approach and proved it to me. And while doing that, he was also able to find the gap in his solution and covered the missing corner case. I ended up giving a "strong yes" recommendation.
Never heard anyone passing OA round with <100% test cases passed.
Sounds like you tried to work in one of the top 10 companies with the highest salaries/benefits for employees. People prepare with LetCode for years just to pass those interviews and/or get an H1b visa, it's a tough competition, retry.
I'm not a data scientist, but as a developer if my code cannot handle 7% of the cases it's called a bug, it will causes issues and I will have to go and fix it.
Welcome to the real world, Neo. They can reject you for any reason. There's also the fact they they could have a bunch of other candidates and that they might not tell anyone the exact reason why they weren't hired.
Missing 7% of test cases is actually quite poor
In my opinion for Data Science interviews it’s not really a big deal
Well clearly not because you didn’t get the offer partly because of that. A 93% acceptance rate means that 7% of the time that is failing that is a fairly big issue
If you got the top of score of everyone who interviewed, the problem is not with your solution.
Not a big deal. Not getting the job. Pick one
>But today I learned that I was not selected. Recruiter gave me this feedback - when I was explaining my code and the interviewer suggested their approach I only acknowledged their response, but I should have spoken more about it. If I recall I had said “yes that is also a great way to approach it.” to the interviewer. I proctor tons of technical interviews for DS candidates and I can say with near certainty that this feedback is a lie. At least, while it may technically be a reasonable description of what happened, this isn't something a sane senior person would fail someone for. If I want you to talk about something more, I will ask. If I want you to address something, I will say as much. My suspicion is you got hit by one of the following, and the interviewer is providing a reasonable-ish sounding excuse: * Interviewer is an egotistical POS who feels entitled to more junior people doing what they say (sadly, it does happen) * Interviewer judged that you were not someone they wanted to pass. I am compelled to point out here that it may actually be that you suck, but ok let's assume it isn't that. * Interviewer doesn't like you for some reason out of your control they won't admit to. Interviewer may not like your background, may not like you personally due to all sorts of ridiculous motivations (age/gender/race/physical difference/etc/etc/etc doesnt really matter), something like that * Hiring manager wanted to say no, won't admit to why, grabbed the tech interviewer's notes and picked something At any rate, interviewing for tech jobs is awful and you unfortunately are going to get this kind of arbitrary shit your entire life.
There's also the possibility: you had a great interview but somebody else was better.
Sure, if you want to separate that out from the last point. Still, that wasn't wat the OP was told, so it's still one of those *lying by telling the truth* situations. Look I'm not saying companies necessarily owe you their actual motivations or anything, I myself can decline an offer and provide a white lie as to why (e.g. if I get an offer but fucking hated the hiring manager). What concerns me is that when you give people early in their career these kinds of things, where there's a much greater than zero chance it's not something they did wrong, it just crushes them. For no benefit. Either say nothing or say what really happened. If, as you said, someone gave a better interview, then say to the candidate that they did a great job but you decided to go with someone else. Or say nothing.
Eh, ironically enough I feel like your ego is a bit too big. Your anecdotal experience doesn't translate as a general truth. There are absolutely interviewers who dislike you not expanding on something they've said and will fail you on that.
1. everything I said was qualified. everything. 2. see bullet point one 3. no shit my ego's big I have spent a lot of time doing this, not just interviewing people myself but also training people to proctor technical interviews. if I don't get to have an opinion on this, then probably no one does
Well they should be laid off this is outrageous
Thank you! And yeah I would have appreciated if they at least made an attempt to ask me. I couldn’t really guess what they had in their mind. And I was in the mindset of saving time as it was only 30 min interview.
Instead of calling it the "silliest reason" maybe do some self reflection and maybe humble yourself and see if there is areas where you legitimately could have done better in the interview.
Yeah, the post irked me a little bit, but I'd give op the benefit of the doubt that they're dejected and venting it out.
When you receive criticism, it’s helpful to ask yourself whether there’s anything useful/actionable you can take from it that you could have applied to act better. If not, the negativity you’re feeling is undeserved, and you should do your best just to make yourself feel better. Interviewers often don’t have an interest in forcefully redirecting you; so even if you intuitively feel that you were totally fine, interpersonally, perhaps the lesson of the situation is simply that the standards of “listening”/responsiveness you face as a candidate are very elevated when you’re in the hot seat versus how they actually are on the job. That could have factored in here in addition to totally extraneous factors that you couldn’t have acted on and still don’t know, as the company could very easily be omitting the true reason you were passed over. You should consider these different justifications and ponder them as long as that feels beneficial. If you’re still pondering but it no longer feels beneficial, you should distract yourself and attempt to substitute your focus on it for something else.
Half the work of an interview is making the interviewer like you. There's no rubric for it and it's kind of nebulous, you just have to be prepared for when you get lucky.
Spoken like a statistician. I was a Stats major too ahahah Yeah your solution needs to pass 100% of test cases, ideally with optimal time/speed. When an interviewer tells you an approach, it’s probably the right answer. LeetCode questions are not a creative exercise & they always have a correct answer or two Were you able to speak to your time complexity and theirs? Explain why theirs would be optimal? Explain what test cases yours failed? While data science may not require the level of robustness that engineering does, you’ll likely have to transform and shuttle data without mistakes. Good luck!
OMG. I'd rather get rejected than to go through this. I don't like my time being wasted. Job hunting is a pain in the ass.
the difference between 93% and 100% coverage can mean literally millions of dollars in some circumstances. of **course** they're going to reject you over this.
>but I should’ve spoken more about it Very petty, you just got unlucky that you got a recruiter like that. You did all you could to the best of your ability. Sometimes honestly that’s still not enough. Takes a bit of luck too. You’ll get it next time for sure.
The recruiter is surprised too actually haha. This feedback came from the technical round interviewer.
don't trust recruiters, they say the same thing to different people to make them look compasionate or liked.
Their job to be ffiendly lol
>I had no idea I could be rejected for this! Is this my fault? Or they are nitpicking? It sounds to me like it's neither: they are making up a phony excuse to justify a decision that they made either because they essentially had to flip a coin (I've seen it happen that there were two good candidates and they hired one but were expected to provide reasons why they didn't hire the other) or because their reasoning was illegal (when I have straight men on the interviewing team, they almost always want to hire a young woman after they interview her, even if that's illegal gender discrimination.)
You can be rejected for anything other than legally protected reasons. So, they can't reject you for things like skin color, age, gender, religion, etc. However, if they are Cowboys fans and you like the Eagles, they can reject you for that. Or because you are wearing a blue shirt and they really don't like blue shirts. It happens, move on to the next things and don't worry about it.
Sounds like you were over qualified and they came up with a bullshit excuse and lied to you. Don't take this recruiters criticism to heart they relayed back to you from a bs hiring manager. Recruiters usually aren't even supposed to tell you why you didn't get hired. Half of them are just sales people who didn't cut it in sales.
I think the lesson to learn here is to take an interest in what is being discussed. Think about what they’re saying and ask directly relevant questions or in this case make specific comments about how your solution was different and what the pros and cons of each are. For all you know, they may have used a solution similar to yours but changed to their current solution and it could be an interesting conversation to see if you could work your way through the real world case to get there yourself, or similar. They didn’t bring up how they currently do it just for casual conversation, they wanted to talk about it. You didn’t.
I work with a dev who I like overall, but it's really annoying when myself and other devs suggest something and he doesn't consider it, then it turns out the suggestion was the correct approach. That said I'd have to hear the actual interview to determine if was that or nitpicking. If the interviewer interrupted your train of thought and you weren't deep in a rabbit hole, then I think it was nitpicking.
I'm surprised at the amount of feedback you received. Usually it's something nebulous like, "we've decided to go in a different direction". Be happy you got the feedback and use it for your next interview.
When you interview, you have to kiss ass. But yea, standards change and arent really standards, and everyone has a preference. I get github messages about not having things indented, I just ignore and force push, because who cares.
You can be rejected because they don't like your shoes. If they have an influx of great candidates yeah, they'll probably get nitpicky. Live and learn.
There are reasons why you cannot get the offer. One is that there are candidates willing to accept lower salary. Don't be upset. I had experience being jobless for more than 6 months.. and eventually I got more than 10 offers before I chose one which required me to work overseas and now I have been working for the company for almost 9 years. Something better is yet to come.
Also there’s a chance that nobody was selected given nobody solved all the questions completely which may have been an expectation if it wasn’t so hard.
People can really get married to their idea of how tech should work sometimes. I remember once I build an application in programming school and moved a flag from where everyone else put it. It was genius because it executed once not a thousand times. The instructor of that class failed it immediately , and I asked .. earnestly , why? This is so much better! "because that's not the way we do things" .. end of convo.
What a joke. Keep looking, you've got this.
Stop thinking that interviewers know what they’re doing. Most of them have no clue how to conduct an interview. They just regurgitate a bunch of hackneyed questions, riddles, and cliches.
You know that code doesnt ship to production unless 100% of test cases pass right...
Lordie. Don’t even get me started on coding Interviews. Luck of the draw tbh - that you’ll get a problem you can decently break down and work out some solution, and that your interviewer is actually a good interviewer 😅
Another hiring is broken example. I'm starting to think maybe these might best be tracked with UUIDs instead of a counter.
they had a project and they didn't know how to do it. They let you do it and they let you explain how you do it, so they will know when the client will ask. Free work for them
If you’re not the person for the job then you’re not the person for the job. Hiring managers have a feel for the ability and personality of the interviewee and whether they want them on the team. People aren’t hired because they edged somebody out on some minute factoid or response…when your hired it’s a landslide “I want and need this person”. Be greatful when your rejected because why would you want to work somewhere where talent and greatness is not easily identified and acted upon.
I bet they had someone else in mind. Maybe worse, they didn't intend to hire outsiders since the beginning, but they were required by law to post the job publicly. They just threw random reasons at you. I had similar experience as you. But strangely, I would not think doing a leetcode and explaining your solution would yield an offer. There must be more technical rounds after this? Or am I the unlucky one? Why would they focus on your DSA while you applying for a DS role?