Had the same experience indeed. I once talked to CTO to find out why I was rejected. And the reason turned out to be just “we didn’t like you” 
Other rejection explanations also looked like trying to reason irrational decision
staring_frog
6
Desty
Definitely not something to worry about. Interviews can be extremely stressful, where it feels like the eye of Sauron is upon you for several hours straight. I’ve been in several interviews that tanked for various reasons… some because I froze in the spotlight, others because I just didn’t know the thing they really needed me to know, and others because the interviewer didn’t know what they were asking for.
One company had me come back on 4 separate days to interview for different teams. The first guy asked me to reverse a linked list, so I wrote it on the whiteboard in (tail-)recursive functional pseudocode and walked him through it. He was like “wow… looks correct, but that’s not really what I expected – I was kind of looking for a mutation approach… can you do that?”, so I started over and ran out of time after a few minutes… then I asked him to show me how he would have done it, and he converted the list into a bi-directional one. When I pointed out that this was not the problem he’d asked me to solve, he didn’t seem to understand.
Another place asked me to do a 6 hour interview. I said “well, I don’t know Ruby on Rails, which is a core part of your tech stack… if that’s a problem, I’m happy to cancel the interview?” and they assured me that was no problem and they were happy to teach new joiners.
After failing the interview, they called me up 2 days later and said “a bit of feedback from the interviewers – they said you didn’t know Ruby on Rails which is a deal-breaker” and then seemed shocked when I pointed out that this was something I raised before the interview.
A couple of times I’ve run into someone fresh out of college who has prepared a series of algorithmic questions where it seems like all he really wants is to prove that he knows a lot and I don’t. Usually I can sense this pretty early in the interview, so in future I’ll probably just bail when it happens, since it’s almost guaranteed that there will be no job offer.
The sad fact is that most tech employees don’t know how to interview, what they’re looking for, or possibly even why they’re interviewing candidates in the first place. In previous jobs I’ve been on the interviewing side quite a few times and remember a few points where the candidate got confused and frustrated, and I realised what we were asking them was basically stupid and unfair. Now I just look for people who have a reasonably good basic understanding of computer science, are interested in the craft, and seem basically friendly and clever. I don’t care if people are experts with specific tools or languages, and in fact have become suspicious of programmers who claim to be experts in anything.
Keep trying and don’t worry about bombing an occasional interview – each one is a chance to learn something that might have been missing from your toolbox (at least, if it was a good interview with smart people).
15
dimitarvp
I loved your take and upvoted but I’ll have to elaborate – and slightly disagree with – that part.
What you say seem to be tilted towards younger and/or less experienced candidates. On an interview I’d tell you with a straight face that I am an expert in big-scale refactors – and I really am, that’s been a highlight of my career. I never was afraid to get my hands dirty and repair problems (purely technical or of the tech-debt nature) that went super deep in code bases that spanned thousands of files. Sometimes not only reworking code but code plus infrastructure.
That’s coming from a 41 y/o guy who to this day is not convinced that he’s a good programmer. But with time I learned to recognize my strengths and weaknesses and nowadays I don’t feel bad to emphasize what I know from historical experience that I am really good at. I don’t idolize modesty because I know I am not bragging and I am confident in my abilities (empty bragging is something that’s long behind me).
Would I flunk an interview lead by you in this case?
1
cnck1387
I like this approach and it’s what I look for too in the limited spots I’ve been involved with around hiring.
I mainly do contract work for a bunch of different companies and once in a while when one of these companies are trying to hire someone they ask that I sit in on the interview and ask questions or just sit back and watch passively and then give my 2 cents afterwards.
The interviews were lead by someone else asking technical questions but I usually just throw in more casual / conversational questions, or try to get them to talk more about their thought process instead of the syntax of the implementation.
Personally, I don’t really care if someone knows the hardcore low level technical details off the top of their head. I’d be totally fine hiring someone who can communicate how they would solve the problem without actually being able to solve it on the spot.
Like, if they know how to break down the problem and can articulate what the solution would look like while explaining their thought process and what they would Google, that’s much more valuable to me than if they can remember an algorithm or specific syntax but can’t explain what they’re doing.
7
dimitarvp
Your local ElixirForum essayist checking in again! 
To answer you in one line of text:
The most common biases relate to tribal behaviour and becoming set in your ways.
Detailed examples below. They might be a bit salty I admit. 
-
Early programmers in the company worked a lot and made visible contributions to the business itself. The CEO and VPs of many departments know your face and voice and have confidence and trust in you. As time goes on however, you need more people in the team and those first programmers begin to conflate “I’ve been working here for 3 years” with “my practices are never wrong”.
-
Over-fixating on N amount of tech practices that, while working well, become an impediment in future projects. One particularly egregious example is umbrella projects. Ever had to use
mix xrefor various libraries that need to inject code in well-known places in your project? Well, if you use an umbrella application, I wish you good luck with that! Yet when we wanted to optimize compile times and break apart the monolith for other extra reasons, nobody from the team was willing to break apart the umbrella applications in smaller classic singular projects. Let’s start new umbrella projects! “Familiarity with a practice beats everything else and to hell with the future consequences. Not like I’ll get fired.” -
Become set in your ways because your work seat is not in danger and you go overly academical (because you wrongfully believe you have nothing else to learn in terms of programming skills; and because you vastly over-estimate your scientific knowledge). I’ve been told that one thing I offered as a practice was “OOP coding style and we’re coding in an FP language here” which was such an extremely out-of-the-blue thing to say that I actually was lost for words and didn’t complete the discussion. I was so baffled that I couldn’t talk for a few minutes. The funniest part is that was the first ever team to resist me on these practices; all other teams applauded the much clearer code that also enforced the single-responsibility principle that resulted after applying those practices. But that team? Nah. One guy just authoritatively proclaimed that I am offering an OOP practice. Fine!
-
Becoming territorial. I’ve been super delicate with colleagues on that because long time ago I was territorial as well and I know how uncomfortable can it feel when some newer hires start ripping your old and proven code apart. Things change however, and business / technical requirements are no exception. But for one reason or another, many programmers get attached to their code and refuse to cooperate. What’s even worse, they don’t tell anyone anything directly – they just become grumpy and hard to work with. When you confront your manager about it they just grumble something like “he’s been under stress, he’ll be fine, don’t sweat it” under their breath and never act on any feedback because obviously the company is afraid to lose one of its core programmers. And it becomes a vicious cycle that you cannot break. Most of the times the best thing to do is to leave the company. Or if that tickles your fancy, engage in meaningless infighting where you both are trying to one-up each other by competing who produces the most, in a vain attempt to steal the prestige status from the guy who’s been there for longer than you. Meh.
-
Monopolize planning and brainstorming meetings. On my last job I was expected to just blindly pull tickets out of a tracker because a project has been completely planned without me. I don’t claim that I have to be given decision-making rights as a new hire by the way – not at all. But when you hire a senior programmer, you don’t demote them to a drone that only implements ticket after ticket. I wouldn’t claim anything about any personal feelings or dislikes towards me; but it did seem that their idea of a “senior programmer” was “a guy who produces more lines of code per day compared to a junior”.
-
Refusing to learn new technologies and practices and clinging to what they already know. My first ever Elixir work was just me telling everyone to feck off and rewriting some super slow Ruby financial reports in Elixir, resulting in reducing the runtime from 210 minutes to 5-7. However, the philosophical question here is: do you want to fight with people so they see reason? As I get older, I refuse to do so. I turn my back and leave and I even stopped giving feedback if nobody asked me anything. (In another company, there had to be a meeting with 15+ people, 5 of which managers, just so a new girl could make the case against a Python monolith that’s been falling over and needed manual grooming roughly once an hour for the last year – and that it has to be rewritten in something else. They didn’t believe her, she left, then I was called to do the rewrite 3 months later, in Rust. Funny stuff.)
-
Requiring you to suffer through a nasty process as a rite of passage. I already addressed this above, just mentioning it here again for posterity. If you find yourself in such a situation, sleep on it for a day or two and be very honest with yourself: do you really want to go through that? Have courage and leave early if you don’t find yourself willing to subject yourself to somebody’s idea of initiating you in their cult.
There are more but I think I covered some of those that happen most often.
An important disclaimer is in order: a sharp-eyed reader might easily criticize most of my points by saying “but your wanting to do practice X was currently not a priority for the company so you come across as narrow-minded yourself by wanting to impose that practice regardless of the current priorities”.
That I answer with: yes, you would be theoretically correct but I became that way because there is never time to introduce the good practices in most teams, so I prefer to start making the case for them early. The above counter-argument has been used and abused tens of times in my career and in the companies where I stayed for longer time we never got to the point where the good practices were to be applied. So at one point and on I just started pulling the blanket towards my side of the bed. 
I guess I am indeed salty about some of my recent-ish past experiences so read my take critically and inquisitively and form your own conclusions. I don’t claim I haven’t been at fault in part of my past employments (in fact I am pretty sure I was very much at fault in some of them). But, I am a normal flawed human being after all.
12
Desty
No, because I only regard statements claims of expertise with suspicion and don’t treat them as an immediate “hard no” (god I hate that term). The idea of going into interviews with a checklist for rapid elimination of candidates is also not cool in my book. 
I grew up with Commodore 64 Basic, then GFA Basic and C/assembly on the Atari ST in the 1990s, and enjoyed programming ever since, but still wouldn’t call myself an expert in really anything (including the artificial intelligence topics I dealt with during my PhD). I’ve seen too many confident, even aggressive young programmers make oversimplifying assumptions and repeat phrases that reveal only a superficial understanding of the topic. For example, when people on one team started writing “REST service guidelines” with very opinionated ideas about how resources should be named, but when we discussed it, they had never heard of Roy Fielding’s thesis on the subject, and were really thinking in terms of the letter of the law, rather than spirit of the law. When I presented some counterexamples and alternatives to the naming schemes they were arguing for, they really had nothing else to say.
A few years ago, we had a more experienced programmer insisting that we could do a certain thing with Apache Spark on a local filesystem, exactly like we could on S3 storage, because “it’s just an abstraction”. He was confident about his expertise with Spark, so we took his word for it instead of investigating more deeply why it wasn’t working. As a result, we ended up stuck for several hours, before someone opened the source code to the filesystem driver in Spark and found that “yes, it’s an abstraction, but every abstraction has specific implementations which may still behave very differently”.
The more I notice things like this, the less inclined I am to make strong statements without seeing the actual situation more closely. I don’t want to be one of those guys who attends a presentation about some difficult problem that the presenter took 6 months to solve, and then interrupt them with a question like “why didn’t you just do X? You could just do Y, obviously… this is a trivial problem”, when of course the speaker probably tried X and Y right at the beginning.
There’s an interesting philosophical discussion to be had about when it’s the right time to be modest or circumspect, and when it’s the right time to be confident and forthright – and I don’t know the answers to that either, coming from a 39 year old guy who also is not convinced that he’s a good programmer
6
Desty
Oh yeah, I had exactly this experience on one team. We had an extremely messy, slow and difficult to maintain/extend Python program that used a TensorFlow model to do image classification. I was new at that company, as was another colleague who was supposed to add a feature to the Python application.
Instead, he rewrote it in Elixir (just out of curiosity – he had never used it before, although he knew some Erlang) and told me about it, saying he wanted to get it fully working before telling the rest of the team. I was like “you absolute lunatic. Nice one”.
About a week after he started, he told the rest of the team and did a demo, showing that the Elixir version had fewer lines of code, solved a bunch of bugs in the old system, and was waaaaaay faster since it had a built-in queue and backpressure mechanism. I was able to extend it after spending only an afternoon or so going through the Elixir tutorial.
Eventually it became an integral part of our team infrastructure and worked without any major problems for about a year, before some more senior engineer was hired on another team, who decided to make it a political goal to get our system shut down because “if you leave, who will be able to maintain this? They’d be forced to rewrite it from scratch”. So it had to be rewritten from scratch in a more politically acceptable (JVM-based) language (even though this seemed to be exactly the worst case he was describing, yet he forced it to happen). Afterwards, it had maybe 5 or 10 times as many lines of code and was much more complicated and now almost nobody knows how to contribute to it.
10
dangdennis
This has been such a fun thread to read. Thanks for sharing so openly everyone, especially those with a more decorated history than my short one.
——-
Regarding the hiring majority statement, I wonder how true that is.
If taken, then I’ve been lucky. The managers that have hired me and the people I look to hire now are those that can think independently and care about the work, regardless whether they write less or more code. Software dev is so creative, so hiring any less really hampers that.
I moved from enterprises to now a startup. Most of my teams and teammates strove for competence and diligence, while recognizing our limits. Phew, I do hope this isn’t the monitor cuz it’s great.
1
Ninigi
Thank you everyone for sharing all those stories, experiences and just general interest.
I did not really feel like checking this post for a few days, I had to process the situation first.
But now I should clarify:
- the code exercise was a “do at home” task, not a live-coding (I know, my first post was absolutely not clear on this)
- the interview was the last in a 3 (and a half) step interview process, the first two interviews were with HR and Engineering reps, the last one was with 3 people from the team itself
- after the first 2 minutes in the last interview, I started to feel like something is wrong, there is no connection - and it just felt off. I got nervous, because that is usually not my experience - I am not the type of person everyone loves on the first meeting, but I usually get along with everyone well
- the code exercise was brought up later in the interview, and I realized that what I did was way less than expected - and that was my explanation of why the first part of the interview was so rocky/rough - they had already decided that I would have to be the most amazing guy to be considered…
I will post replies to individual questions/comment directed at me - I am kind of overwhelmed how many people are sympathizing with me here, and I want to thank every single one of you.
3
Ninigi
Thank you for the encouragement. I have been out of the interview game for quite a while, and I am ready to admit I did probably not leave the best of impressions. I misunderstood the purpose of the last interview, I thought it would be more like meeting my future team-mates, giving them some time to get to know me, and then let them decide if I would be a good fit character-wise. I did not expect it to be more focused around my expertise so much - and since I picked up the general mood of “not sure about this guy…”, I got more and more nervous and started to babble, instead of giving simple and clear answers to very reasonable questions.
My fault in this was not preparing for the interview in the way I should have - instead of telling them about “myself”, I should have told them about my “professional self” when they asked “why don’t you tell us a little bit about yourself.”
They could have made clearer what the last interview will be about I think.
But I feel like I am over it now - I accept the feedback they gave me, and I agree that the last interview did not go well. I will just take that as a lesson, and get back on the wagon.
1