Another take on what the author proposing is to simply not care about the output of the task, but focus on how that person approaches the problem (even if they don't manage to complete the task at all).
A hiring test I'd like to run
41–50 of 203 posts
Re: A hiring test I'd like to run
#42I hear a lot (and believe myself I suppose) that I would rather hire someone that knows how to learn than someone who currently knows thing x but can't pick up and learn things on their own. But I feel like it's VERY hard to figure this out about someone. It's pretty easy to test how well someone knows a particular technology or tool (given some variance for operating in a high-pressure scenario etc.) but it seems pretty hard to tell if someone can learn new things quickly, and learn the right things. I feel like this is what algorithm tests are trying to do, but I also feel like a lot of algorithms are based on having a key insight into a problem that is, at least in my experience, pretty hard to have when you're in a room with strangers on a timer and being judged, so if you don't know the particular algorithm to apply, good luck. And also it's pretty easy to go study algorithms and hope you remember how to implement DFS if that's what they ask you in the interview. And there is some non-zero value to just knowing about different data structures and algorithms for certain types of work for sure. I don't think many of us web developer types will be implementing DFS ourselves, but I run into issues pretty often where having knowledge about different data structures and algorithms comes in handy.
So I can see the appeal to doing a test like this that has nothing to do with a particular skill, where you're trying to evaluate someone's judgement and how quickly they can absorb new ideas or figure something out on the fly etc. BUT, I just think there are too many factors that can really muddy this up, and I still don't feel like there's an objective way to measure "smart and learns quickly". Even "learns quickly" is somewhat vague; I personally wouldn't expect someone to pick up, say, functional programming in an hour just by saying "go read about it." Some things take longer to learn than others.
Anyway, there's no silver bullet. I still feel like we end up making pretty subjective decisions about other people when interviewing them. I don't think we're even all that aware of them ourselves. I would say though that if you're interviewing somewhere, you're getting useful information about that place by how they interview you, and so I wouldn't feel too disheartened if you feel like the interview is unfair or doesn't work for you. That's probably a good sign that you wouldn't enjoy working there anyway.
Re: A hiring test I'd like to run
#43Earlier quoted context omitted.
I've never found anything of actual use on StackOverflow in my ~decade of doing this professionally. The only time StackOverflow provided useful answers to my questions was during my first year of programming courses in university.
StackOverflow is fine when learning a new language. But indeed, hardly seems to help in real-world problems.
Thats why I put in the "know how to ask questions" part. Sure, a lot of the time you don't get an answer. And you end up figuring out stuff the hard way yourself. But then I always force myself to go back and answer my own question. It might help the next guy, but more importantly if I have to answer the question myself I need to put what I learned in writing.. and in an understandable way as well. Often the exercise of explaining it will make me understand even better.
Re: A hiring test I'd like to run
#44I interviewed at Twilio. My resume and phone chats made it abundantly clear that my professional experience was 95% backend in languages like Java and Go. I looked at their Glassdoor where people wrote they were heavily biased to the algorithm type questions, for better or worse. In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, wit…
> was allowed to Google whatever but 50 minutes is still a crazy time crunch to figure out a lot of the stuff that needed to be figured out. The point of such interviews is to see how you handle a situation with limited time and - like in this example - mostly new tech and paradigms to you. Usually you are not expected to output anything.
It's not going to do that. Over time it's just going to select front-end developers experienced with JavaScript.
Re: A hiring test I'd like to run
#45I don't mean to be derisivs but at that point - testing for reasoning, understanding, personality - Why stick with a software tool? You'd be better off arranging to play a strategy, preferrably collaborative, boardgame. One day I'll use Pandemic as an interviewing tool. I wonder of it'd work as a pre-formal interview stage
I've been to group interviews where they pretty much do that. Randomly divide all the candidates into groups, give them a task, see how they work together.
I can't say I enjoyed the experience - and I've no idea how good it is as a tool - but it was illuminating to see how people treated each other.
Re: A hiring test I'd like to run
#46I interviewed at Twilio. My resume and phone chats made it abundantly clear that my professional experience was 95% backend in languages like Java and Go. I looked at their Glassdoor where people wrote they were heavily biased to the algorithm type questions, for better or worse. In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, wit…
> In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, without the use of any framework, just vanilla JS. > I was allowed to Google whatever but 50 minutes is still a crazy time crunch to figure out a lot of the stuff that needed to be figured out. This actually might not be so nuts if it were clearly a way to evaluate how you handle u…
> "to evaluate how you handle unfamiliar problems"
Re: A hiring test I'd like to run
#47Earlier quoted context omitted.
> In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, without the use of any framework, just vanilla JS. > I was allowed to Google whatever but 50 minutes is still a crazy time crunch to figure out a lot of the stuff that needed to be figured out. This actually might not be so nuts if it were clearly a way to evaluate how you handle u…
> "to evaluate how you handle unfamiliar problems" The only problem here is figuring out why would anyone work for a company with these practices. Unless I am missing something and it is common practice to build a product without any thinking, research and design.
The goal is to see how you approach thinking about it and conducting your initial research. The solution is irrelevant, and falling back to "well we won't do that at work!!" is missing the point.
If you're the type of person who freaks out when we discuss the possibility of using a new tech you're unfamiliar with, I don't want to work with you. There's a certain level of pressure in saying "I know we've never worked with $TECH before, but we're going to use it for $IMPORTANT_PROJECT_WITH_A_DEADLINE" and if 50 minutes of fiddling around with JavaScript is enough to psych you out, you're probably not going to handle the new tech well either when you barely even know what to search for when looking for tutorials.
Re: A hiring test I'd like to run
#48Earlier quoted context omitted.
> In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, without the use of any framework, just vanilla JS. > I was allowed to Google whatever but 50 minutes is still a crazy time crunch to figure out a lot of the stuff that needed to be figured out. This actually might not be so nuts if it were clearly a way to evaluate how you handle u…
> "to evaluate how you handle unfamiliar problems" The only problem here is figuring out why would anyone work for a company with these practices. Unless I am missing something and it is common practice to build a product without any thinking, research and design.
Almost no companies come out and say "we will ask you some dumb bullshit in the interview and not tell you what we're evaluating or how we're evaluating it" and a huge percentage of the industry interviews like this, at least to some degree. The best I've ever gotten when asking "is there anything I should prep for or expect for the on-site, and how's the interview going to run?" is "bring a laptop, here's a schedule of who you'll talk to and what their titles, oh and consider dressing [some way]".
Re: A hiring test I'd like to run
#49Earlier quoted context omitted.
> "to evaluate how you handle unfamiliar problems" The only problem here is figuring out why would anyone work for a company with these practices. Unless I am missing something and it is common practice to build a product without any thinking, research and design.
The goal is to see how you approach thinking about it and conducting your initial research. The solution is irrelevant, and falling back to "well we won't do that at work!!" is missing the point. If you're the type of person who freaks out when we discuss the possibility of using a new tech you're unfamiliar with, I don't want to work with you. There's a certain level of pressure in saying "I know we've never worked…
From my perspective, a big part of the problem is that companies don't let you know they'll be doing something like this (a simple "the 1:00 section of the interview will involve giving you a task using some tech you're not familiar with"), so it's a surprise (interviews are already stressful in ways that real work pretty much never is, "surprises" are deeply unhelpful for evaluating candidates outside very rare and particular kinds of work), and then also often forget to provide extremely useful information like "we know this isn't a familiar language or environment for you—we specifically want to see how you work in something you're not familiar with, so don't stress out if you aren't close to a complete solution by the end, we don't really expect you to be."
Re: A hiring test I'd like to run
#50I interviewed at Twilio. My resume and phone chats made it abundantly clear that my professional experience was 95% backend in languages like Java and Go. I looked at their Glassdoor where people wrote they were heavily biased to the algorithm type questions, for better or worse. In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, wit…
> In reality I was given only a single coding interview my whole onsite, and it was to build a JavaScript SPA, including routing/linking, without the use of any framework, just vanilla JS. > I was allowed to Google whatever but 50 minutes is still a crazy time crunch to figure out a lot of the stuff that needed to be figured out. This actually might not be so nuts if it were clearly a way to evaluate how you handle u…
I don't know. I'm very comfortable in JS, valilla, jquery, react and vue. And apparently my customers think I do a decent freelancer work since they keep hiring me back.
And yet, an entire SPA in vanilla JS in 50 minutes seems a lot to me.
I guess it depends of the size of the SPA, but user input + rendering + routing + whatever logic they ask you for the app is a lot of work.
I guess it depends a lot of the requirements: you could skip the routing, make a dirty innerHTML rendering, deal with one browser only for the input events, etc. Still...
Besides, I hate being rushed when I code. I never speed code IRL, the deadlines are in days/months, hours for crisis, never minutes.