Hey all! š Iām Ryo, a Sr. Design Technologist at PlayStation. I do web dev with React/TS/Node and game dev with Unity/C#/C++/OpenGL/DirectX. Feel free to ask me any questions! š¤
Only a couple, after a while it feels like you're getting led on -- or that it only takes one person along a complex chain to decide against me. Interviews and first impressions are hard enough, it's another thing to do 4-5 in a row with different people. Unless it's some government gig, there's no reason to screen someone so thoroughly.
Would you have a coding test in the interview? What would that look like?
Code comprehension, reading code and breaking it down. Rather than having them code on the spot, require docs, etc -- let them show you how they break down apps (cause that's what they'll do day one on your app).
Not a fan of writing actual code on the spot, or taking home "homework". I get paid to write apps, so even writing a small menial one is time spent without compensation. I'd rather keep working whatever gig I have, or find someone who'll value my time. Maybe if the "homework" were open source work, I'd feel more inclined, rather than doing code for a private, profit-driven company.
What are some of the maybe less obvious questions you might ask?
This one's hard cause the more random a question I ask, I can say that it's not exactly uncommon to hear it. I'd maybe paint some scenarios and see how the person works it out, like "how would you handle a project if the client didn't provide XYZ assets?".
Would it be a short interview (< 30 minutes) or a longer and more thorough interview?
Keep it short. I don't think anyone's interview skills are that great that I want to spend an hour with them.
Would you meet & greet with the team / show them around the office?
Of course. Helps someone understand the office better, know who to turn to, know where the bathroom is, etc.
Interviews and first impressions are hard enough, it's another thing to do 4-5 in a row with different people.
Yeah I agree. Personally, the most rounds that seem good to me is 2 but I would much rather 1 round simply because time is valuable: theirs and yours.
Code comprehension, reading code and breaking it down. Rather than having them code on the spot, require docs, etc -- let them show you how they break down apps (cause that's what they'll do day one on your app).
Yeah, that is a good point. Rather than testing programming, you're testing understanding and problem solving.
Not a fan of writing actual code on the spot, or taking home "homework". I get paid to write apps, so even writing a small menial one is time spent without compensation. I'd rather keep working whatever gig I have, or find someone who'll value my time. Maybe if the "homework" were open source work, I'd feel more inclined, rather than doing code for a private, profit-driven company.
I agree with not writing code on the spot as an interview environment really isn't going to bring out the best in a programmer.
I am a fan of a take home test though I would never have that be building a piece of functionality for the eventual application they may work on. I agree, that is doing work without compensation. I view the take home test as trying to allow the developer to be in their most comfortable development environment working on some small problems, custom made for testing. I aim for the test to be short (again, time is valuable) and encourage the developer to play to their strengths (especially if they don't/can't complete it all).
What are some of the maybe less obvious questions you might ask?
This one's hard cause the more random a question I ask, I can say that it's not exactly uncommon to hear it.
Yeah, you have all those project/client/colleague situational questions which are variations of each other like handling conflicts etc. I prefer asking a question about something/anything they made. Ideally this is something they have programmed but it really can be anything as I'm trying to tap into their enthusiasm about a subject and want them to get into the nitty gritty. I think it shows a few things like what parts of making they like and how well they can explain technical details.
Would you meet & greet with the team / show them around the office?
Of course. Helps someone understand the office better, know who to turn to, know where the bathroom is, etc.
Would you do that at the interview stage or when they are hired? I see the first (greeting the team) being important early on in the hiring process with the latter (showing around the office) being less important till they are hired.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Would you do multiple rounds of interviews?
Only a couple, after a while it feels like you're getting led on -- or that it only takes one person along a complex chain to decide against me. Interviews and first impressions are hard enough, it's another thing to do 4-5 in a row with different people. Unless it's some government gig, there's no reason to screen someone so thoroughly.
Would you have a coding test in the interview? What would that look like?
Code comprehension, reading code and breaking it down. Rather than having them code on the spot, require docs, etc -- let them show you how they break down apps (cause that's what they'll do day one on your app).
Not a fan of writing actual code on the spot, or taking home "homework". I get paid to write apps, so even writing a small menial one is time spent without compensation. I'd rather keep working whatever gig I have, or find someone who'll value my time. Maybe if the "homework" were open source work, I'd feel more inclined, rather than doing code for a private, profit-driven company.
What are some of the maybe less obvious questions you might ask?
This one's hard cause the more random a question I ask, I can say that it's not exactly uncommon to hear it. I'd maybe paint some scenarios and see how the person works it out, like "how would you handle a project if the client didn't provide XYZ assets?".
Would it be a short interview (< 30 minutes) or a longer and more thorough interview?
Keep it short. I don't think anyone's interview skills are that great that I want to spend an hour with them.
Would you meet & greet with the team / show them around the office?
Of course. Helps someone understand the office better, know who to turn to, know where the bathroom is, etc.
Yeah I agree. Personally, the most rounds that seem good to me is 2 but I would much rather 1 round simply because time is valuable: theirs and yours.
Yeah, that is a good point. Rather than testing programming, you're testing understanding and problem solving.
I agree with not writing code on the spot as an interview environment really isn't going to bring out the best in a programmer.
I am a fan of a take home test though I would never have that be building a piece of functionality for the eventual application they may work on. I agree, that is doing work without compensation. I view the take home test as trying to allow the developer to be in their most comfortable development environment working on some small problems, custom made for testing. I aim for the test to be short (again, time is valuable) and encourage the developer to play to their strengths (especially if they don't/can't complete it all).
Yeah, you have all those project/client/colleague situational questions which are variations of each other like handling conflicts etc. I prefer asking a question about something/anything they made. Ideally this is something they have programmed but it really can be anything as I'm trying to tap into their enthusiasm about a subject and want them to get into the nitty gritty. I think it shows a few things like what parts of making they like and how well they can explain technical details.
Would you do that at the interview stage or when they are hired? I see the first (greeting the team) being important early on in the hiring process with the latter (showing around the office) being less important till they are hired.