Hey all, I'm a developer at [Big Tech Company] that graduated from university a few years ago, and I've recently just signed up to be a technical i...
For further actions, you may consider blocking this person and/or reporting abuse
Stolen from some Amazon interviews, I love the question :
I love this question because actually a LOT of things happen and giving a complete precise answer is impossible. As a consequence it's a good question to test the ability of giving an honest synthetic answer, to ask more questions to complete some technical points and see how far goes the web/internet/computer knowledge of the candidate, to see on which topics he focus the most on, etc.
It's an excellent technical icebreaker in my opinion.
And I also love that it's not a weird question on a stupid problem but about a very typical thing we do everyday...
I second this. It's fun knowing where the interests and existing skills are. Do they talk about software, hardware, networking? Do they talk about CDNs and performance? Do they talk about the web servers and databases? Do they know how the browser makes the request, or what a request actually is? Do they mention load balancers, routing or DNS? Etc etc. And it's usually a fun conversation that could go on forever.
Or about how the browser interpret the answer? How and when are loaded css and js? Where is stored the information during the whole process? What about some eventual caching?
it never ends and most of the time even being the interviewer I discover new aspects of the question... :D
I really like this question. I feel like the answer could say a lot about who a candidate is, what they're interested in, and what their areas of expertise are.
One that I got a long time ago was design an algorithm to sort a list of words by anagram - so the words 'cat' and 'act' would appear together.
When I got the generic 'sort list of words' question previously, I said I would send to the language's 'sort' command - any developer of mine that thought they were smarter than a tried-and-true honed api wouldn't be hired, or would be a risk of being fired if I found it in a code review. My rationalization allowed it to be a correct answer.
To be honest I hate most whiteboard questions. At my current job I have thought about what type of questions I would want to ask (even though that is not my responsibility), and the two that seem to be overlooked everywhere is code maintainability and testing.
So something like: given you are building a web api with 50 routes across 10 storage objects (tables or what not) how would you go about organizing the code, services, etc.
Also given this function or class show me how you would test it to verify it works correctly.
That's my two cents at least.
Yeah, I'm pretty ambivalent about whiteboard interviews myself, since I don't think they accurately express the kinds of skills that most developers need. Data structures & algorithms do come up from time to time on the job, but not as frequently as software engineering skills.
At the same time, at least when I was in university, everyone was preparing for this style of whiteboard interview, so at the very least it'll be what the people I'm interviewing are expecting. The company policy isn't really mine to change :P
That is fair. After looking at 11 year old spaghetti php your perspective of what is important as a developer changes from algorithms to maintaining and writing easy to understand and modify code. Though we did get a petabyte data file in recently and parsing and processing that was one spot where complexity actually has an impact.
I think this would pretty rough for most computer science undergrads to answer. It requires quite a bit of experience to correctly answer. The second question I like though, probably more important than implementing a binary search tree.
I've always thought a fun one would be to ask a candidate to spend a a few hours learning to solve a Rubik's cube and then come back to me and explain how you solve it. It tests research ability, problem solving, how well you can keep track of the state of the cube, communication skills, how you handle stress under pressure of time etc. There would need to be other questions to see if they have the technical knowledge for the job, but I feel like this gives you a more abstract idea of the candidate's raw abilities.
I'll start with my personal favorite question I've ever been asked:
I like that there are a multitude of ways that you can accomplish this.
The solution that I eventually settled on in the interview was a random walk on a 2-D grid which would first try to join the start and end points, and back up a fixed distance if it ever determined that it had walked itself into a corner. Afterwards, it would attempt to fill in the rest of the grid with branching paths by backing up the walked path and following a similar random walk until it had nowhere left to go, at which point it would return to the main path and continue filling in more blank portions of the grid.
I'm not sure if it generates the most interesting mazes, since I'm relatively certain that the correct path would be rather visible, as it probably ends up drawing a relatively straight line between the start and end points. Maybe I should try to code this up some time and see how it looks 😂
My favorite question from a hiring manager: "When can you start working here?"
But, when I'm the interviewer I like to ask open ended questions that relate closely to the work that's going to be expected and how the applicant's experience fits into that. I avoid asking generic brain teaser type questions or language/framework trivia questions. I assume that the person I'm interviewing doesn't know everything and, like me, there will be gaps in their knowledge. No silly "gotcha" questions.
I may also ask about their most recent project, what was the most interesting part, what was the most challenging part, what worked the best and the worst. I may ask them to diagram it out on a whiteboard just to see how well they can explain something they've worked on. That will be important for demoing at the end of sprints and epics.
I also like to ask why they are here, why they chose to apply at this particular company. I want to see if they are in "a job, any job" mode or if there was something in particular they thought was interesting about the company.
No single whiteboard question has ever been relevant for my actual work.
What's your favorite thing about writing code? Or, what's your favorite programming language? I want to see people be excited and passionate about what they're doing.
I like to start small and take it up a notch progressively.
The first question I usually ask is to swap two variables without using a third.