51–60 of 203 posts
First test of any software dev: Do you know how to look for answers on stackoverflow? Second test of any software dev: Do you know how to ask a good question on SO?
And the ROI on learning to game Stack Overflow isn't worth it for me. :)
Well this is exactly like a test I went through at one time. It even used the same reasoning pretty much. The job was fullstack node and react, I went in and they said we want you to look at this game written in Python which is really slow and tell us what is wrong with it (I hadn't done python in years and back then wasn't very good at it). We will sit with you. I said I was game, they said lots of people weren't -…
Of course there was pressure, but why not just say that you know an algorithm that can do this faster, but you can't remember the name of it, and then just provide the intuition behind it?
I 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…
I've found it's not possible for me to enter an interview with an unbiased mind having read a resume.
Some of the tests in my current company work like this. We don't expect you to have everything memorized. We give you a problem and then say, "feel free to use any reference you want, help, man pages, google, stack overflow, whatever." Some people still stubbornly refuse to look for help. Some people act on the first google search result even though it's obviously wrong. Some people don't know how to read a man page.…
The thing is that some people might feel that they will get assessed lower if they look for help rather than come up or even luck into a solution.
Despite making it abundantly clear to candidates that they should take the test(s) as a pair programming sessions, we had candidates struggle with some basic stuff and not ask questions. They just kept trying things while getting more nervous.
A lot of people would feel that it might be held against them. The thing is a lot of people under pressure will forget the basics
Funny thing, it had a bug. As long as you didn't let go of the mouse button, it would let you open and navigate all of the menus. So I simply browsed the menu UI until I found the correct choice. 100% score.
Earlier 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…
I was on a python/javascript team that transitioned to kotlin -- everything went well, better than I would have expected tbh given only 1 of us even had any production java experience, but 50 minutes would not have been enough time to figure out how to usefully set up the IDE, let alone build anything beyond FizzBuzz.
I 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.
Earlier quoted context omitted.
> 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.
This reminds me of the story of the young intern that went around a few years ago. They sheepishly admitted to their boss at the end of their summer internship that they had just googled all the Excel things that were required, that they hadn't actually known any of it. "But your generation KNOWS to look for help, and knows where to find it! That's where you were doing it right," was the boss's response. And that's h…
Guy googled enough to muddle through and got hired. Management explicitly said that he was the only person to look up information about the software, and that was why they hired him.
Earlier quoted context omitted.
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…
People ask all of these for good reasons. You can write literally anything on the CV, so people ask about your experience to check you're not lying (you'd be surprised how many people do lie and at least misrepresent). People ask coding challenges because they expect you to code (and we've all heard horror stories about like the head of IT security not actually knowing how computers work). They ask you general problem-solving questions to test your intelligence, mental models, and behavior under stress/adversity (again, you'd be surprised how many people just suck here, or worse, get insulting etc. ALSO - note that I'm not saying that all such questions are good, they're mostly bad, but with a little bit of thought and planning you can design a good question). People test for basic CS knowledge because it's important in almost all situations (would you hire a brain surgeon that didn't know what a spleen was?).
(Not discounting all the actually terrible interviewing practices, e.g. people asking impossible questions to feel good about how smart they are, etc.)