5 ms·

> Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? "Please arrange these colors in complementa

> Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? "Please arrange these colors in complementary, analogous, and triadic color schemes". This is color theory 101 -- something every visual designer should now. > Why is red font on blue background bad, please justify? Again, a valid question. It all depends on the brightness/saturation of the colors, and how much contrast is between them. Edit: Obviously these are ridiculous and unnecessary interview questions because frequently a designer provides a portfolio of work that demonstrates their skill. This may not be possible in a programming interview if the candidate has been not been working on open source code or side projects.

cableshaft 11y ago
I have a portfolio of past work (I made games that are still available, I even bring an iPad with them playable on them). I still get asked a ton of technical questions, and I'm lucky if I can even show them my past projects, because they never trust that I was the actual programmer on these projects (even though in the credits for a couple of them it says 'Lead Programmer: [cableshaft]'). It's a totally broken perception, and it needs to end. We're one of the few professions that are routinely asked to prove our abilities in every single interview we attend. It wastes so much time on both ends and there needs to be a new way.
- yoklov 11y ago
  Why wouldn't they trust you? Sounds bizarre. Especially if you're listed in the credits.
  - cableshaft 11y ago
    Well really, they don't even usually let me get to the point with showing my work where I can show my name in the credits. My point is they could have checked that ahead of time and seen my name in the credits if they wanted to verify that I actually did what I said I did in my resume, and they don't. The handful of people I've had to interview I always checked the interviewees portfolio ahead of time if it was available.
ommunist 11y ago
Perceived contrast depends on media. The only question designer answers in real life - is he ready to subdue his taste and skill to PMs whim or not.
bayonetz 11y ago
Many (most?) times you provide samples for a software engineer job, they don't get looked at or serve to provide much help to your cause. That you have samples seems to help get an interview but after that it's at if the samples were never even provided. I link to many samples right from my resume so interviewers don't have to depend on HR or whoever passing on extra files. I've often asked the interviewers, "just curious, what did you think of my samples?" Almost without exception they say sheepishly say something like "sorry, didn't have time..." Which is probably true but geez you'd think a portfolio would matter more and merit a required look. On a related note, I love the story about the Homebrew guy getting rejected by Apple because he couldn't invert a tree or some such thing. Even if it was sensationalized (or plain false for that matter), we aren't even surprised by headlines like that anymore given the current interview climate.
- illicium 11y ago
  When interviewing, I'm interested in seeing the process a candidate takes to get a result, not just the result. I like looking at code samples to get a feel for code quality and software engineering practices (everything from variable naming and program structure to Git commit messages) Real-time coding during the interview shows me how good a candidate is at collaborating when solving a problem. One good indicator is asking follow-up questions to make sure requirements are clear. Other things to look for are, e.g. TDD, which can help solve a problem with predictable correctness and pace. I have interviewed quite a few candidates who throw a bunch of code into the editor and start pseudo-randomly tweaking the code to try to make it work -- this is not a recipe for successful problem solving. Some aspects of code quality can be evaluated during the interview as well, which probably explains why many interviewers don't bother looking at code samples. It's important to ask for a solution that can be easily deduced -- trick questions are bad for both parties, because the candidate is often stumped, and the interviewer thinks they are bad because knowing the trick makes the question simple. Many classical algorithmic questions are "tricky" in this way. The questions also have to be "real world". Like you mentioned, you can be a successful engineer and not know the specifics of inverting a tree. If you can correctly recognize the need for the algorithm and implement it from pseudocode, you have solved your problem, which is what engineers are paid to do.

cableshaft 11y ago

I have a portfolio of past work (I made games that are still available, I even bring an iPad with them playable on them). I still get asked a ton of technical questions, and I'm lucky if I can even show them my past projects, because they never trust that I was the actual programmer on these projects (even though in the credits for a couple of them it says 'Lead Programmer: [cableshaft]'). It's a totally broken perception, and it needs to end. We're one of the few professions that are routinely asked to prove our abilities in every single interview we attend. It wastes so much time on both ends and there needs to be a new way.

yoklov 11y ago
Why wouldn't they trust you? Sounds bizarre. Especially if you're listed in the credits.
- cableshaft 11y ago
  Well really, they don't even usually let me get to the point with showing my work where I can show my name in the credits. My point is they could have checked that ahead of time and seen my name in the credits if they wanted to verify that I actually did what I said I did in my resume, and they don't. The handful of people I've had to interview I always checked the interviewees portfolio ahead of time if it was available.

ommunist 11y ago

Perceived contrast depends on media. The only question designer answers in real life - is he ready to subdue his taste and skill to PMs whim or not.

bayonetz 11y ago

Many (most?) times you provide samples for a software engineer job, they don't get looked at or serve to provide much help to your cause. That you have samples seems to help get an interview but after that it's at if the samples were never even provided. I link to many samples right from my resume so interviewers don't have to depend on HR or whoever passing on extra files. I've often asked the interviewers, "just curious, what did you think of my samples?" Almost without exception they say sheepishly say something like "sorry, didn't have time..." Which is probably true but geez you'd think a portfolio would matter more and merit a required look. On a related note, I love the story about the Homebrew guy getting rejected by Apple because he couldn't invert a tree or some such thing. Even if it was sensationalized (or plain false for that matter), we aren't even surprised by headlines like that anymore given the current interview climate.

illicium 11y ago
When interviewing, I'm interested in seeing the process a candidate takes to get a result, not just the result. I like looking at code samples to get a feel for code quality and software engineering practices (everything from variable naming and program structure to Git commit messages) Real-time coding during the interview shows me how good a candidate is at collaborating when solving a problem. One good indicator is asking follow-up questions to make sure requirements are clear. Other things to look for are, e.g. TDD, which can help solve a problem with predictable correctness and pace. I have interviewed quite a few candidates who throw a bunch of code into the editor and start pseudo-randomly tweaking the code to try to make it work -- this is not a recipe for successful problem solving. Some aspects of code quality can be evaluated during the interview as well, which probably explains why many interviewers don't bother looking at code samples. It's important to ask for a solution that can be easily deduced -- trick questions are bad for both parties, because the candidate is often stumped, and the interviewer thinks they are bad because knowing the trick makes the question simple. Many classical algorithmic questions are "tricky" in this way. The questions also have to be "real world". Like you mentioned, you can be a successful engineer and not know the specifics of inverting a tree. If you can correctly recognize the need for the algorithm and implement it from pseudocode, you have solved your problem, which is what engineers are paid to do.