Getting an Interview
Getting an Interview
Interviews for Top Jobs at Sucker Punch ProductionsMore
- No OfferNegative ExperienceDifficult Interview
I applied online. The process took 2+ weeks – interviewed at Sucker Punch Productions in December 2014.
Toughest screener I've ever had. Another review notes the question they ask. Apparently they've asked the same question for over 6 years so it must work for them. Without asking any questions about me or a phone call, just got emailed the test. It's initially a bit of a trick question because its not what it appears to be. Where most other companies ask you short questions or short code efficiency with data structure or algorithm-based questions as screeners, they expected a rather large and tedious low-level C program designed from scratch. Even after spending multiple hours on it and trying to get it as efficient as possible, lots of bitmasking and alloc/realloc implementation, and testing, it apparently failed to impress. I admit I did get tangled in the design a bit myself, and may have left edge cases open for error. So I probably got busted if they used a big test harness and just passed on anyone whose program doesn't score well. But I had spent so much time on a ~screener~ (more time than in-person Google interviews) that I knew I had to draw a line somewhere and submit it. Two weeks later I received an email with no feedback informing me they had moved on. Quite a shame I didn't even get a phone call. I went back to the problem to try to redesign it anyway because I was curious. I put enough time into it that I liked to at least have an answer to it, or an idea of one. The ONLY alternative I could get out of any friends or internet boards was a much less efficient answer compared to my solution in terms of memory. So, I'm even more confused on where I may have went wrong. The question specifically stressed memory efficiently, and I pulled out all the stops on bitmasking.
- Queue design with 2048 char array, no heap allocation (malloc,realloc, new, delete not allowed) Answer Question
- No OfferPositive ExperienceDifficult Interview
I applied online. The process took 1 day – interviewed at Sucker Punch Productions (Bellevue, WA) in October 2012.
Interviewed at Sucker Punch last year and had a great experience. I was one of a handful of people that was involved in a 'speed dating' style interview. It was an all day event (lunch included) and we all took turns interviewing with 3 different team members in between watching movies in their theater room. I got great feedback on my portfolio and critiques on my workflow. Although I did not get the job, I feel I walked away with a better understanding of the industry.
- I wasn't expecting technical questions for some reason. i.e. word definitions. I got stumbled up on what Global Illumination was because I was focused on explaining how I get from one step to the next. 1 Answer
Helpful (4)No OfferNegative ExperienceDifficult Interview
I applied through a recruiter. The process took 2 days – interviewed at Sucker Punch Productions (Bellevue, WA) in September 2012.
A Recruiter sent me unsolicited email asking about my interest and asking for me to solve a coding problem. I am not an experienced Playstation/game developer, so I confirmed that the position was open to generalists before we moved ahead. I was given no credible reason for a negative response after I submitted my sample code. And upon further review with my peers, I would expect that the my code is a valid response to get my foot in the door. Very frustrating. I suggest that the next candidate ignore the recruiting email from Sucker Punch.
- Problem Statement The problem is to write a set of functions to manage a variable number of byte queues, each with variable length, in a small, fixed amount of memory. You should provide implementations of the following four functions: // Creates a FIFO byte queue, returning a handle to it. Q * create_queue(); // Destroy an earlier created byte queue. void destroy_queue(Q * q); // Adds a new byte to a queue. void enqueue_byte(Q * q, unsigned char b); // Pops the next byte off the FIFO queue unsigned char dequeue_byte(Q * q); So, the output from the following set of calls: Q * q0 = create_queue(); enqueue_byte(q0, 0); enqueue_byte(q0, 1); Q * q1 = create_queue(); enqueue_byte(q1, 3); enqueue_byte(q0, 2); enqueue_byte(q1, 4); printf("%d", dequeue_byte(q0)); printf("%d\n", dequeue_byte(q0)); enqueue_byte(q0, 5); enqueue_byte(q1, 6); printf("%d", dequeue_byte(q0)); printf("%d\n", dequeue_byte(q0)); destroy_queue(q0); printf("%d", dequeue_byte(q1)); printf("%d", dequeue_byte(q1)); printf("%d\n", dequeue_byte(q1)); destroy_queue(q1); should be: 0 1 2 5 3 4 6 You can define the type Q to be whatever you want. Your code is not allowed to call malloc() or other heap management routines. Instead, all storage (other than local variables in your functions) must be within a provided array: unsigned char data; Memory efficiency is important. On average while your system is running, there will be about 15 queues with an average of 80 or so bytes in each queue. Your functions may be asked to create a larger number of queues with less bytes in each. Your functions may be asked to create a smaller number of queues with more bytes in each. Execution speed is important. Worst-case performance when adding and removing bytes is more important than average-case performance. If you are unable to satisfy a request due to lack of memory, your code should call a provided failure function, which will not return: void on_out_of_memory(); If the caller makes an illegal request, like attempting to dequeue a byte from an empty queue, your code should call a provided failure function, which will not return: void on_illegal_operation(); There may be spikes in the number of queues allocated, or in the size of an individual queue. Your code should not assume a maximum number of bytes in a queue (other than that imposed by the total amount of memory available, of course!) You can assume that no more than 64 queues will be created at once. Answer Question