I know the questions are more practical based but can anyone who interviewed recently or works at Square comment on the best way to prepare. Got my onsite in a few days and I'm struggling with what types of problems I should use to prep. Outside of the normal LC prep is there anything else I should be ready for in regards to the coding?
Is it progression of an LC question in phone screen?
My question was not LC but it has similar concepts obviously and yes it is iterative. I got through 3 of 4 steps.
Speaking here as a SQ EM who interviews a lot... In general every interviewer at SQ has their own question. (I think there's some dabbling with shared questions cause we have so many interviewers now, but not for most) This does mean the quality of questions can vary, but, our guidelines are basically: - Make it multi layered, so you can learn useful info from someone at any level. When doing our feedback, we're explicitly asked to describe how much progress someone of the candidate's level should make, and how much this candidate made. But basically everyone has multi part questions, and it's not necessarily a no-hire if you only finish part 1. - It shouldn't be a "eureka!" sort of puzzle question. And it shouldn't require you to know how to implement some specific algorithm by heart. We're not trying to learn what specific things you know, we're trying to understand your engineering instincts and general coding skills. - It should have multiple possible approaches to get a working solution, not just one "right" way. Almost all of the questions I've seen, including mine, would require you to understand basic data structures like arrays, maps, sets, trees, graphs, and to understand when/where to use them to model a problem. It's not "do you know how to sort an array" ... It's "do you know when a sorted array will be useful to solve a problem?" Here's how to do well on a SQ question, though in my experience it's true for all interviews as well as just good coding... - Break the problem into sub-problems. Work backwards from the output you need to produce. What intermediate state do you need to produce that output? What transformations can you perform to get to that intermediate state? - Work collaboratively with the interviewer. Bounce ideas off them, discuss different possible approaches. Someone who is able to verbally, abstractly discuss multiple competing approaches to the problem will get better scores than someone who silently jumps straight to the "correct" solution. - Test early and often. Write your code so the sub-solutions to the sub-problems can be tested independently. I'd rather see a well tested solution that gets 75% of the way to the answer than a working solution that only gets tests added in the last couple minutes. I cannot stress that last part enough: there is no such thing as an automatic no-hire, and depending on the candidate and the interview I could give a hire, even a strong hire, to a candidate who did not fully complete part 1 of my pairing question. That would be if I see strong engineering instincts, good systematic problem solving, good testable and maintainable structure.
Thank you Square! By far one the best interview practices I've faced in my career. Google and FB should take notes and use a similar process. It gives way better signal than if a candidate memorized a similar question and able to regurgitate code
Here's a LC I could imagine being a SQ question: https://leetcode.com/problems/valid-sudoku/description/ This would be part 1. What would look like a good solution to me? You already have a list of the rows. I'd love two functions to give you a list of the columns and a list of the squares, respectively. Then a method to check a list of lists for dupes. Then a function that checks dupes on the input and the two transformations of the input. I'd want tests on the sub-methods. Then, I suspect there'd be a part 2. Probably... "Given a row/column index, write a method to return all the valid numbers that could be put in that box." Easy solution for part 2 is, create 9 copies of the input with that space filled with each digit 1-9 and use the method from part 1 to check which ones are valid. More involved but efficient solution is to do the three transforms, pull the row, column, and square, and use a set to track what digits aren't in any of them. This would require a sub-method to get the index in the list of squares based on the row/col index. I could even imagine a part 3: write a Sudoku solver using the results of part 1 and 2, but I doubt you could get to that in 55 minutes.
That's very similar to how my screening question went. Having a good example like that makes it much easier to visualize what to expect though going in. Thanks.
Hey bixbite, I’m pursuing a role at Square. Would you mind if I DM you for a referral?
A somewhat different vision from another Square EM: Agree with the write-up of the kind of questions we ask. However, different people look for different things - we have a lengthy rubric we use and assume people just gravitate to focusing on different parts. For example, I don't really look for testing at all, and it's kind of an afterthought in my question ("if you were going to write tests, what would you be looking for?"), though I do use that to see how you think about edge cases. Mostly what I look for is: - Can you break down a question? Can you figure out what kinds of algorithms you'll need to solve this, and can you figure out the appropriate data structures to use in your algorithm? Many candidates pick a data structure first based on what seems intuitive and then have to write overly complex code to make it work. - Is your code readable and maintainable? Do your variable names help me understand what you're doing with them? Would I want this in my codebase? Obviously with some adjustments for it being an interview. - Related to those issues above, my question involves maintaining a lot of state - can you do that correctly, or failing that, can your code be pulled apart enough that it can be debugged when you do get something wrong?
Hi AzID47 Good response. Sorry for reviving the thread again. I am Wondering if its mandatory to have a working solution in the end like code that should compile and run right away and product a result? Its natural to take longer on big problems and sometimes for me its hard to write test-cases while devising solution and focus completely on actual problem. I will appreciate your input.
It really depends on the interviewer. We understand that if the question doesn't break down into convenient parts it may be hard to finish... but the idea is that because the questions we ask are usually broken into smaller parts, you should be able to reach certain checkpoints even if you don't finish the whole problem. In general I'd say that if you're showing valuable other skills that are making it take longer - if you have a better design or whatever - that's fine, but we're supposed to be able to tell the difference between that and someone who's just moving slowly.
Could someone share interviewing questions for s/w engineering manger role @ Square
They actually have some of the best questions I've faced. It's pair programming. Progression based. Meaning you start simple and build on top of it layer by layer
Ya my phone screen was like that and I enjoyed it and did pretty well. I feel good about being able to solve them but Im just unsure how to even prep outside of just continuing to bang through LC mediums the next couple days lol.
Do you have a sample of what type you were asked?