Job Interview Tomorrow - 2hr Assessment

[Hamster]

Can be anything.

Most assessments I've done have been tests to write code on a PC. Short silly questions like "prove this is a palindrome" followed by a "bigger" program you have to write.

Only once did I get an assessment that was more googlish with riddles and a white board. I'm not gonna lie, it was the second most fun I interview ever had (but when I was done I felt I had wasted my time and I didn't take them too seriously)

 

[Edwe]

/SNIP

Sounds like this would be a pretty cool interview. Wouldn't have been able to answer any CUDA-specific questions (before I read up on it this morning), but the ASIC/FPGA discussion would have lasted pretty much until someone explicitly asked me to shut up.

In terms of (3)... I'm not sure there is really much I could do to optimise manually, even if my code doesn't have to be portable, unless I have some additional info about the data I'm going to get (if limited data range, LUTs could be used to trade memory for performance). Most modern compilers will, however, translate a naive C for-loop into appropriate SSE instructions automagically http://gcc.gnu.org/projects/tree-ssa/vectorization.html as well as any decent programmer could. Otherwise you could use Intel IPP; I'm pretty sure they know way more about their own CPUs than anyone you get for an interview ever will.

 

[cguy]

Sounds like this would be a pretty cool interview. Wouldn't have been able to answer any CUDA-specific questions (before I read up on it this morning), but the ASIC/FPGA discussion would have lasted pretty much until someone explicitly asked me to shut up.

In terms of (3)... I'm not sure there is really much I could do to optimise manually, even if my code doesn't have to be portable, unless I have some additional info about the data I'm going to get (if limited data range, LUTs could be used to trade memory for performance). Most modern compilers will, however, translate a naive C for-loop into appropriate SSE instructions automagically http://gcc.gnu.org/projects/tree-ssa/vectorization.html as well as any decent programmer could. Otherwise you could use Intel IPP; I'm pretty sure they know way more about their own CPUs than anyone you get for an interview ever will.

Most compilers won't vectorize that loop since you can't vectorize it effectively without altering the the output (due to FP non-associativity). There are aggressive compilation options that may get the compiler to do it, but then you've generally got to be careful to get it enabled very selectively, since non-associative math isn't really a variable one wants running rampant through one's numerical code.

The IPP library (and others of its kind) generally involves a function call, as well as a branchy preamble determining which version of the dot product code to run based on size (and/or CPU), which means that for sizes of ~2048 (which would take about ~128 clocks to run), this overhead can greatly reduce your efficiency. The vectorization discussion also gets quite interesting because there have been a lot of new instructions add to x86 recently (i.e., wouldn't just use SSE, and not just vectorized mul's and add's either), and there are still instruction pipeline level issues to consider in order to get to ~128 clocks.

Good point on knowing the contests of the data though, precision is definitely an issue with hardware, although knowing that on or both of the vectors are sparse for example, could allow you to do some additional optimizations.

 

[Sonic2k]

A good question for interview would be Amdahl's law

 

[animal531]

I tend to ask open questions like: How would you compute the dot product between two vectors of size 2048 as quickly as possible?

Language, hardware, etc. is all left open. This explores a lot of avenues, and lets the candidate tell me what's in their repertoire, rather than me having to ask many superficial questions.

Interviews are difficult, but remember that any test that's given to you also tells you a lot about the company, work environment and people. You're only there to prove yourself to them inasmuch as they're trying to prove themselves to you (so don't sweat it too much).

For example I go in for a C# interview, they give me a SQL test. I complete it and then asked the recruiter about it, turns out they gave me the wrong thing and I have to go back for the code test.
This company is most likely a meat factory, not only did they not bother administering the correct test, but they couldn't even be bothered to waste a human's time on you. Don't bother going back. The best places I've worked at (with the most interesting software) have often been at the ones with the least technical and difficult interviews.

Some arbitrary problems with computer testing:
1. I've maybe worked on desktops my whole life, if you give me a laptop my dev speed will drop by 50%
2. I use a generic dev env such as Visual Studio, but I highly customise it. I haven't pressed the build button in 15 years which means that I lose another high % of speed digging around for buttons and functionality
3. 15-10 years ago all development pretty much happened offline, but since then it's vastly changed. Then if you had a problem you sat in your environment playing with it, checking specs and whatever docs were available; or asking co-workers. In contrast, now when I'm faced with a problem, design challenge or a random issue/bug it's my skill at correctly naming the problem, googling it and being able to follow the correct links and being able to implement it (although of course not all problems are google-able)
4. When they ask in an offline test "what's wrong with this program?", you reply "Click build and see what the compiler says". I'm a developer, not a compiler


This brings us to the biggest problem with tests and interviews. They fail when they test the knowledge of the interviewer; instead of the history, capabilities and potential of the interviewee.

Let's take cguy's vector question as an example (note that I'm not saying at all that it's a bad question, it's all about how it's introduced, the follow up questions and why he's asking what he's asking).

Does cguy need to know if the interviewee knows anything about vectors, dot-products, or how a size of 2048 is mixed into it, or was it a general question trying to fish out different bits of interviewee knowledge on computer working/architecture (because that's what cguy and his company is into)?

If I have difficulty in answering any of the 3 parts and cguy just sits there then he's failed as an interviewer. If he's interested in my math skills then he can for example expand on the vectors part, graphics programming the dot product and low level on the 2048 part. Give me a hint, figure out why/if there was a gap in our communication or if I simply don't have any knowledge in that area. If you've spoken to me and it turns out that my entire working history is on relational DB's and that for fun I'm playing with NoSQL variants at home, then focus on that rather than asking me math/graphics/compiler questions. Focus on finding my strengths, not my weaknesses.


Back to cguy's question: For myself, I've been doing graphics programming my whole life, although I'm not very mathematical. I've computed a lot of vector dot products and can answer on why you'd do so, but I'd have struggled with the 2048 (even though I've done assembly/gpu programming, albeit not recently). I'd have specifically asked what do you mean with the 2048 (since as a graphics programmer I first associate vectors in my head as a set of floats), so the question would appear to be nonsensical. If you'd explained that you're asking in terms of compilers, then I'd go with ahh yes, SSE etc...

Often it's the follow-up questions, comments and dialog that makes the interview.

 

[dadecoza]

How did the interview go?

 

[cguy]

...

My interviews tend to be very interactive - I don't sit back and expect the candidate to draw knowledge from thin air. I do also generally need to test the candidate's maths skills. If they don't know what a dot product is, I won't ask them another maths question (this is a litmus test), and will sketch out the naive implementation on the board quickly and proceed. If they do know it, I will follow up with more advanced mathematical questions afterwards. If they can't come up with anything beyond the simple implementation (or at least make a comment about optimal complexity if they are theoreticians), I will likely end the interview there.

If I'm ever interviewing an SQL or NoSQL expert, HR has screwed something up.

I'm not sure what you think the 2048 meant, but it's just a dot product in a 2048 dimensional vector space. Each vector is just an array of 2048 floats, where in graphics you usually deal with 2, 3 and 4 dimensional vectors. It's the same math. BTW, if you did mention that you have graphics programming experience, I would ask you questions on fast Ray-triangle intersection, shadow algorithms and GPU architecture.

 

[braBenj]

Hope the interview went well!

 

[animal531]

My interviews tend to be very interactive - I don't sit back and expect the candidate to draw knowledge from thin air. I do also generally need to test the candidate's maths skills. If they don't know what a dot product is, I won't ask them another maths question (this is a litmus test), and will sketch out the naive implementation on the board quickly and proceed. If they do know it, I will follow up with more advanced mathematical questions afterwards. If they can't come up with anything beyond the simple implementation (or at least make a comment about optimal complexity if they are theoreticians), I will likely end the interview there.

If I'm ever interviewing an SQL or NoSQL expert, HR has screwed something up.

I'm not sure what you think the 2048 meant, but it's just a dot product in a 2048 dimensional vector space. Each vector is just an array of 2048 floats, where in graphics you usually deal with 2, 3 and 4 dimensional vectors. It's the same math. BTW, if you did mention that you have graphics programming experience, I would ask you questions on fast Ray-triangle intersection, shadow algorithms and GPU architecture.

Hehe yeah, as long as you keep it interactive and focus on finding the candidate's strengths then you're doing a good job.

 

[CamiKaze]

So how did it go?