Literally no company wants you to make actual production code on a whiteboard.
Hiring Without Whiteboards
201–210 of 471 posts
Re: Hiring Without Whiteboards
#202The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others. Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews. Pair progr…
In the past we had some candidates complain about take-home problems. The primary complaint was that candidates weren't interested in dedicating 4-5 hours of their own time unless they felt that someone from the company was putting in an equal amount of their own time. Some candidates also had suspicions that we were trying to use them for free labor (Not true, we used the same toy problem for every candidate). One c…
Re: Hiring Without Whiteboards
#203We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
That’s not to say I don’t think this process has promise, but I’d need to be convinced that the above two issues can be fairly dealt with first.
Re: Hiring Without Whiteboards
#204We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
I recently had a humiliating experience. Just was approached on LinkedIn and at first they sent me a take home. I learned the front-end tech which was required for it, and then coded it. They just wanted me to fill out a doc but I put it all up on stackblitz. Another portion was back-end which I also put up on another online env so they could see not only the code but how everything was laid out.
Get to the over the screen share interview - just nervous and both the interviewers were impatient, and just the atmosphere was so nerve-wracking - they did nothing to make it more relaxed. Just seemed like the senior guy was stressed out and I was wasting his time. My brain kind of shut off and the seemingly simple problem at that time just seemed insurmountable because I felt myself second guessing my every thought.
Been developing for a number of years for a few companies, and I guess I haven't prepped for the tech interview - I thought my existing skills are what they need and should be enough to evaluate but boy was I wrong.
Needless to say they didn't go with me. It's not like I needed the job, or probably wouldn't have taken it anyway since what their maximum range was lower than what I make, but the startup seemed quite interesting. Just such a bad experience.
Re: Hiring Without Whiteboards
#205Here we go again perpetuating the stereotype of the whiney privileged engineer put in a position of mild discomfort by the villainous abusive white board interview boogeyman. I don’t mind whiteboard interview exercises. They’re not great, but they often give a very good and reasonable signal that often has a high corollary to work performance. I think there’s bigger fish to fry in refining fair and objective intervie…
if properly trained, interviewers ask questions that build without throwing the kitchen sink at you.
whiteboard interviews (when done holistically) assess for signal, not binary correctness
- do you have a solid framework to build a solution?
- are you considering multiple approaches / data structures / complexities
- referencing similar problems, vocabulary, situations to illustrate breadth of knowledge
sure, the stress component isn't ideal, but there are multiple relevant capabilities being assessed in a very short amount of time...
in other words it's a much better test of tacit knowledge than alternatives
Re: Hiring Without Whiteboards
#206We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
How do you avoid awarding candidates who violate your request of no more than two hours and spend considerable time coming up with something amazing? They may still produce 100 lines of code — but those 100 lines may end up being unusually elegant, beautiful code that stumps 40 year veterans. How do you avoid punishing someone who took your requested time constraint seriously (or otherwise didn’t have enough free tim…
Re: Hiring Without Whiteboards
#207Re: Hiring Without Whiteboards
#208To a large degree, these look like no-name companies who probably have to resort to this kind of thing to make up for worse pay and benefits as compared to FAANG.
In other words the companies that 99% of the world's developers work for. What they are "resorting" to is a hiring process that finds good developers at a reasonable cost. "We can't pay you what FAANG pays but we don't put you through a shitty and lengthy interview hazing" is a pretty good proposition to the vast majority of us.
If you want some one who can build web sites using React JS you are better off hiring people who know and have built things using React JS. There is little logic in hiring people who can do some obscure fashion-of-the-week algorithms, assuming if they can do this they can learn React is just plain wrong. A person does what they are good at doing, if some one is good at interviewing their incentives are in changing jobs often to find the next company that can offer a raise. Not getting your work done.
Also this whole thing that one must know these algorithms because they might once in a life time face a need for Dijkstra's sometime during midnight at a place where they wouldn't find an internet connection, is unrealistic. C'mon. Get real. Companies are full of situations where people are digging with shovels and spoons, because people don't have the skills to use and build tools and system to save thousands of man hours of manual effort. Code bases are full of tech debt. Deployment problems because tests aren't written, or there is just no CI infrastructure. Lack of skills and productivity is a far more realistic and commonly occurring problem than these once in a decade algorithm needs. On top of this comes the need for proactive problem identification and solving(a.k.a innovation).
The fact that FAANGs have to acquihire or acquire companies to grow shows they are not hiring the right people either.
As of today if you are hiring for devs. You must look for turn-key projects executed, expertise in one main programming language/stack, ability to script quickly, skills to build tooling/monitoring, ability to produce deployable code, code maintenance, writing test cases etc etc.
Re: Hiring Without Whiteboards
#209We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
Re: Hiring Without Whiteboards
#210Oh God, here we go again. Coding on a whiteboard in an interview is not "broken". What is "broken" however is making the problem the candidate needs to solve "hard". I can't stress this enough: a whiteboard coding test is nothing more than a negative filter . It's to filter out people who can't turn a simple idea into code as these people exist. This is why FizzBuzz was such a simple problem. But interviewers fall in…
Yeah, I tanked the interview but I really did not care if I pass when I got to that point.