In my senior year of high school, I met with a recruiter from a major tech company based in New York City. It was a super exciting opportunity to work at my then-dream job. At that point, I was only doing freelance and working from my bedroom. It was fun and paid the bills, but it's hard to turn down an office with a firepole to go between floors.
I did really well for most of the interviews and phone screens... until I got to whiteboard coding. It just wasn't how I think. Being presented a problem without doing quick trial and error goes against how I felt about problems - never mind writing a complicated algorithm from scratch.
It's actively pushing how to reinvent the wheel instead of testing how pre-existing, well-made tools can be used creatively and originally. It was in isolation, away from leveraging the internet resources that programmers do every day.
Supposedly the purpose is to "see how you think," but I really don't agree with this method of doing it.
I didn't advance beyond this stage. Apparently, other applicants would spend 6= months studying for these coding interviews - but at the same time, I'm happy I stayed my course.
I'm thankful for that experience, though, because it affirmed why I'd never run a coding interview involving writing from scratch at Melon. It's not an accurate test of skillset, and it's not similar to an actual programming environment at all.
Instead, our policy for technical interviews is more straightforward. Together with an applicant, we'll walk through the codebase of a personal project or something recent they worked on. We talk about why they chose the methods they did. If we find something that we think can be optimized, we point it out and ask if they can do it. We encourage using Google and StackOverflow to do it, too. If they're allowed on the job, why should this be different?
We understand their mindset for building code and thinking through it all. If we ask the candidate to write code at all, it's always something we feel is within the realm of their expertise, and they can still use internet research.
We embrace that programming is a diverse skill that people have learned differently. People enjoy different aspects, do it for various reasons, and are great at their specializations. Sure, being a technical jack-of-all-trades is cool, but I'd rather not lose out on these highly specialized team members because they couldn't make me a bubble sort.
- Devon
I did really well for most of the interviews and phone screens... until I got to whiteboard coding. It just wasn't how I think. Being presented a problem without doing quick trial and error goes against how I felt about problems - never mind writing a complicated algorithm from scratch.
It's actively pushing how to reinvent the wheel instead of testing how pre-existing, well-made tools can be used creatively and originally. It was in isolation, away from leveraging the internet resources that programmers do every day.
Supposedly the purpose is to "see how you think," but I really don't agree with this method of doing it.
I didn't advance beyond this stage. Apparently, other applicants would spend 6= months studying for these coding interviews - but at the same time, I'm happy I stayed my course.
I'm thankful for that experience, though, because it affirmed why I'd never run a coding interview involving writing from scratch at Melon. It's not an accurate test of skillset, and it's not similar to an actual programming environment at all.
Instead, our policy for technical interviews is more straightforward. Together with an applicant, we'll walk through the codebase of a personal project or something recent they worked on. We talk about why they chose the methods they did. If we find something that we think can be optimized, we point it out and ask if they can do it. We encourage using Google and StackOverflow to do it, too. If they're allowed on the job, why should this be different?
We understand their mindset for building code and thinking through it all. If we ask the candidate to write code at all, it's always something we feel is within the realm of their expertise, and they can still use internet research.
We embrace that programming is a diverse skill that people have learned differently. People enjoy different aspects, do it for various reasons, and are great at their specializations. Sure, being a technical jack-of-all-trades is cool, but I'd rather not lose out on these highly specialized team members because they couldn't make me a bubble sort.
- Devon