Thanks for your input, really interesting to read. Could you elaborate on what those biases are?
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
6 Likes
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).
14 Likes
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 Like
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 Likes
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 Likes
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 Likes
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 Likes
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 Like
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 Likes
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 Like
I can try to give a very rough outline.
Basically it was about writing a very, very simple REST API in Phoenix, that is running a process to periodically update database entries - with the crux that that process should also return database results, and the db update takes a rather long time to go through, so youād have to work around that bottleneck.
I made 2 key mistakes when working on this:
- I thought the allotted time for this was 30 mins, to 1 hour, which I thought was pretty demanding, but not unreasonable (time was not given in the exercise description itself, it was somewhere buried in a general guide - and it was a lot more time than thatā¦) So I did it a little too simplistic and went with āit works on my machineā
- the machine I was writing this on was not my usual linux laptop (I ran an update a day before, and it completely disabled the network drivers - so I could not go online with it, and couldnāt update Elixir/Erlang/Phoenix etcā¦) and instead set up the WLS on my Windows gaming PC. Which is of course considerably more powerful than what the guys in the interview tested it with. So what took 3s for me (which I thought was slow, but good enough given the specs for the exercise) took more than 10 seconds for them - and I admit that is not in the acceptable range anymore.
I had already thought of an idea to solve the issue in 2 (even though I forgot that it would be way faster on my computer than most work mules people use for coding), but I thought I did not have the time to implement it, and I would just explain it in the interview if it came up.
Turns out, that was pretty much the main thing they were looking for, among other things I left out. Like testing certain edge cases, extracting parts of the code to make it easier to test individually (once again because of time I thought I did not have), etcā¦
I did not mention my problems with the time constraints in the interview - I only found out about the actual time I should have taken afterwards - because I thought that would make me look even worse.
Big lesson learned here 
1 Like
Thanks for these in detail examples! As I am one of those first devlopers in my company (mid sized Ecommerce in Germany) and am sometimes involved in hiring it helps reflect on our own biases trying to keep them transparent to ourselves and thus trying to stay open to others opinions, experiences, practices and advice.
As long as someone is motivated, never stops learning and communicates openly, that person is a valuable asset to most companies out there.
2 Likes
I will try to keep the rest of my replies in one comment, and just mention the people. Not because I value their feedback less, but because the forum told me to do this in a suggestion text.
Interview processes are broken beyond repair, people bring a ton of unjustified bias and unreasonable expectations towards candidates and itās extremely rarely to āfailā an interview entirely through your fault only. 95% of the time both sides āfailedā.
I agree - and I already described a little bit of how we both failed in my case. Truth is, itās just really hard to gauge people in interviews, and there is no right way to do it. I would even say, the company I applied to did a lot of things right, a lot more than I would hope for in most companies (part of why I was so upset with my failure.) No company can take weeks to assess people, and if they doā¦ thatās pretty effed up too! You canāt take up a personās time like that, just to tell them āyeah, sorry - good luck.ā So I donāt really know how to fix that problem.
Just keep trying. It will be okay. Just donāt stop.
That seems to be the way forward, yes 
Itās not that easy to find the right fit right now, because I have a deadline at the end of this year (the latest) and other decisions to make that depend on my next workplace. I thought it would be fair to let my current employer know that I want to leave before I have sealed any deals for various reasons, but that also means I have given myself a timer - a generous one, but still a timer that is ticking down.
You had another longer post:
I donāt think you have to hold back being salty hereā¦ There were clearly some bad experiences you had, and I donāt know anyone who would not be angry about it, especially if you feel like it was not particularly your fault.
Have been in that position for the last 6 years. Happy to say I did not become complacent with my position, and did not just keep working towards being one of the āunfirableā people - which is why I am in this position now 
I actually donāt feel happy in my current job anymore, because I feel like I cannot distinguish between people following my suggestions just because I have been there from the start, or because itās just legit good advice anymore.
Very likely part of why it hit me so hard - I felt like I had overestimated myself over the last years. After thinking about the feedback I got, I think that might be part of why I failed - over confidence - but I am still confident enough in my skill set to believe I can land another job that really fits me.
Been there, done thatā¦ Lets not get into a discussion about monolithic approaches in general - but umbrella applications? I am glad we did experiment with them, because now I can confidently say: Donāt do it, unless you have an extremely good reason for it.
Man, I hope I wont ever have to deal with that. That is pretty much my nightmare scenario, doing development in a āpoliticalā way. Good thing you got out of that.
Big oneā¦ I have been part of most planing meetings for a long time in my current company, until I started working on pulling out, because I was thinking I might start to look for a new challenge, and I also thought that I had too many responsibilities combined in one person.
And then suddenly, I was given brain-dead coding things, pre-decided. When I asked why, I was told that āyou are not really good in UI design, and this one was really a UI questionā - but it was not, at least not entirely. That was what pretty much made my decision to quit final - if I canāt be part of the process, just because I am starting to hand over some of my responsibilities anymore, then I really donāt like what I am doing here.
That honestly just sounds as if they simply were not sold on your ways, and did not want to spare resources to pursue another way. In a way, it is way easier for a company to change or adapt, because they have many people who can just adjust a little to find a middle ground between new and old. And thatās what makes hiring new people so exciting - they can bring in some different opinions, different ways of looking at what has already been built!
If the company does not want to change at all, then thatās probably a red flag right there, and raises the question why they did hire you specifically in the first placeā¦
@Desty thank you for your kind words, and I absolutely agree with what you said at the end of the post
Thatās how I always tried to approach the interviews I was part of (on the employerās side of the chair.) And I absolutely believe I made a good case to my boss about the whys - you can teach a lot of people how to code in any given language, but you canāt find teachers for people nobody can stand.
I donāt disagree - I think itās really more about how to design your hiring process once you reached a certain amount of employees. How do you make all those people agree to certain values? Or look for them?
Phewā¦ idk if this was really better than doing individual answers, but here you go.
2 Likes
I think that is a very good step in the right direction.
There are human elements that are very hard to address in any kind of interview settingā¦ If someone gets nervous, they might seem like an undesirable person. If someone does not like someone in the interviewers, they might close up and pull out of the interview, even though they might be a perfect fit except with that one person. If someone just hits a bad note (saying something that is a bad meme in your company), but was really just trying to be funny. If someone dresses the wrong way for one of the interviewersā¦ and so, so many more small details that can ruin an interview for a really good candidate.
In the end, I think we have to come to terms with everyone just being human, and sometimes we miss good opportunities, because of some things that could turn out to be minor road bumpsā¦ On both ends. Thatās what I will take away from this experience. Seems like I hit the spot in the first 2 interviews, but failed to impress in the last one - partly due to my overconfidence, partly due to some bad communication on their part. But I stopped blaming either party. As we say in German
Mund abwischen und weiter.
3 Likes
OMG, at these moments I get glad I got rejected and didnāt get to places like these
It started looking to me like copy-pasting some code from StackOverflow without even understanding what itās doing. Same in interviewing: people ask questions they got copy-pasted somewhere without even understanding what they are for
I can say that I agree with these points and came upon them as well. Thanks for laying out and wording them nicely.
2 Likes
I think you understood what you can improve in the future: manage expectations early. If you feel a deadline is too unfair, just say it. Iāve had some fairly demanding homework assignments and I have outright refused some of them while saying more or less this: āpeople, in a real work setting Iād never try to code this in 2 hours because Iāll have to make compromises that are not representative of my best workā.
So Iād say in your case you should have:
- Told them early if the deadline was too short;
- Pursued them for a crystal-clear list of expectations for the homework (if it wasnāt already clear?);
- Ask a few general questions, mostly ādo you expect the logic of this to be exhaustively covered or are you looking to see how I would generally and on a surface level solve the problem?ā
Mind you, thereās a good chunk of interviewers that wouldnāt even answer #3; they expect you to figure it out which is not always fair. But when I was given a week to complete an assignment thatās realistically 5-6 hours of steady and calm work then I preferred to assume they want the detailed exhaustive version and not something surface-level.
50/50. I sympathize with you and I know it can feel out of the blue ā but part of the skills some companies expect is that you be able to hop on a meeting call and figure out whatās going on as you go. Hence, a good amount of interviewers would like to test that ability and not give you clear pointers as you enter the meeting.
Not very fair in general but somewhat fair when you understand what are they looking for in you.
As you said, you were out of the interview game for a while. That definitely contributed to your confusion. Being overconfident though? I wasnāt there but I think thereās a cult to (way too much) modesty in our circles and a lot of people judge you by the mere virtue of you not acting like a beaten dog ā happened to me several times. There arenāt many people (not only programmers but humanity in general) out there that do not mistake ābeing cheeky / joyful / playful + having some confidenceā with āheās an overconfident a$$ā. Thatās on them, not on you.
1 Like
And on the other hand, I just got rejected for a coding exercise where I did MORE than expected. Sometimes you just get a bad hand, I think.
Mine was an API project also, where I was expected to implement 3 mandatory features, and up to 4 optional features. I did all seven, plus included a comprehensive test suite for all 7 features.
After that, I didnāt even get a call, or any feedback on the projectā¦ Just an email saying I wasnāt the right fit. And this was after two video interviews where the fit was PERFECT - I got along super well with both interviewers, and all three of us agreed that my experience and goals were totally in-line with the expectations of the position.
This was earlier this month, my 8th month of searching everyday for an Elixir position.
1 Like
Man, I donāt even know what to sayā¦ that sounds horrible. And not even getting feedback?? You should definitely email them and demand feedback.
Hey there
I went through most of the hiring process, and I think I did more than asked for in the coding exercise.
Can you please give me some feedback on why exactly I failed? I would like to do better next time, but I need your feedback.
Regards
XXX
just something like that - customize for your needs.
EDIT: and if they give you some bullsht reason again, ask again. And again. And again. If they put you on spam, then you know they are shit and you are lucky you did not have to deal with them.
2 Likes
Oh, I did send a polite email like that, thanking them for the opportunity and requesting some feedback, and they still have not sent any reply, weeks later, so I guess Iāve been āghostedā. After a 4-hour code exerciseā¦ 
