14 ms·
Ask HN: What are good software architecture interview questions?
- arethuza 10y agoWhat is the role of an architect? What architectural mistakes have you made in your career - what did you learn from them? What architectural decisions are you proud of - how relevant are those ideas to other systems? How much code should an architect write? Have you been responsible for maintaining a complex system that you didn't design?
- AstralStorm 10y ago1 and 4 is matter of opinion. Too many ways to answer it correctly but incompletely. Number 2, 3 and 5 is asking about past jobs and may be even illegal depending on the applicant. NDAs are everywhere. Rephrase them to be generic. Number 5 is worthless yes/no type of question as well.
- keyboardhitter 10y agoWell, I don't think interviews are always about answering something correctly. It might just be nice to have an applicant's opinion on x y and z, to spark conversation, gain some insight into their personality and what is important to them, etc. In my opinion, discussions like that can be invaluable: sure, someone might have all the technical answers correct, and if so that is great. But humans are more complex than just being right or wrong. It's also good to see if the candidate has a similar view on the role they would be fulfilling.
- arethuza 10y agoThanks - that's what I was getting at. I was in a bit of a hurry (OK in a conference call) when I wrote those questions ;-)
- arethuza 10y agoWell, we can disagree on those points... On the subject of writing code - the question is really trying to find where on a spectrum someone is from: "Code, I don't write code, I draw UML and throw it to our offshore development partners" through to "I always keep all the most complex and demanding parts of the development process to myself as everyone else is an idiot and only I can realize the amazing architectural vision I have <maniacal laugh>" [And yes, the space probably isn't one dimensional and those probably aren't the endpoints] :-) I've known extremely successful "architects" (in terms of £££$$$) who fit both of those descriptions...
- b4xt3em4n 10y agoWho pays?
- SoulMan 10y agoYes but only @ 75 percentile .
- british_india 10y agoTell me about a technology you were initially excited about but that later you regretted using?
- arethuza 10y agoI'd be tempted to reply "All of them" to that question :-)
- deleted 10y ago[deleted]
- caleblloyd 10y agoThis is a great question. The converse would also be great: Tell me about a technology you used in a project that you didn't later regret using?
- terryjsmith 10y agoAs with any interview, I like to make it as personal as possible. Tell me about something you have architected and why you've architected that way. I will ask probing questions about why you chose this stack, this database tech, this integration layer, questions about security concerns, areas for improvement, what you learned and would've done differently, etc., etc. This also allows you to see the interviewee's excitement and really turns the table to put them in a comfortable position where they are the most knowledgeable person, which makes for a much smoother interview. If that goes well, I may turn to some specific tasks or problems we have faced or are facing and discuss at large how those might be addressed, again really focused more on brainstorming than any "right" answer. If you don't have any projects or work to talk about, the interview is basically over as I don't see much value in talking about cookie cutter problems.
- pacaro 10y agoAlso, what were the pragmatic trade offs: CapEx vs OpEx; development time vs quality; etc.
- corysama 10y agoThis is great stuff. A fun bit to add is "That thing you made, if you had more time, how would you make it better? How would you make that version better?" And, so on until it start to get a little ridiculous.
- maxxxxx 10y agoI do the same. With people who actually know something an interesting conversation will develop. A lot of "architects" will only repeat generalities and have nothing left to go deeper. I also don't like too many buzzwords like "integration patterns" or "serverless architecture".
- technophiliac 10y agoHow do you communicate your "design" to others (stakeholders, developers, ops, sec, etc)?
- lepunk 10y agoI normally go with: "If you could do it from scratch how would you implement the infrastructure of X" X being a currently widely known service (I'm usually going with Spotify). There is no "right answer" to this question but this shows you how the candidate thinks and how well they can protect their opinion if challenged
- sjeanpierre 10y agoThis is a very good one, my default is usually Instagram
- Cyph0n 10y agoThis sounds like a fun question, and seems interesting and engaging for both the interviewer and the interviewee.
- garysieling 10y agoOne of the fun things about these questions as an interviewer is all the answers end up a little different, so you end up learning something. While that's not the prime goal, it is nice if a candidate uses it to teach you something :)
- itsmeduncan 10y agoA great "how would you architect X" is Uber. Lot's of hidden complexity.
- madiathomas 10y agoDo you first ask them if they have personally used the service X first or you assume they know and have used it because it is "widely known"?
- garysieling 10y agoI like questions like this, but I always give an explanation what the service is, in case the person freezes up in an interview situation.
- bsvalley 10y agoYour question is too broad. Which industry? Which type of products? which technologies are you referring too?
- nichochar 10y agoI once received the question: let's architect a web browser. This was for an interview for backend engineering at uber, so by no means did I have any particular knowledge or speciality in browser design. Because I knew the product very well from a user's standpoint, and common knowledge about web standards, it was really fun and exciting to figure the architecture out. Typically the questions revolve more around: "How would you design twitter/pinterest/facebook newsfeed?"
- huac 10y agoI got the "how would you design a news feed" (and similar) for data science positions as well fwiw.
- patio11 10y agoTake an actual problem that your team solved. Distill it down to essential elements. Wargame out plausible solutions to it if one didn't have your team's context on your particular situation, particularly plausible solutions which would be top-of-mind to a smart, stressed person operating under incredible time pressure. (Your actual IRL solution should probably be one of them, but don't assume it is the only solution, the most likely solution, or the only passing solution.) Take insights out of those wargamed answers (e.g. "Ahh, this is performant", "Ahh, this approach fails loudly when our infrastructure is in a degraded state", "Oof, this creates a SPOF... not desirable here") and write them in a list. Group them by theme. Try to have somewhere between 5 and 10 themes. For each theme on the list; make 3~5 variants of things which show the insight(s) related to the theme at varying levels of quality/discernment/depth/etc. Assign an appropriate numerical weight to that tier of answer. Your list is now two-dimensional; in teaching circles it would be called "a rubric." Grade interviews against the rubric. On security, this candidate said X, Y, and Z, which are elements which most closely match a Good answer; 7 of 10 possible points awarded. Even better, grade written notes taken during interviews against the rubric. Now, and this is the brutally organizationally difficult part, stop overriding the rubric when it spits out point values which imply next steps regarding a particular candidate that are clearly not what one wanted to do. Instead, fix the scenario and/or rubric.
- cheez 10y agoThis a nice list of interview questions. How does one actually go about getting the experience to answer these with expertise?
- sethev 10y agopatio11's comment reads more like a method for evaluating answers. You present the candidate with a boiled down description of a real problem and then evaluate what they say against the rubric. All that to say you answer the questions by actually having expertise in the subject area of the question.
- cheez 10y ago
- beat 10y agoNot so much a question as an approach, but... When interviewing senior people, I like to get them going on war stories. "Can you talk about a project you experienced that went very badly?" is a good one. It's not necessarily that they went badly, but we've all been on death marches before (and I absolutely would not hire an architect who's never done a death march!). The beauty of this is you can find out how they react to impossible demands and pressures. What they're proud of accomplishing in dire circumstances. Possibly what they're ashamed or embarrassed about, or mistakes/lessons learned (if they're that bold). You can learn a ton about how they talk about their colleagues! Are they full of praise, or contempt? Do they find someone to blame, or talk about how someone else saved their asses? You can also learn a lot about their actual approach to technical decisions - their taste, for lack of a better word. You can ask probing questions here, but the important part is to get them speaking in an unguarded way. Nobody makes it to the architect level in this field without at least kind of loving the job. Find out what they love. Find out what they hate. Find out what they regret. Find out any strong technical biases they have, and why. But most of all, find out how they play with others. Because the architect's job isn't just to design, but to communicate. You don't just want a technical expert. You want someone that can value and respect the rest of the team, or they're just going to cause problems.
- ryanx435 10y agoWhat is a death March in this context?
- popey456963 10y agoYou continue even though you're doomed to fail.
- troebr 10y agoI've heard Death March more meant as a crazy period before a deadline.
- enraged_camel 10y agoNo, a death march refers to the pace of the march, i.e. you're marching so hard (without rest) that you start losing troops to fatigue or worse.
- MrQuincle 10y agoNice for the reading list: http://aosabook.org/en/index.html http://aosabook.org/en/index.html Practical overviews of design decisions in familiar open source software. I wish there were books like that!
- cableshaft 10y agoThese look amazing, and some really high profile projects as well (Asterisk, Audacity, Eclipse, LLVM, Mercurial, Git, GDB, MediaWiki, etc). Thanks for that! I wish there were more books like these.
- MrQuincle 10y agoNice for the reading list: http://aosabook.org/en/index.html http://aosabook.org/en/index.html Practical overviews of design decisions in familiar open source software. I wish there were books like that!
- rb808 10y agoYou should make sure they've actually stayed around in their companies a few years to see how it actually behaves. I've seen a bunch of architects that regularly move on to the next hot project, before the old one is properly completed. The architect never sees all the problems that come from their grand ideas so they dont get to learn what is practical. There is a big difference between architects that know all the hottest tech and buzzwords, and an architect that can deliver a reliable and maintainable platform.
- alistairSH 10y agoI wish I could triple up-vote this. I've worked with a few architects who were great at envisioning fantastic, pure systems that looked great on paper. But, were nearly useless at actually building these systems and making them work in the real world. That might be ok if the role is a pure R&D role, where they're "playing around" with the latest technology and ideas. We have some of those positions at my current employer. But, it's not very good for an architect who will be embedded with a team of developers.
- tyingq 10y agoAsking them to whiteboard out software design thoughts, risks, etc, for things we all commonly encounter can be revealing. Things like an ATM, slot machine, bank of elevators, red light cameras, and so forth.
- codr4life 10y agoToy problems get toy answers, you'll learn nothing that way. I couldn't care less about traffic lights and elevators, and I can code circles around many.
- LoSboccacc 10y agoSome of my favs when I was recruiting, all meant to probe attitude more than knowledge. What was the worst requirement you had to meet? Where would you store 100Mb user data? 10Gb? 1000Gb? Preferred deploy to production strategy? Worst process you followed? ..what did you do to make it better?
- arethuza 10y ago"What was the worst requirement you had to meet?" Thanks for mentioning that one - it means I get to think of a sensible answer rather than convulsing in laughter for a few moments. It did involve physical buttons for "Burger", "Beer" and "Porn".
- OliverJones 10y agoAn architect's role often has an economic as well as a technical part to it. So, it's important to find out whether your candidate has a strong loyalty to a particular vendor stack. Ask. After you've had a conversation about a project in the candidate's track record, ask some pointed questions: -- what would you lose in performance and functionality if you reworked that project to run on cheaper infrastructure? (By that I mean such things as "standard edition" rather than "enterprise edition" of DBMSs, open source vs. paid licenses, etc.) This is a good way to get a handle on the candidate's economic reasoning ability. -- what was a significant performance bottleneck in that system? How did you address the problem? -- with the benefit of hindsight, what parts of that system would you say you overdesigned? underdesigned? -- what was a security vulnerability in the system? How did you plan for security? If you had to do security remediation, please describe it.
- z5h 10y agoHow could you detect possible plagiarism between documents in a large DB of documents? Given such a system, how could you process a document to subvert it? How would you fix the system? How could you subvert the fix? ...
- kyrra 10y agoAs someone else says, it depends on what you define as a "software architect". A co-worker from a former company that was a "technical fellow" and "technical director" (effectively an architect, at a 12,000 person tech company), came over to Google and just has the title of "Software Engineer". From the companies I've worked at, software architect covers a lot of different job descriptions. At Google, more senior software engineers will have a "system design" type question as part of their interview. There are sample problems for this all over the internet[0]. For example, you could ask them "Design a URL shortening service like bit.ly.". When you ask open ended questions like these, there are so many parts of the system you can dive into that you can really test the depth and breadth of a candidate's knowledge. [0] https://www.hiredintech.com/system-design/ https://www.hiredintech.com/system-design/
- delroth 10y agoIf I remember correctly, the system design interview at Google is for software engineers candidates of all levels, not only the more senior ones. I was definitely asked one of these problems when I interviewed as a newgrad.
- alphanumeric0 10y agoThis is specific to my codebase I was interviewing candidates for (heavy OO). Not all of these concepts are necessary for the candidate to understand, but a few go a long way towards a great developer experience when applied correctly: - SOLID principles - The Expression Problem - DRY - Dependency Injection - Composition vs Inheritance vs Delegation - Connascence - Law of Demeter - Invariance, Contravariance, and Covariance
- pcsanwald 10y agoMy general line of questioning is as follows: 1) Explain to me a system you built/architected. How it worked, what it did, etc. I'm looking for a deep understanding around the requirements of the business, and how that played into technical choices. 2) Talk me through some bugs you encountered or mistakes you made, and how you course corrected. I try to make a candidate comfortable prior to asking this and usually tell a quick and horrifying war story from my own career. Here I want to understand how a candidate processes information and adapts the plan accordingly. Like mike tyson said, everyone's got a plan until they get hit. 3) If you had to build the system again today, what would you do differently? I'm looking for an awareness of how technology has evolved since they designed the system in question, as well as what didn't work well over time from an operational perspective (e.g. we didn't burn off time series data over time so table index rebuilds started to take forever, etc). I want to make sure the candidate supported the system they designed over time, and felt the pain/benefit of their decisions. I usually specifically ask the candidate at the beginning to pick a system they built and supported for an extended period of time. I also ask about areas of technical expertise, and areas where the candidate feels less strong technically. For the former, I make sure they have the kind of expertise they claim, and for the latter, I want to see how they communicate with team members that are expert in those areas (and how they gain familiarity with new technologies).
- jwilliams 10y agoLots of good answers here (and in this thread in general). I like to focus on the person's history and dig in - war stories for sure. For a software architect you should get a lot just from their CV/Resume. In the interview you get to test how valid and deep this experience is. To your list I'd also add some human factors. Some behavioral interview questions about dealing with difficult people, entrenched opinions, people under stress. You've also got questions such as "what is your favorite/last book on this domain and what was your take away". Or more generally what you like to read and how you stay in the loop.
- BurningFrog 10y agoI just don't remember enough of old projects to answer these questions in any detail.
- siliconc0w 10y agoGive them a sample, 'The company you thought you're interviewing for is just a smoke screen, we're actually a stealth startup for a social network for pets" and have them diagram out how it might look for a MVP launch, 2 years in, 5 years in. What technology choices, how are they going to launch internationally, scale to hundreds of millions of pets, how are they going to achieve sub-second latency for the FindMyPet API, high-availability, do operational and business intelligence monitoring (and which BI metrics would he care about), unifying code across multiple platforms, etc. Most importantly they should light up when they get the question. Like someone just sat a piece of cake in-front of a fat kid.
- itaysk 10y agoI've written about how I interview here: http://blog.itaysk.com/2016/07/07/how-i-interview http://blog.itaysk.com/2016/07/07/how-i-interview
- cromulent 10y agoOne of the twelve principles of the Agile Manifesto is "The best architectures, requirements, and designs emerge from self-organizing teams." Does your style of architecture fit well with self-organizing teams?
- tootie 10y ago"How do you come up with estimates?"
- donretag 10y agoPlease implement on heap sort on the whiteboard. Let's face it, we would all love the meaty architecture questions, but most interviewers are still stuck on the CS101 algorithms.
- luckydude 10y agoHN doesn't seem to like mine, but I've always asked "tell me about some project, can be a tiny shell script, that you did entirely by yourself: the code, the docs, the install". It has to fit through the filter of nobody asked you for help, if they sent you a thanks, that's cool, but they need to be able to install/learn/use it on their own. If someone is claiming to be an architect and they've never done that, that's a red flag for me. Kinda like asking a building architect to talk about framing. You'd be surprised at how many of those guy have never swung a hammer and they "design" stuff that can't be built. Sort of the same with software, IMHO.
- civilian 10y agoThe ORCA card system in the Seattle area is a great architecture question. You have a bus/transportation system that has: 1. RFID cards that tie into 2. Electronic wallets 3. The busses are not always internet connected 4. You need to be able to refill your card either online, or via kiosk. 5. You also want to be able to refund card balances. What system can solve this? What drawbacks would the system have? How could the system be scammed? Bonus questions are: "6. The LINK rail allows you go scan your ORCA card when you get on and get off the train, so you only pay for the number of stops you're on. How would you include that? 7. ORCA cards also allow for free transfers-- so if you take a second ride within 3 hours, it will be free. How would you include that?"
- drharby 10y ago"If you were the size of a quarter and trapped in a blender, how would you reconcile having a dime-sized 'package'" I forget the blog, but it was from an unused script off of silicon valley, interviewing for a new CEO of PP.
- KirinDave 10y agoSoftware architecture questions are an interesting topic because unlike software implementation, you cannot simply give someone a task and ask them to demonstrate it. Architecture is not just a matter of selecting components, it's about understanding conflicting roadmaps for multiple teams and available human talent and technical resources. My favored approach for it has been to ask people questions that mirror problems I've been forced to solve in the past at the current venue you're hiring for. I think this approach has a number of advantages: 1. You know how YOU solved the problem, so you've got at least some qualifications to discuss it with authority. 2. You can answer any and all questions the prospective architect wants to ask. These questions and their quantity are often even more telling than any hastily described solution ever could. Do they ask about infrastructure? Do they ask about expertise? Do they mention specific tooling you yourself decided on? 3. This gives them a chance to wow you in a controlled environment. If their idea for a solution is better than yours, you know you have a very high value candidate. 4. This also is a supreme test of technical communication skills. They need to rapidly get YOU to tell them things by asking questions, formulate an idea, and then communicate it to you in a way you can understand. Of course this assumes the interviewer has done some architecture, but I think that's probably required to do this job right. Personally, I think all this talk of "war stories" and whatnot is not a very good idea. If you're concerned about someone's personality and grace under pressure, you should treat that separately from their technical skills. That way you can weigh those attributes separately and fairly when it comes time to decide if you will hire the candidate.
- paulkearney 10y agoI'd go with: 'What do you expect to be involved in as a software architect and what can you contribute?' and take it from there. If you are interviewing for that role then surely what they do in the context of your organisation is key and open questions help you understand whether the person is a fit for that.
- otikik 10y ago- Tell me about a problem related with software architecture that you find interesting, and why. Take your time. - Tell me some pros and cons of a library or framework that you have used recently. - Here's an hypothetical problem (describe the problem). How would you approach solving it, from the point of view of software architecture? Please think aloud and ask questions, the idea here is getting to know how you think, not necessarily arriving to a perfect solution.
- ChuckMcM 10y agoFor me, the single largest differentiation between "senior programmer" and "software architect" is whether or not they can see the actual problem. The catch phrase is "see the forest for the trees" but in software it is recognizing you're in a forest and then understanding forest type issues. I was on a team that was nominally building a "video encoding protocol" because that is what they were asked for but the problem they were solving needed a remote procedure call protocol. Happens all the time, a person wants to buy a waterproof computer, but really what they want is to see the results of a program while they are in a rainstorm. Or they want a "website for managing inventory" but they really want a way of tracking employee theft. So architects listen to the problem statement(s) and think about what is in play, will ask some clarifying questions and then reframe as the actual problem statement. A senior engineer will ask evaluation level questions (how fast, how much memory, etc) and come up respond with a solution to the stated problem. A bad software architect will not be able to stop abstracting and will start with a 50,000' view and then float into orbit. A "good" software architect will add in the business or operational constraints to the problem and articulate where the ceiling is and why.
- SoulMan 10y ago>single largest differentiation between "senior programmer" and "software architect" I am glad that you brought this up. My question was more from a perspective of distinguishing senior engineer vs architect interview questions. There is only a limited time in the interview. Shouldn't an architect be also asked the senior engineer questions in addition to the ones discussed here. Especially my our org setup they are also hands-on and individual contributor to the code base. One solution could be to restrict the 1st couple of rounds of an architect interview to senior engineer questions only . Fair ?
- ChuckMcM 10y agoIf you don't mind I'm going to go a bit 'architect' on you :-) Do you need a software architect or do you need a senior engineer. Interview questions are about finding out if you should say 'no', by definition if someone is called in for an interview you've tentatively said yes to them for the job you just want to know if you should change that to a no. So the problem set is understanding if the applicant in front of you will be able to do the job you need done. Your comment that "in our org ... they are also hands-on" is the an echo of the Joel Spolsky 'architecture astronaut' type. Someone who spends all day architecting and none of their time coding. But here is the thing, at the end of the day its about how much product the organization ships at the end of the day and whether or not that product had does the job it needs to do right? So there is some nuance there to consider. I certainly believe that anyone who considers themselves to have software architecture skills, should also be able to do anything a senior engineer can do caveat a deep discipline/subject matter engineer[1]. So interviewing for senior engineers will also get candidates who show architecture tendencies, and you will recognize them because of the questions they ask. If you want to provoke those questions then leave some of your coding or puzzle questions a bit ambiguous to see if they let their ideas play out or if they are sticking with the task. Here is the thing though, you can have lots of really good programmers and all they need is a bit of structure around where they are going so that together they can make something awesome. That needs an architect who is spending all of their time keeping everyone on the same page, and if changes need to be made, moving to the new page. If your programming team is fairly senior and just "gets it" and will work out amongst themselves which parts need to fit with the other parts, then you just need another senior engineer like that. In my experience though group 1 is more common than group 2. [1] There are irreplaceable senior engineers who have become so deeply expert in a particular technology you don't want them to do anything but own that code.
- nicostouch 10y agoGive me an example of a violation of the Liskov Substitution Principle that is not the canonical Rectangle/Square example.
- jgalloway___ 10y agoLooking over their public work experience and perhaps open source contributions you will already know if this person will be a good fit. When tasked to interview I have found that asking a question which you know the candidate will be unable to answer will show you the most-intriguing parts of their character. Something deceptively simple like a puzzle or logic problem but scales up quite quickly. This is when you can learn things about them that they would not put to paper and thereby determine if they are for you.
- jblow 10y agoIt's not specific questions that are important so much as the process. You want the questions to be tailored to the candidate. See this example: https://www.youtube.com/watch?v=cfyWvJdsDRI https://www.youtube.com/watch?v=cfyWvJdsDRI
- gayanhewa 10y agoOne of my fav is to ask their preference on Composition vs Inheritance. It's a fundamental question that will give you lot of insights on how they view building applications to last.
- neeleshs 10y agoMy favorite way is to start with a very vague design question, with no expectation of any predefined answer. Then I try to make it a discussion, see if the candidate asks more questions, pokes around, can think in terms of abstractions - I don't expect any of it to match my own thought process. Another question is to pick a project they've worked on, and ask them how would they do it if they were given a clean slate.
- femto113 10y agoFor architecture I prefer to just ask for input on an actual issue my org is currently facing. Perhaps abstracted a bit to make answering less of a slog through details but I don't see any advantage to using some made up scenario. By using current issue I'm in both a good position to interact on the subject since its top of mind and get a sense for the relevance of the candidate's experience and/or their creativity. Also means I don't need any better rubric for evaluating their answer than "if I'd heard that in a meeting today would I have thought 'oh there's a good idea...'"
- pm24601 10y agoAt Evernote: 1) Peer presentation - talk about past project 2) System design - design at the high level 3) Debugging - given a failing test fix the code so the test passes. 4) Coding - Straight forward problem to code and create. For the peer presentation, we are expecting the candidate to be prepared. They have lots of notice about this portion of the interview. We want them to be articulate and clear about the technical problems, project management problems and unexpected issues. System design - we come up with a sample issue that is easy to articulate quickly. For example, "we are going to design the first version of Wordpress". We then ask questions and extend the problem during the interview. Debugging - we give them a random open source project and we break one of the unit tests. We then ask the developer to track down and fix the issue. Coding - smaller scale than the System design question but focused on determining if the candidate can construct a small program end to end. So this is not a portion-of-a-program, but rather construct a quick command line program to do X. For junior people we drop the peer presentation and add additional coding questions. -------- I liked this interview the best of all the places I interviewed. There was no "gotcha" and the problems I was asked were relevant to Evernote's business. Walking out I didn't feel like I did the best I should have, (I have high standards) but I felt the problems were incredibly fair. Now that I am at Evernote, hands down where interviews go badly are in the debugging section. The peer presentation shows people who have not thought about the "why" behind their coding / design decisions - and it separates the juniors from the seniors. Lastly, we expect and can demand a far higher interview performance because we tell candidates how to prepare. If they don't prepare, it shows soooo painfully. For candidates that do prepare we can have a more interesting and engaging interview that allows us to sell Evernote as a company.
- mbrodersen 10y agoI have interviewed and hired software developers for many years at different companies in different countries. Which has given me the opportunity to experiment with different questions and correlate that with outcomes (how good the people I hired or recommended for hiring turned out over the next 5 years). And I have now narrowed the questions down to 4 types of questions that really filter the good developers from the not so good: (1) Ask the candidate to dive into all major groups of software development (DB/UI/Testing/OS/...) and see how deep the candidate can go (2) Ask the candidate to come up with a practical solution to a NP complete real problem (usually an optimization problem) (3) Ask the candidate how he/she would approach investigating and solving a specific real problem for a large real system (usually a mobile-server-DB system) and (4) how they would architect a system given a list of real use cases. Candidates that do a good job of answering those questions are highly likely (as in 95%) to be successful if hired. They don't have to come up with a perfect solution. What is important is how they approach the problems and what kind of possible solutions/investigations they come up with and their reasoning behind it.
- paulie_a 10y agoI have been through a few recent interviews and the technical questions seemed like they were from a college exam. My advice is to see how they operate... Give them a problem, even a vague one, but then solve it together, have them use google to seek out ideas. See how the person approaches it, don't expect a bunch of memorized answers off the top of their head. The big thing is to see what questions they ask. How will you and the person collaborate in a normal working environment. The personality and adaptability are far more important than memorizing the exact command line or function call.
- sulam 10y agoOne of my favorite: You have written some code you'd like people to be able to reuse. Should you share it as a library or expose it as a service? Talk me through how you'd make this decision for a few cases and what the pros and cons are for each choice.
- joeld42 10y agoI ask them to design a structure for a card games that uses a standard deck of playing cards, and how they would implement shuffle (not the algorithm itself) and dealing and hands. This is simple. People manage to grossly over engineer it. My ideal response would be one struct with nothing but a suit enum and int value. A deck is just an array of these, as is a hand. But usually people start with a deck class, then try to reuse that for the hand, discard pile, etc. Things get complicated quickly, just like in real world problems, and a good architect can keep that in check while still providing useful abstractions.
- nunez 10y agoAsk them about a project they did. Let them talk. Ask questions about minor details that seem interesting and (hopefully) relevant to the position you're trying to fill especially when part of their explanation is hand-wavy ("yeah, we used Kerberos because that seemed like the right thing to do." "Why?" "I tried other things. They didn't work." "Why?" etc.) Ask a bit of trivia about the stack you're hiring for. They don't need to know the right answer, but their reasoning about it should corroborate with their experience.