11 ms·

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 lo

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, 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. It felt like a massively unfair way to evaluate me. I have honestly never felt more screwed over and time wasted by an interview than at Twilio and I would highly recommend avoiding interviewing there. My overall point being, is there’s no silver bullet. It’s not necessarily about this magical process will work well and this one will not. It’s about the small details, especially things like making sure all of your interviewers actually read the candidates resume and that everyone knows what type of role they are interviewing for, and that the interview is designed to discover both the candidates strength and weakness. I’ve been on both sides of the process and I know too often shortcuts are taken and churning the pipeline forward takes priority over doing a diligent job and respecting the time of every candidate you engage with. The very fact that the foundation of tech recruiting is inexperienced recruiters, with minimal tech knowledge, who are incentivized by sales type numbers, and churned through themselves at a comical rate, speaks to how the industry views recruiting. College athletes get recruited, top law school graduates get recruited, engineers aren’t recruited but relentlessly spammed in hopes of finding more bodies to feed into a process straight from a Kafka short story, the problem starts there and no a-ha process improvement will fix that.

numlock86 7y ago
> 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.
- jjjensen90 7y ago
  Seems unnecessarily cruel and divorced from reality, even if that is the point. In real software jobs, you don't have to learn a new language, framework, and especially a new paradigm in 50 minutes. Those are things that happen over weeks, months, and years. I don't know of any useful skill that adding even more stress to an interview will surface.
- nilkn 7y ago
  It's not going to do that. Over time it's just going to select front-end developers experienced with JavaScript.
  - shantly 7y ago
    An engineering mindset and systems thinking—or simple awareness of things like experimental design principals—are badly under-applied to software hiring processes, IMO. "What are we trying to select for with this section of the interview? Does this accomplish that, or does it do something else, or does it accomplish that but also do something else? Are we being any less humane and supportive in this section than necessary to evaluate what we have decided we need to evaluate? If not, how can we fix that?"
- minimaxir 7y ago
  Your mileage will vary. I've been in enough interviews where it's a flawless-answer-or-fail.
- Merad 7y ago
  What exactly would you be hoping to see the candidate do in such an interview? I’m moderately experienced on the front end (mostly jQuery and React, a bit of AngularJS) but if the task is making a SPA in vanilla JS I’d barely know where to begin. It’s pretty likely that I’d do hours of reading and researching before writing a single line of code. It would be one thing to talk about how you’d approach the task, but the GP specified their interview was apparently expecting workable code to be produced during the interview.
sethammons 7y ago
Sorry to hear about your experience. I'm at twilio and we recently started a hiring guild to tackle this exact problem. Most of the members of the guild on the technical side are there specifically to address bad interview experiences like yours. We are focusing on improving process, questions, and candidate experience. We are moving the technical portion towards work sample like questions and ensuring the interview focuses on what you bring to the board as opposed to someone's pet question in their favorite stack.
shantly 7y ago
> 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.
avip 7y ago
I don't do much hiring, but when I do I make an active effort to avoid reading candidates resumes. I've found it's not possible for me to enter an interview with an unbiased mind having read a resume.
- josephorjoe 7y ago
  This feels weird to me. If you have advertised a job and I've given you my resume, it is to give you some information you can use to avoid wasting your time and my time. Just like I would hope your advertisement is accurate and useful enough to let me decide if it is a good use of time for me to send you a resume (e.g., saw an ad for "react developer" -- got to the interview and they were looking for a "server side java dev" -- I mean -- wtf?). Not reading a resume before an interview feels... rude. It feels like the path that leads to you asking a Java/Go programmer to do a Javascript coding challenge in 50 minutes, which is a waste of everyone's time.
  - avip 7y ago
    It is rude. People put lots of effort into resumes. But it's ruder to reject a candidate based on age, gender, martial status, education or lack thereof or doing non sw jobs in the past. I always talk on the phone before and that's where we both make sure the interview is of relevance.
    - tristor 7y ago
      If you can't read someone's resume without rejecting them based on age, gender, marital status, education or lack thereof, or for their non-sw work history, then it sounds like you're not a very good person to be interviewing candidates. The concept of "unconscious bias" might be true in an academic sense, but in a very real way you should be treating people with respect regardless of their characteristics, especially during an interview process. Not reading someone's resume isn't just rude, it's supremely disrespectful. I take a completely different approach, because I have been on the receiving end of disrespectful interviews and I won't stand for it and I don't expect the candidates I interview to accept it either. I carefully read the resume and research the candidate far in advance to the interview. I only ask questions during the interview which are open-ended, not trivia questions, and are directly related to either the content of the candidate's resume or things we're actually doing day-to-day on my team. The dog and pony show interview style is intensely disrespectful and so is the idea that you won't even read a candidate's resume. I've walked out of interviews where both have happened, and I hope everyone on HN gets the personal confidence to do the same. I'm a professional, I expect to be treated like a professional, and I return that by treating those I interview like professionals. End of story.
oarabbus_ 7y ago
Great anecdote, thanks for sharing. I myself have some stories about poor tech hiring all over the place. As a counterpoint/to play devil's advocate - it doesn't actually seem like these companies are any worse off for this, are they? In other words, it doesn't seem like poor interviewing practices (Google is offender #1) are negatively affecting these companies.
- astrofinch 7y ago
  What poor hiring practices does Google have?
hinkley 7y ago
The last two times I went through an interview cycle (one on each side) it struck me how dependent your success was on your chosen tools and whether the coding question dovetailed with those choices or not. For instance if I'm working on a hard problem I usually need tests (whether I initially admit that to myself or not), and despite the fact that I'm often the one who sets up and/or defines our testing strategies, every time I set things up is an adventure, because I set it up once and run that way for years. I have zero muscle memory for the installation process and anyway the decisions might be a little different in 3 years. And more to the point, I want people to copy what I've done, so I do the same thing (which gets me an experience of what others are having to put up with/enjoying about my solution). For the app server the situation isn't much better. In an interview taking the time to set any of that up would be crippling, even though I'd come out even on a 2-3 day story and ahead on anything longer. I have thought many times about setting up a blank application with testing, logging, and production-reasonable overrides for all the defaults for the app server, etc. Just so I have an easy starting point for quick prototyping, which is essentially what an interview often is. Generators probably work for an interview, but for real projects, re-applying the generator with each release is kind of a bear. I propose that it would be much easier (possibly trivial) to do on an empty shell project and then merge downstream. I kind of think one of the things we are missing about DVCS is that the ability to maintain permanent forks gives us other options for arranging cross-cutting concerns. Maybe one more generation of merge tooling is necessary for that to be A Thing.
- GreenJelloShot 7y ago
  Most interviews seem to weigh heavily in favor of "sprinters" over "marathoners". That is, they select for people who can go from nothing to working code in a short period of time. I am one of those people who takes a while to get rolling, especially when starting from scratch. Interviews generally give you 30 minutes or an hour to produce something. I will easily take an hour to think about the problem, do some research, and then create some notes before writing any code. This is, of course, not what most companies want. Unless you are asking me to do something trivial or something that I have claimed to do many times in the past, you can't expect me to come up with the "right" answer instantaneously. I never jump right into editing code, unless I am already intimately familiar with it.
vanusa 7y ago
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 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. This is of course both completely ludicrous, and incredibly disrespectful. Thanks for pointing this out so that we know to add that company (Twilio) to our list of companies to pass on, the next time they come our way.
- echelon 7y ago
  I hope Twilio (and other companies) are reading. One bad experience can turn many engineers away from your recruiting pipeline.
  - dntrkv 7y ago
    Do you really take random comments on the internet into consideration when you're looking for your next gig? If you do, in my experience, every company is off the table.
    - Aeolun 7y ago
      What else am I supposed to take into consideration? The companies marketing material? Maybe the signal in those comments is a bit biased, but it seems far less biased than the alternatives.
      - dntrkv 7y ago
        At this point, unless I talk to someone I trust within a company, I try to reserve all judgement. In fact, I do that with everything nowadays. The internet and modern media skews so negative, according to them nobody is happy anywhere and everything sucks. That hasn't been my experience.
plughs 7y ago
I had a 2 hour coding project in a language I'm familiar with - entirely based around a sub module that I've never used before. Maybe 2 hours should have been enough? I don't know - with the stress of writing under time pressure ( I had a new sympathy for contestants in cooking shows ) and complete unfamiliarity with the module, I was pretty impressed that I submitted something that passed the unit tests. Then I got rejected with the implication that I wasn't using good OOP principles. OK, my decision to store JSON data as a byte array was unorthodox - but it worked without a lot of coding overhead. I thought it was pretty clever frankly.
- mixmastamyk 7y ago
  Yeah bullshit, in the real world you’d refactor.
  - hvidgaard 7y ago
    There is three types of developers in this scenario. Those who "do it right from the start", they are slow. Those that do the quick and dirty, and create an issue in the issue tracker about what to change and why. Then there is those that do the quick and dirty with mental note about what to change, and never return to it. I do not want the latter.
- brigandish 7y ago
  I'd be more impressed if they had a mock code review as a discussion afterwards where you could explain your decisions and they could question/challenge parts of it. Not only would that give you time to settle, it'd give both parties some real insights into expectations, skills and work practices. Something like: "Why did you store it as a byte array?" and then "How can you reconcile it with OOP principles?" as follow up questions would be far more productive. "Which principles do you mean? If I write an object then it only matters to the caller what the API is, not the underlying storage, right?" and before you know it you're in an interesting conversation where you both have the opportunity to learn something. It'd probably be quite enjoyable, regardless of whether you got the job in the end.
paxys 7y ago
Were you interviewing for a backend or frontend position?
mixmastamyk 7y ago
It’s hard to realize under the gun, but we have to put our foot down occasionally and speak up.
drdaeman 7y ago
> It felt like a massively unfair way to evaluate me. My advice to someone in a similar situation is to start talking and ask about what we want to really achieve here. Not what the task description literally says (SPA or whatever - that's "how" but not "what for"), but what's the real business purpose for it. For the interview purposes - what do they want to see during or after those 50 minutes. Then making a guess whenever this objective can be realistically delivered within the provided constraints, and communicating how do you feel about it. If they provide their real expectations (e.g. "we want to see how you tackle a problem outside of your immediate expertise domain, we recognize harsh time constraints and it is okay if you won't complete it, although we'd appreciate trying your best") it's all fair game. If they don'tjust insist they want this specific JS SPA done in 50 minutes - well, that says something about their project management habits. In such case, I'd start asking questions about the role responsibilities.
Alex3917 7y ago
> 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. OK but that's like 4 lines of code: Line 1: Get the URL of the current page Line 2: Get the path part of the URL Line 3: Using the path as a key, retrieve some chunk of text from an object Line 4: Write that chunk of text to the DOM I wouldn't know the syntax for any of that without googling, but that doesn't seem excessively crazy even as a question for someone who doesn't know the language.
xivzgrev 7y ago
I had an interview like that. I’m a marketer and my background is clearly B2C, and a hiring manager reached out about a B2B role. We chatted, had a fine conversation, then I had an hour “test” on lead scoring. I wasn't passed on, and told it was because I had no prior experience with B2B lead scoring...duh?
iandanforth 7y ago
> engineers aren’t recruited Yes they are? Gift baskets, personal emails/calls from the CEO, offers of travel just to meet the team (not an interview), offers to fly out and meet with them. The whole nine yards. The number of people who get this treatment is small compared to the number of engineers, but it's not zero.

numlock86 7y ago

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

jjjensen90 7y ago
Seems unnecessarily cruel and divorced from reality, even if that is the point. In real software jobs, you don't have to learn a new language, framework, and especially a new paradigm in 50 minutes. Those are things that happen over weeks, months, and years. I don't know of any useful skill that adding even more stress to an interview will surface.
nilkn 7y ago
It's not going to do that. Over time it's just going to select front-end developers experienced with JavaScript.
- shantly 7y ago
  An engineering mindset and systems thinking—or simple awareness of things like experimental design principals—are badly under-applied to software hiring processes, IMO. "What are we trying to select for with this section of the interview? Does this accomplish that, or does it do something else, or does it accomplish that but also do something else? Are we being any less humane and supportive in this section than necessary to evaluate what we have decided we need to evaluate? If not, how can we fix that?"
minimaxir 7y ago
Your mileage will vary. I've been in enough interviews where it's a flawless-answer-or-fail.
Merad 7y ago
What exactly would you be hoping to see the candidate do in such an interview? I’m moderately experienced on the front end (mostly jQuery and React, a bit of AngularJS) but if the task is making a SPA in vanilla JS I’d barely know where to begin. It’s pretty likely that I’d do hours of reading and researching before writing a single line of code. It would be one thing to talk about how you’d approach the task, but the GP specified their interview was apparently expecting workable code to be produced during the interview.

sethammons 7y ago

Sorry to hear about your experience. I'm at twilio and we recently started a hiring guild to tackle this exact problem. Most of the members of the guild on the technical side are there specifically to address bad interview experiences like yours. We are focusing on improving process, questions, and candidate experience. We are moving the technical portion towards work sample like questions and ensuring the interview focuses on what you bring to the board as opposed to someone's pet question in their favorite stack.

shantly 7y ago

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

avip 7y ago

I don't do much hiring, but when I do I make an active effort to avoid reading candidates resumes. I've found it's not possible for me to enter an interview with an unbiased mind having read a resume.

josephorjoe 7y ago
This feels weird to me. If you have advertised a job and I've given you my resume, it is to give you some information you can use to avoid wasting your time and my time. Just like I would hope your advertisement is accurate and useful enough to let me decide if it is a good use of time for me to send you a resume (e.g., saw an ad for "react developer" -- got to the interview and they were looking for a "server side java dev" -- I mean -- wtf?). Not reading a resume before an interview feels... rude. It feels like the path that leads to you asking a Java/Go programmer to do a Javascript coding challenge in 50 minutes, which is a waste of everyone's time.
- avip 7y ago
  It is rude. People put lots of effort into resumes. But it's ruder to reject a candidate based on age, gender, martial status, education or lack thereof or doing non sw jobs in the past. I always talk on the phone before and that's where we both make sure the interview is of relevance.
  - tristor 7y ago
    If you can't read someone's resume without rejecting them based on age, gender, marital status, education or lack thereof, or for their non-sw work history, then it sounds like you're not a very good person to be interviewing candidates. The concept of "unconscious bias" might be true in an academic sense, but in a very real way you should be treating people with respect regardless of their characteristics, especially during an interview process. Not reading someone's resume isn't just rude, it's supremely disrespectful. I take a completely different approach, because I have been on the receiving end of disrespectful interviews and I won't stand for it and I don't expect the candidates I interview to accept it either. I carefully read the resume and research the candidate far in advance to the interview. I only ask questions during the interview which are open-ended, not trivia questions, and are directly related to either the content of the candidate's resume or things we're actually doing day-to-day on my team. The dog and pony show interview style is intensely disrespectful and so is the idea that you won't even read a candidate's resume. I've walked out of interviews where both have happened, and I hope everyone on HN gets the personal confidence to do the same. I'm a professional, I expect to be treated like a professional, and I return that by treating those I interview like professionals. End of story.

oarabbus_ 7y ago

Great anecdote, thanks for sharing. I myself have some stories about poor tech hiring all over the place. As a counterpoint/to play devil's advocate - it doesn't actually seem like these companies are any worse off for this, are they? In other words, it doesn't seem like poor interviewing practices (Google is offender #1) are negatively affecting these companies.

astrofinch 7y ago
What poor hiring practices does Google have?

hinkley 7y ago

The last two times I went through an interview cycle (one on each side) it struck me how dependent your success was on your chosen tools and whether the coding question dovetailed with those choices or not. For instance if I'm working on a hard problem I usually need tests (whether I initially admit that to myself or not), and despite the fact that I'm often the one who sets up and/or defines our testing strategies, every time I set things up is an adventure, because I set it up once and run that way for years. I have zero muscle memory for the installation process and anyway the decisions might be a little different in 3 years. And more to the point, I want people to copy what I've done, so I do the same thing (which gets me an experience of what others are having to put up with/enjoying about my solution). For the app server the situation isn't much better. In an interview taking the time to set any of that up would be crippling, even though I'd come out even on a 2-3 day story and ahead on anything longer. I have thought many times about setting up a blank application with testing, logging, and production-reasonable overrides for all the defaults for the app server, etc. Just so I have an easy starting point for quick prototyping, which is essentially what an interview often is. Generators probably work for an interview, but for real projects, re-applying the generator with each release is kind of a bear. I propose that it would be much easier (possibly trivial) to do on an empty shell project and then merge downstream. I kind of think one of the things we are missing about DVCS is that the ability to maintain permanent forks gives us other options for arranging cross-cutting concerns. Maybe one more generation of merge tooling is necessary for that to be A Thing.

GreenJelloShot 7y ago
Most interviews seem to weigh heavily in favor of "sprinters" over "marathoners". That is, they select for people who can go from nothing to working code in a short period of time. I am one of those people who takes a while to get rolling, especially when starting from scratch. Interviews generally give you 30 minutes or an hour to produce something. I will easily take an hour to think about the problem, do some research, and then create some notes before writing any code. This is, of course, not what most companies want. Unless you are asking me to do something trivial or something that I have claimed to do many times in the past, you can't expect me to come up with the "right" answer instantaneously. I never jump right into editing code, unless I am already intimately familiar with it.

vanusa 7y ago

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 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. This is of course both completely ludicrous, and incredibly disrespectful. Thanks for pointing this out so that we know to add that company (Twilio) to our list of companies to pass on, the next time they come our way.

echelon 7y ago
I hope Twilio (and other companies) are reading. One bad experience can turn many engineers away from your recruiting pipeline.
- dntrkv 7y ago
  Do you really take random comments on the internet into consideration when you're looking for your next gig? If you do, in my experience, every company is off the table.
  - Aeolun 7y ago
    What else am I supposed to take into consideration? The companies marketing material? Maybe the signal in those comments is a bit biased, but it seems far less biased than the alternatives.
    - dntrkv 7y ago
      At this point, unless I talk to someone I trust within a company, I try to reserve all judgement. In fact, I do that with everything nowadays. The internet and modern media skews so negative, according to them nobody is happy anywhere and everything sucks. That hasn't been my experience.

plughs 7y ago

I had a 2 hour coding project in a language I'm familiar with - entirely based around a sub module that I've never used before. Maybe 2 hours should have been enough? I don't know - with the stress of writing under time pressure ( I had a new sympathy for contestants in cooking shows ) and complete unfamiliarity with the module, I was pretty impressed that I submitted something that passed the unit tests. Then I got rejected with the implication that I wasn't using good OOP principles. OK, my decision to store JSON data as a byte array was unorthodox - but it worked without a lot of coding overhead. I thought it was pretty clever frankly.

mixmastamyk 7y ago
Yeah bullshit, in the real world you’d refactor.
- hvidgaard 7y ago
  There is three types of developers in this scenario. Those who "do it right from the start", they are slow. Those that do the quick and dirty, and create an issue in the issue tracker about what to change and why. Then there is those that do the quick and dirty with mental note about what to change, and never return to it. I do not want the latter.
brigandish 7y ago
I'd be more impressed if they had a mock code review as a discussion afterwards where you could explain your decisions and they could question/challenge parts of it. Not only would that give you time to settle, it'd give both parties some real insights into expectations, skills and work practices. Something like: "Why did you store it as a byte array?" and then "How can you reconcile it with OOP principles?" as follow up questions would be far more productive. "Which principles do you mean? If I write an object then it only matters to the caller what the API is, not the underlying storage, right?" and before you know it you're in an interesting conversation where you both have the opportunity to learn something. It'd probably be quite enjoyable, regardless of whether you got the job in the end.

paxys 7y ago

Were you interviewing for a backend or frontend position?

mixmastamyk 7y ago

It’s hard to realize under the gun, but we have to put our foot down occasionally and speak up.

drdaeman 7y ago

> It felt like a massively unfair way to evaluate me. My advice to someone in a similar situation is to start talking and ask about what we want to really achieve here. Not what the task description literally says (SPA or whatever - that's "how" but not "what for"), but what's the real business purpose for it. For the interview purposes - what do they want to see during or after those 50 minutes. Then making a guess whenever this objective can be realistically delivered within the provided constraints, and communicating how do you feel about it. If they provide their real expectations (e.g. "we want to see how you tackle a problem outside of your immediate expertise domain, we recognize harsh time constraints and it is okay if you won't complete it, although we'd appreciate trying your best") it's all fair game. If they don'tjust insist they want this specific JS SPA done in 50 minutes - well, that says something about their project management habits. In such case, I'd start asking questions about the role responsibilities.

Alex3917 7y ago

> 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. OK but that's like 4 lines of code: Line 1: Get the URL of the current page Line 2: Get the path part of the URL Line 3: Using the path as a key, retrieve some chunk of text from an object Line 4: Write that chunk of text to the DOM I wouldn't know the syntax for any of that without googling, but that doesn't seem excessively crazy even as a question for someone who doesn't know the language.

xivzgrev 7y ago

I had an interview like that. I’m a marketer and my background is clearly B2C, and a hiring manager reached out about a B2B role. We chatted, had a fine conversation, then I had an hour “test” on lead scoring. I wasn't passed on, and told it was because I had no prior experience with B2B lead scoring...duh?

iandanforth 7y ago

> engineers aren’t recruited Yes they are? Gift baskets, personal emails/calls from the CEO, offers of travel just to meet the team (not an interview), offers to fly out and meet with them. The whole nine yards. The number of people who get this treatment is small compared to the number of engineers, but it's not zero.