8 ms·

> 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

> 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 unfamiliar problems and they made it clear they didn't really expect you to finish the whole thing in 50 minutes, I guess. Part of the problem is that most companies seem to be complete dogshit at communicating: 1) what they're going to quiz you over—they seem to think it must be a pop-quiz with absolutely no way for you to know what might be on it or specifically prepare for it, sourced from literally all of your past experience, all of CS, all of software engineering practices, and maybe even stuff you never claimed to know, which is plainly, to be blunt, fucking bullshit and goddamn insulting, and that's not even getting into how many of these questions/challenges rely on recalling (rarely on formulating or discovering, that's just impractical and unlikely) some very specific "ah-ha" insight to not look like a complete dumbass while trying to solve them—and, 2) why they're giving you certain challenges or asking certain lines of questions, what they're trying to evaluate, or how you'll be judged, leading to stressful, pointless guessing games like "should I risk not completing this challenge to write very complete tests, because they'd rather see good tests than a working solution, or am I just completely fucked and a getting a definite 'no' if I don't have a working solution anyway, so I should not write any tests that don't increase the likelihood of my finishing in the time allotted?" [EDIT] "why don't you just ask questions to resolve point #2?" Yes that can work, but a lot of this is so damn vague that then you've got the meta-guessing-game where there's a real chance you'll "lose some points" if you ask valid-in-context but "wrong" questions, because any "real" developer should know the answer ("of course you must write extremely complete tests for all code ever! Ugh, this guy must suck.")

rimliu 7y ago
> "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.
- pc86 7y ago
  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.
  - shantly 7y ago
    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."
    - tomp 7y ago
      So what would you like to be interviewed on? If it's not based on your CV/experience, general CS best practices, neither known nor unknown technologies, nor general problem-solving questions... 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.)
BiteCode_dev 7y ago
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.
- ScottFree 7y ago
  I've done a similar test. I didn't finish it in the time allotted, but a few other candidates did and they hired one of them. The fact companies can do these kinds of demanding frontend tests and still hire people is what makes me think there's a glut of web developers and not a shortage like people keep saying.
  - codyb 7y ago
    I had an onsite recently that told me were were going to be building something that had to interact with a postgres database. I built out the entire backend prior and took copious notes because getting stuck looking up things like “how do I initialize a postgresdb” (something I do maybe once a year, if ever) would eat up time. I think I did pretty well at that onsite because of the fact that I prepped before hand and they didn’t seem to mind that. It’s weird to me because in general most engineers are rarely if ever creating an entire stack from scratch and it can be very easy to want to do such a thing methodically and with best practices in mind. How would I enable hot code reloading? How do I set up PostGres so I’m not just connecting as super user which is obviously a security risk? Etc etc. To be able to do these tasks under pressure with an engineers mindset is tough and you either have to really drill down and focus and stress that in a real setting you wouldn’t be connecting as superuser but for the sake of time in this particular toy exercise you will be. Being able to prep was essential, and even so, I still stumbled here and there with unfamiliar syntax. Interviewing is not a solved problem.
athenot 7y ago
> This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems and they made it clear they didn't really expect you to finish the whole thing in 50 minutes, I guess. This happened to me. I once interviewed at a place where they presented me with a language I had never seen. Very different concepts than your typical C/Algol flavored languages. They went over the basic concepts, with a handy reference sheet for me, then gave me a few tasks to complete in that language. Towards the end, after completing the tasks, I congratulated them for inventing a ficticious language in order to test candidates on a more equal footing. Cute, clever, creative, even though it's probably far-removed from the real world... Their response? Oh this is not a ficiticious language, this is what we use daily. It's our proprietary language and we're quite proud of it. Me: ... (I ended up getting the job and learned a lot in the domain of wheel reinvention.)
- tristor 7y ago
  Was it a company that is in the healthcare technology space, because that sounds like something you'd find there. That or aerospace.
  - sansnomme 7y ago
    MUMPS?
    - athenot 7y ago
      Very close, yes. And yes to the parent comment. ;)
      - BWStearns 7y ago
        So it was Perl?
    - buildawesome 7y ago
      I find it disconcerting that there is a language the healthcare industry uses named MUMPS.
baddox 7y ago
> This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems Why not seek applicants who are familiar with the problems they’ll be regularly encountering for the position you’re trying to fill? And as an employee I’d rather interview for positions that will require me to solve problems I’m familiar with. That’s kinda like the whole point.
- LoSboccacc 7y ago
  everyone is looking for their flavour of 'full stack' because in the mind of middle managers human resources need to be fluid across organisational projects.
- Swizec 7y ago
  Because even if you're familiar with all the tech we use, you're not going to be familiar with the business domain, our cobbled-together solution on top of the tech stack, and the tens or hundreds of thousands of lines of code we nurtured over the past N years. How you handle unfamiliar stuff is critical when evaluating an engineer. That's like the whole job. Unless your goal is to churn out copycat CRUD apps and marketing pages your whole life. Then carry on :)

rimliu 7y ago

> "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.

pc86 7y ago
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.
- shantly 7y ago
  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."
  - tomp 7y ago
    So what would you like to be interviewed on? If it's not based on your CV/experience, general CS best practices, neither known nor unknown technologies, nor general problem-solving questions... 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.)

BiteCode_dev 7y ago

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.

ScottFree 7y ago
I've done a similar test. I didn't finish it in the time allotted, but a few other candidates did and they hired one of them. The fact companies can do these kinds of demanding frontend tests and still hire people is what makes me think there's a glut of web developers and not a shortage like people keep saying.
- codyb 7y ago
  I had an onsite recently that told me were were going to be building something that had to interact with a postgres database. I built out the entire backend prior and took copious notes because getting stuck looking up things like “how do I initialize a postgresdb” (something I do maybe once a year, if ever) would eat up time. I think I did pretty well at that onsite because of the fact that I prepped before hand and they didn’t seem to mind that. It’s weird to me because in general most engineers are rarely if ever creating an entire stack from scratch and it can be very easy to want to do such a thing methodically and with best practices in mind. How would I enable hot code reloading? How do I set up PostGres so I’m not just connecting as super user which is obviously a security risk? Etc etc. To be able to do these tasks under pressure with an engineers mindset is tough and you either have to really drill down and focus and stress that in a real setting you wouldn’t be connecting as superuser but for the sake of time in this particular toy exercise you will be. Being able to prep was essential, and even so, I still stumbled here and there with unfamiliar syntax. Interviewing is not a solved problem.

athenot 7y ago

> This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems and they made it clear they didn't really expect you to finish the whole thing in 50 minutes, I guess. This happened to me. I once interviewed at a place where they presented me with a language I had never seen. Very different concepts than your typical C/Algol flavored languages. They went over the basic concepts, with a handy reference sheet for me, then gave me a few tasks to complete in that language. Towards the end, after completing the tasks, I congratulated them for inventing a ficticious language in order to test candidates on a more equal footing. Cute, clever, creative, even though it's probably far-removed from the real world... Their response? Oh this is not a ficiticious language, this is what we use daily. It's our proprietary language and we're quite proud of it. Me: ... (I ended up getting the job and learned a lot in the domain of wheel reinvention.)

tristor 7y ago
Was it a company that is in the healthcare technology space, because that sounds like something you'd find there. That or aerospace.
- sansnomme 7y ago
  MUMPS?
  - athenot 7y ago
    Very close, yes. And yes to the parent comment. ;)
    - BWStearns 7y ago
      So it was Perl?
  - buildawesome 7y ago
    I find it disconcerting that there is a language the healthcare industry uses named MUMPS.

baddox 7y ago

> This actually might not be so nuts if it were clearly a way to evaluate how you handle unfamiliar problems Why not seek applicants who are familiar with the problems they’ll be regularly encountering for the position you’re trying to fill? And as an employee I’d rather interview for positions that will require me to solve problems I’m familiar with. That’s kinda like the whole point.

LoSboccacc 7y ago
everyone is looking for their flavour of 'full stack' because in the mind of middle managers human resources need to be fluid across organisational projects.
Swizec 7y ago
Because even if you're familiar with all the tech we use, you're not going to be familiar with the business domain, our cobbled-together solution on top of the tech stack, and the tens or hundreds of thousands of lines of code we nurtured over the past N years. How you handle unfamiliar stuff is critical when evaluating an engineer. That's like the whole job. Unless your goal is to churn out copycat CRUD apps and marketing pages your whole life. Then carry on :)