4 ms·

1. I would whiteboard you and vet your previous clients/projects. This also assumes I have time. Make sure you're good on from a project pov and an algorithms

1. I would whiteboard you and vet your previous clients/projects. This also assumes I have time. Make sure you're good on from a project pov and an algorithms pov. I've seen bad code from people who have made decent looking projects. When I looked deeper I just saw copy pastes from stackoverflow. 2. This makes it harder - just learn react, new ES stuff and webpack if you want to focus on front end, it doesn't take long, just run yourself through some tutorials and build a small project to familiarize yourself. Some people will ask you trivia. 3. You're being unrealistic. I suggest you ask for referrals.

smt88 7y ago
> I would whiteboard you > you're good on from a project pov and an algorithms pov As someone who also hires software people, I would urge you to review the evidence on whiteboarding. It's difficult to discard your own anecdotal evidence, but hiring has no control group -- you have no idea how many great people you're missing as a result of whiteboarding. The reasons against whiteboarding have been discussed here many times, but I'll summarize them again: - They're unnatural. People haven't practiced writing code standing up, with markers, with other people around, in real-time with minimal thought/planning, or with a potentially life-changing job on the line, and they don't do that after you hire them. - They're biased against people who are introverted, who haven't specifically practiced whiteboarding, and/or who just aren't as cocky. Why are those traits you want to filter out? - Most programming jobs are about learning and critical thinking, not regurgitating algorithms. - They're humiliating for most people. That alone should be enough to end the practice. When people ask me for advice, I tell them to avoid companies whose first interaction with you is humiliating. - Experienced candidates can (and should) refuse to do whiteboard interviews, which means your company is missing out. I hope that's at least food for thought!
- pikamonad 7y ago
  While these items might be true, as an interviewer you are not trying to solve for “find all good candidates” but, instead, are solving for “find one good enough and better than the rest”. Anymore, I love that I have a clear path on how to obtain a very high six figure gig with plenty of resources to get there. I’ll gladly play that game, with enthusiasm. When others focus on the plight of the interviewee, others are leetcoding, white-boarding, practicing, reading up on blind, etc.
  - xwolfi 7y ago
    Depends, I don't think you care all that much about coding skills. You don't want a cripple, but you want a diva even less. You can take a learning developer with an amazing passion for learning, and building shit while you must refuse a guy who say he's leet coding and shit on everyone trying to learn from him :D Depends what industry you work in, but where I am, it's more about accepting to switch team and language during hiring freeze, spend a week or two on legacy retro spec'ing, tell business users that you failed your impossible deadline, and fix your own crap honestly. Nothing leet about it, just brutal honesty, courage and loyalty to get a six figure where I am.
  - smt88 7y ago
    > leetcoding, white-boarding, practicing, reading up on blind, etc. These things have no relationship with whether someone is productive, constructive to the team, or good at coding.
- drenvuk 7y ago
  My whiteboarding consists of a mix of three things: 1. Invert a binary tree (tree based and simplistic) 2. Open a file, parse it in a simple way and then write to a new file. (file systems, strings) 3. Design a barebones twitter/reddit, etc. (architecture) No dynamic programming, no esoteric stuff. Just can they understand tree structures, do they have a grasp on file systems, and do they have a modicum of design sense. It doesn't need to be hard. After that the rest of proving themselves happens on the job. This isn't for humiliation, I just want to filter out the people who I would waste time on with further vetting and training. If the candidate cares they should be able to meet my appropriately low bar.
  - smt88 7y ago
    It doesn't matter how easy the task is. People are nervous about being in a job interview. Also, who inverts binary trees on the job? I've had good success with (like you) asking to be walked through some architecture. I also ask them to review a one-page program and then code-review two commits to it. Finally, I give them a take-home (paid) assignment. It's as close to testing how they really work as I can get without contract-to-hire (which I also support).
  - sethammons 7y ago
    1: have you _ever_ had to invert a binary tree outside your interview? And if you have, not that many others have. 2: surprisingly, not all programming jobs require opening a file (I used to run a question that required opening and writing a new file and got rid of it). 3: I love whiteboards for design questions. My suggestion for a technical interview (coding portion): take a real life problem you solved in the last year or so. Distill it down into something you could do in 15 minutes. Give the candidate 45 minutes to do it on a computer (preferably their own). For other important things you need them to know before they start (like if trees and file systems are important), just talk about them and ask questions. You can drill down as far as needed there and learn more than if they know the file api in the given language. I recently hired a guy who was green, and did not know how to open and read a file or do unit tests (really green). But given a laptop and a few minutes to read docs, he knocked it out. He has been a fantastic hire working on high scale, high available systems. I don't think he would have done well if the questions were on a whiteboard. Just my $0.02.
winrid 7y ago
Unrealistic? Half the people at my current company do this.

smt88 7y ago

> I would whiteboard you > you're good on from a project pov and an algorithms pov As someone who also hires software people, I would urge you to review the evidence on whiteboarding. It's difficult to discard your own anecdotal evidence, but hiring has no control group -- you have no idea how many great people you're missing as a result of whiteboarding. The reasons against whiteboarding have been discussed here many times, but I'll summarize them again: - They're unnatural. People haven't practiced writing code standing up, with markers, with other people around, in real-time with minimal thought/planning, or with a potentially life-changing job on the line, and they don't do that after you hire them. - They're biased against people who are introverted, who haven't specifically practiced whiteboarding, and/or who just aren't as cocky. Why are those traits you want to filter out? - Most programming jobs are about learning and critical thinking, not regurgitating algorithms. - They're humiliating for most people. That alone should be enough to end the practice. When people ask me for advice, I tell them to avoid companies whose first interaction with you is humiliating. - Experienced candidates can (and should) refuse to do whiteboard interviews, which means your company is missing out. I hope that's at least food for thought!

pikamonad 7y ago
While these items might be true, as an interviewer you are not trying to solve for “find all good candidates” but, instead, are solving for “find one good enough and better than the rest”. Anymore, I love that I have a clear path on how to obtain a very high six figure gig with plenty of resources to get there. I’ll gladly play that game, with enthusiasm. When others focus on the plight of the interviewee, others are leetcoding, white-boarding, practicing, reading up on blind, etc.
- xwolfi 7y ago
  Depends, I don't think you care all that much about coding skills. You don't want a cripple, but you want a diva even less. You can take a learning developer with an amazing passion for learning, and building shit while you must refuse a guy who say he's leet coding and shit on everyone trying to learn from him :D Depends what industry you work in, but where I am, it's more about accepting to switch team and language during hiring freeze, spend a week or two on legacy retro spec'ing, tell business users that you failed your impossible deadline, and fix your own crap honestly. Nothing leet about it, just brutal honesty, courage and loyalty to get a six figure where I am.
- smt88 7y ago
  > leetcoding, white-boarding, practicing, reading up on blind, etc. These things have no relationship with whether someone is productive, constructive to the team, or good at coding.
drenvuk 7y ago
My whiteboarding consists of a mix of three things: 1. Invert a binary tree (tree based and simplistic) 2. Open a file, parse it in a simple way and then write to a new file. (file systems, strings) 3. Design a barebones twitter/reddit, etc. (architecture) No dynamic programming, no esoteric stuff. Just can they understand tree structures, do they have a grasp on file systems, and do they have a modicum of design sense. It doesn't need to be hard. After that the rest of proving themselves happens on the job. This isn't for humiliation, I just want to filter out the people who I would waste time on with further vetting and training. If the candidate cares they should be able to meet my appropriately low bar.
- smt88 7y ago
  It doesn't matter how easy the task is. People are nervous about being in a job interview. Also, who inverts binary trees on the job? I've had good success with (like you) asking to be walked through some architecture. I also ask them to review a one-page program and then code-review two commits to it. Finally, I give them a take-home (paid) assignment. It's as close to testing how they really work as I can get without contract-to-hire (which I also support).
- sethammons 7y ago
  1: have you _ever_ had to invert a binary tree outside your interview? And if you have, not that many others have. 2: surprisingly, not all programming jobs require opening a file (I used to run a question that required opening and writing a new file and got rid of it). 3: I love whiteboards for design questions. My suggestion for a technical interview (coding portion): take a real life problem you solved in the last year or so. Distill it down into something you could do in 15 minutes. Give the candidate 45 minutes to do it on a computer (preferably their own). For other important things you need them to know before they start (like if trees and file systems are important), just talk about them and ask questions. You can drill down as far as needed there and learn more than if they know the file api in the given language. I recently hired a guy who was green, and did not know how to open and read a file or do unit tests (really green). But given a laptop and a few minutes to read docs, he knocked it out. He has been a fantastic hire working on high scale, high available systems. I don't think he would have done well if the questions were on a whiteboard. Just my $0.02.

winrid 7y ago

Unrealistic? Half the people at my current company do this.