A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standard...
For further actions, you may consider blocking this person and/or reporting abuse
I've mentioned this in previous posts -- I applaud the effort here. But I hate that we interview this way. I really, really, really hate it. Let's take the question about SOLID.
Why do we ask candidates this question? Are we trying to see if they grasp the concepts of OOP? Or do we care about the candidates ability to remember mnemonics?
There are much better ways to figure out if candidates understand OOP. Like... why don't we show them a function that has massive side-effects or that does too many things and ask them how they'd improve on it?
And honestly, if a firm can't figure out if a candidate meets baseline technology competence in 1 or 2 coding interviews, it is doomed. If a firm is bringing a candidate in for a very expensive 4-5 hour loop and wastes all of that time doing coding interviews as in a manner that would be more fitting of an oral examination at university, then they aught not to wonder about all the candidates that turn out to be bad behavioral fits for their company core values.
I agree with your concern, but also want to point out that SOLID principles does not apply to OOP only, but for Functional Programming as well as more higher-level design such as system architecture. If you take a look at the 12-factors, most of the concepts can be compared to SOLID principles as well as Q8 about nothing shared architecture.
So SOLID is actually a more general approach and the awareness of it is particularly useful. Maybe if the expected answer shouldn't be what every single one of them means, but maybe with examples of how applying those can help with building a better architecture/system/code.
You are correct. I shouldn't have gotten hung up on OOP. But my point still stands: Do you care about the ideas or about the acronym?
What about candidates that come from coding academies, or that went to school in non-english-speaking countries? If they understand the concepts but have never heard the acronym, are they at a disadvantage?
My guess here is that you will say "No, or course not", but that the very nature of the question itself will create scenarios where the candidate acts uncertain, and this will cause unconscious bias in your impressions as the interviewer.
But it's also means they don't speak the common idiom and it's going to be harder to integrate into the team/project/culture. It sucks to filter out those kind of candidates, but it's a heuristics to filter some candidates in case you have a lot. Depends on what kind of role you're looking to fill.
I agree it's not perfect, but it's a trade-off.
I would propose that if the idiom is so important to the integration of people into your team and culture, that your team and/or culture is exclusionary, and you have a much bigger hiring and staffing problem than "how to effectively interview developers".
Idioms and Acronyms that are unique to the team/firm are something every new hire has to deal with, but it's usually not hard to get up to speed, all it takes is an atmosphere where colleagues welcome questions (i.e. a "there are no stupid questions" attitude).
I agree with that, but that's the only differential in a candidate that is put to a scale, you choose the one that knows, so it's a priority criteria and not an exclusion one.
And you can say SOLID is not unique to team/firm but a more broad one. It's definitely weird to ask a candidate about unique stuff for your company (I've seen it and you shouldn't)
Respectfully, I think that's a poor criterion even as a "priority vs exclusionary" one - seems the risk is high - or at least makes the selection completely arbitrary - of missing on the better candidate on the basis of not recalling an acronym, which carries no practical value when the candidate understands and practices the concepts it represents. I truly hope not many think the way you do, and I mean that as kindly as possible. But something so trivial should never be "the only differential in a candidate" - you ought to find some more meaningful way to distinguish candidates if you want to be successful.
I'm an engineer not a name dropper. Have I seen or read abou all of the above at some point. Yes, along with a gazillion other things. Have I memorized persons, item lists, definitions, etc. involved. No. Does that make me a bad architect?
You are asking the wrong questions. Instead of asking people to be a nice school boy, sit up straight, and define the five solid principles, ask them to talk about coupling and cohesiveness in relation to good system design. Ask open questions like that and see if something sensible comes out. Bonus points if they name drop some SOLID principles. Hint, if you understand both metrics, you'll realize that SOLID primarily drives both of those and why these are important. The goal is not verifying that they name drop whatever you think is fashionable but whether they can talk in a sane way on these topics. Ironically, you can sniff out the bullshitters easily because they will start name dropping things they don't really understand. I've seen this happen a couple of times in interviews.
Asking open questions and maybe leading the conversation is a much better way of figuring out what a person knows, and whether maybe they know something you did not know. Figure out what drives them. What they are passionate about. Don't be that B hiring Cs. You need to be looking for As. That means you need people that add something to your team that you don't yet have.
And another reason of the huge flaw in our current structure for interviewing people.
Most, if not all, of these questions don't tell me at all if you are what I'm looking for. All these tell me is that you know and remember buzz words
Wow this looks like a college test
Thank you very detailed painted. I think you will be interested in this article about medical app development.
Many negative reactions to this but no proposal for a better way to interview in tech... Every style of interview is flawed (whiteboard problem solving, homework technical case, onsite technical case, technical conversation) it just depends on what you are looking for. The only reason i have had for a person to know definitions of technical words is if they put it on their resume... If it's on their resume they should know what those words mean. I have never asked the question "what is unit testing" if unit testing was on candidate resume during the interview i will ask how he resolved technical challenges that comes with unit testing complex software or components to understand 1/if he knows what a unit test is 2/his reasoning around unit testing etc... that would be the same for SOLID or Consistent hashing if it's on your resume you should be able to know what it is and use it in your reasoning around architecting a system etc... not a perfect method anyway, but i have had the luck that every people i have recruited with this method have never been scrubs.
I've never done interviews but based on my point of view as a developer, I think that's the best way to assess a candidate. You should ask questions about his experience. Anything he puts on his resume is fair game. A programmer's task is programming, not knowing about everything about every programming languages or concepts in the universe. You should ask him how he program, how he goes from getting a task and implementing a practical solution by following enterprise pattern. But you need a good technical interviewer to help with this.
Since no one else mentioned it... you lost my attention by the end of Q1. Asking about coding to interfaces is a great question, but has absolutely nothing to do with factories.
The title might be a little bit misleading but really appreciate the content. Never heard/have no idea some of the term. At least I can look at this post later as a cheatsheet 😁
And that is precisely the problem with interview questions like this - they beg for people to have a "cheat sheet" so they can talk about these things without really having a full understanding and being able to talk intelligently about them. I'd rather someone that doesn't know the acronyms but understands and practices the concepts.
"ATM" already has "machine" in the last letter, no need to duplicate that 😜 Nicely copied together though, thanks 👌
Love your articles, keep going :)
Would you mind adding system design questions? Like 'how to design a youtube clone'?
I came across this post this morning, and it actually annoyed me sufficiently that I wrote a rant/blog post about it
jmcpdotcom.com/blog/posts/2019-06-...