191–200 of 370 posts
Earlier quoted context omitted.
Makin' games, burnin' savings. https://www.youtube.com/watch?v=V7MXfg2wt28&list=PLqJcvcLs4C...
Hah! I love the AXBY code-entering minigame :P This is pretty neat so far. I, too, have a side project I'd love to quit my job to work on, but I think it's less monetizable than an actual game.
Less experienced engineers are very difficult to assess without some kind of coding exercise. All the hires I've made that I'd characterize as mistakes are of junior engineers that I didn't do a coding exercise with and interviewed well, but didn't bring that interview polish to the job. Since instituting whiteboard exercises for junior positions, our success rate has been higher (no pun intended).
Having just been through this process (landed a new job after a 2-month search), the worst part about whiteboard coding is how humiliated you feel if you don't get it right or don't know where to start. Is it really necessary to do that to candidates? I've been doing this for 15+ years professionally, have a master's in CS and I struggled to answer many questions. Just stood there blinking like a goldfish. If compani…
Earlier quoted context omitted.
State dependent learning is a bit of a factor too. I can count on one hand the number of times I’ve presented anything on a whiteboard at work, yet just about every company asks these questions during interviews. A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. Whiteboard coding interviews are one…
> A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in. I do coding interviews in the following manner: I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, makin…
First, your definition of "interesting problem" probably includes a lot of personal biases. What you find interesting probably touches stuff you've had experience with, but just because you've done work on say, customized implementations of binary search, doesn't mean it's a good baseline for all developers everywhere. Maybe they've worked on different domains or solved different problems and can't relate to questions you personally find "interesting".
It'd be much fairer to select a boring question that involves standard stuff that everyone has to face at some point in their careers, like string manipulation. And even then, it just involve normal transformations ('look for and remove special characters') and not wacky, HackerRank-style rules ('no two bs after cs but before as').
In general, an interview is to understand what a candidate brings to the table. Therefore, one of the best ways to assess "glass half full" is to talk about their past work. The interviewer is a subject matter expert who can definitely ask pertinent questions about the candidate's work. In many cases, more so for scientific positions - the candidate's work is publicly available. Currently, many interviewers go for -…
For example, one I like to ask (in person, with no computer access), ostensibly to gauge familiarity/intimacy with the Unix CLI, is:
"For each letter of the alphabet, see if you can name a Unix command (anything one can type at a shell prompt that won't return a "command not found error") that starts with that letter."
I preface the question with something suggesting that it's supposed to be fun, and I encourage skipping letters and coming back to them to avoid pressure (nor do I write down the answers). Most people are surprised at how many they remember without much thought.
Although not particularly deep, further discussions can arise from differences between shells with respect to built-in commands, as well as differences between OS flavors. Also, I've discussed how a somewhat new language like Java has made one of the otherwise difficult letters much easier.
Regardless of the trivial nature of the question/exercise, it provides a spectrum of jumping-off points for deeper knowledge discussions, all of which are signaled/chosen by the candidate.
VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…
> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that…
A regular viewer of my daily Twitch programming stream (link is in my profile) asked me to solve a problem he was asked to whiteboard. He wasn't asked to draw diagrams or write pseudo-code so they could learn how well he communicated. He was asked to write the code and it was heavily implied that it must compile and run -- even though whiteboards don't do that. Here's my attempt: https://youtu.be/6LHqrxrC6Uo I solved…
Probably you got exhausted after doing all these preparations and debugging issues not related directly to the algorithm. I'm not sure the final solution is correct, it is not tested on a graph with multiple connected segments of the same color. It looks more like a convoluted way to count colors globally, discarding standalone colors, if I understood your solution properly.
To me, it's not about the code on a whiteboard vs a computer and correctness. It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them? A whiteboard to me is a much simpler and accessible medium through which to explore…
If the goal is to test the thought process why not give interviee a self-directed project then ask them to present a 10 minute talk about it? You get some code written to verify the engineer can build something, plus you get confirmation that they can organize their thoughts and effectively communicate them to another engineer. Isn't that a more realistic scenario? How often do you give an (employed) engineer a task…
I think most people that are opposed to coding interviews feel that way because they don't feel confident in their ability to do those interviews well, whereas they do feel confident in their ability to "get work done". Here's the thing though. Let's say you're the one giving the interview to two people who claim to be able to get shit done. One is able to code up a solution quickly and the other struggles, producing…
The whiteboard is not providing "high signal". Everything else is. The whiteboard is providing low signal, and taking quite a bit longer to do it.