Let’s have a discussion about what are the best question asked you in an interview. It can be also about Phoenix. Also, what is the best way to answer that?
Examples:-
So anyone can choose to answer and in the end, you can write your questions which you faced but don’t know the proper explanation.
My vote: these are terrible interview questions. 
I know man but these are just examples 
Why would I even need to know this? I am not going to extend Phoenix or contribute to it – at least I have no plans to do so at the moment.
Answering something like this properly would require that you actually needed to delve deeper – which is something I can’t imagine you would need in a normal web project.
They just want to know did you try to research this topic. I think they want to know how curious you are.
These are very good questions. Also it made me think about the first question. All I know is JVM is focused on objects and has a new operation and beam has tail call instructions.
Agree it’s a good question and can be answered several way. First thing I thought of without knowing that much about JVM is discussing aspects that are pretty unique to BEAM like scheduler, lightweight processes, message passing and concurrency based programming. If they follow up with OTP then go on to mention the core pieces that make all the former more accessible.
Also liked functional vs imperitive: well imperitive feels like garbage and… or to be serious seems good if you can speak on the origins and goals of I guess C vs Prolog and how imperitive’s path differs
Honestly, good interviews are a conversation. You can get more relevant information by having a simple conversation and trying to understand the individual rather than quizzing them. I’ve made a lot of my best technical hires by having a conversation for an hour and doing no deliberate technical/coding interviews. Given the context of the conversation it tends to naturally focus on more technical topics. You can typically get a good read on things like passion and curiosity and whether they value things you find beneficial for the organization/position. Sometimes a less knowledgeable but more hungry/passionate candidate can be a better hire. I very rarely go into an interview with prepared questions.
What do you mean by JVM? Can you translate? (sarcrasm)
This a so bad question to ask, because not all developers in world code in Java 
As @anthonator said just have a conversation and let things roll down the coast, and you will be surprised how a person can reveal itself, for the good and for the bad, after he/she starts talking without feelling pressured with interview questions.
The best interview question is:
Talk me about your Journey to become a developer?
Then things will just roll in naturally, and you just should make questions based on what the person is saying to explore/clarify more some subject, and keep in mind that questions should be of type open end, not black and white, or true or false.
Yes, It should be like that. But I’ve never faced this and they have predefined questions if you were not able to answer that. Then they will not select you.
I can only remember having those strict questions a single time (not counting applications to internships during studies), I have turned them down, I did not consider them a good fit for me, partly because of that, and also because they had a single “openspace” office with a huge monitor displaying a realtime ranking of “productivity metric”…
My current employer just sat down with me, offered a soft drink and we talked. Yes, they had some questions as conversation starters, but there was no “right” or “wrong” answer to them. This was the rough procedure about everywhere where I applied since failing studies.
Totally agree with anthonator. It’s good to discuss interview questions because of the realities of the world but conversational is ideal and if you can afford to turn down opportunities until finding that it’s probably the best sign you found a good team in my experience (having worked for about 8-10 tech companies by now).
My favorite was a bar interview with this legend in Victoria BC that goes from company to company with a band of loyal engineers. Could tell how well it was going by how many extra rounds got ordered. By the last we were talking about the nature of money more than tech. A curious mind is a curious mind.
Of course corporate in San Fran delayed a decision long enough that I couldn’t stick around. I guess they thought ‘good drinking partner’ wasn’t a legit escalation clause
But these are hidden, and subjective, requirements that are unfair to a large swath of candidates who don’t know the Secret Handshake to Successful Interviews. Maybe they’re introverted, neurodivergent, or maybe they were coached to not look desperate.
Or maybe they’re so smart that their past work experience has been a bore to them and did not warrant passion because they incorrectly think “anyone could have done it” while they did it in their sleep.
The question should be, “Can this person do the job for which we will remunerate them?” Not, “Do they enjoy coding for kicks and giggles in their free time.”
As long as the hiring process involves humans it’s going to be subjective. It all depends on what I, as a human, find valuable in a candidate for a given position. That fact doesn’t change whether I’m quizzing them or conversing with them.
Nothing I said is incompatible with that statement.
Never said that.
Just to be clear, are you saying, then, that we should not examine our subjective biases and ask ourselves whether something—passion/curiosity in this case—should be a requirement? And that we shouldn’t unpack why?
And the person on the other side of the conversation has to magically know what you subjectively value? Is this requirement on your job description? And even if so, how can someone even prepare for that if it’s unnatural for them to put on a performance act for you?
Do you see how this leads to unfair hiring practices that lead to homogenous engineering teams?
Thanks for your post - it’s always good to reflect on these things.
Sure. Just because the process is inherently subjective it doesn’t follow that subjective biases have not been examined. The reason why I personally value passion/curiosity is because complex, valuable problems can’t be solved without them. Never, in the history of invention, has anything meaningful been created without an active, persistent, inquiring mind. Maybe that’s not needed for some types of software, but I don’t personally want to work on systems like that.
Software development is (for the moment) a human-centric, creative endeavour. Human to human interaction is still key. Part of the hiring manager’s job is trying to figure out the balance of personality traits in a team and whether a new entrant to that team will improve or detract from the team’s performance. This is not something you can represent in an HR tick list or signal ahead of time to potential candidates - each candidate’s unique mix of personality traits has to be assessed on the day. And yes, if, as a hiring manager, you have little self-awareness, that could result in bias and a homogeneous team. A poor outcome for both the company and potential candidates, and part of the reason some companies will never get beyond mediocre. That’s life.
I won’t be losing any sleep over it. There is solid global demand for talented software engineers from any background. If your hiring practices unnecessarily restrict your talent pool then bad luck to you.
I’m not exactly sure what you’re arguing here.
I never said anything about requiring passion/curiosity in a candidate. Here’s the quote from me you’ve referenced. Emphasis mine.
I think you’ve misrepresented what I’ve said.
There is no magic to a conversation based interview approach. I expect candidates to be honest about their skills and what they want from their employer. It’s my job to determine the best candidate for that position. Not providing candidates with a study guide isn’t biased or inherently unfair. There are also plenty of people who find quiz based interview processes unnatural. So that argument can be made both ways.
I fundamentally disagree that the approach I’ve advocated for in this thread is any more unfair or biased than the alternative.
Having said that I do appreciate your perspective. I hope we can respectfully disagree.
At this point I think we’ve gone off topic so I’m going to disengage and let others contribute.
Do you see how this leads to unfair hiring practices that lead to homogenous engineering teams?
That’s funny, because I specifically wanted to give a job to what in the states we would call a ‘diversity hire’ and I argued that this person had huge potential, despite being really green, and was turned down on the grounds that they couldn’t pass an objective test (code a hash function) - which in my mind isn’t a thing I care about when hiring someone who, at least initially, is going to be doing mostly HTML/CSS.
Stuff like “tell me O(some function)” is silly. I interviewed somewhere where they asked me to come up with an algorithm to find best path network connectivity because their company has huge TB data sets and some of their clients have bad internet. I said, well, first of all, you should mail the data via sneakernet because transmitting GB over the internet can be hopeless much less TB (unless you’re amazon or google and even they famously roll in big trucks for that job) and two, just brute force it using a recursive algorithm. The interviewer said can you find a better big O? and I said, why bother? Do you have a billion clients? Machine learning (which they do) is all about matrix mults which is big O(n^3) on millions of activations and it’s not really a problem.
Didn’t get the job. Also this was an elixir shop, so if you’re reading this you might know who you are.
Really funny story, thanks for telling it. 
A big problem in the technical hiring process is indeed that often the interviewer has fixated on a solution they really want to see you implement and you are supposed to deal with their XY problem syndrome on the spot.
© Copyright Elixir Forum | Terms | Privacy & Cookies
