7 ms·

I once interviewed for Qualia, and surprise surprise both the founding CEO and Product person both were quite rude to me. Unsurprised due to their very young ag

I once interviewed for Qualia, and surprise surprise both the founding CEO and Product person both were quite rude to me. Unsurprised due to their very young age at the time*. Yeah, someone may not be up to your standards, but that's no reason to mock them in a high pressure/vulnerability scenario. It's particularly odd because they were using MeteorJS quite early and I was one of a very few people in the world having creating, deploying, and running a meteorJS app at that time. If you can believe it that was about 6 years ago and I still can recall their faces to this day. Not that it bothers me anymore, but that the impression sunk deep. Their recruiters continue to reach out to me to this day, not a snowball's chance in hell. Contrast this with a scenario at Dropbox where I was underprepared for a datastructures question (BitSet). While the interviewer was mildly taunting me, he at least was gracious enough to give hints and talk me through the solution as it ended. I knew I wasnt getting the role, but at least I learned something that day. * not that rudeness in youth is acceptable or expected but a lack of life experience can lead to a lack of perspective or realization that life is much longer and you only get one reputation

andy_ppp 4y ago
I find the Dropbox story completely stupid too. You should never be failed in an interview for not knowing things you can trivially Google, in my opinion.
- 100721 4y ago
  I disagree. Consider: You're hiring for a data science role, and the candidate doesn't know what an array is. Consider: You're hiring for a senior systems software development role, and the candidate doesn't know what an instruction is. etc.
  - denton-scratch 4y ago
    Would you agree that what an instruction is depends on context?
    - ovebepari 4y ago
      Yes, ofc, he is applying for the "senior systems software development" role so there is our context.
  - deleted 4y ago
    [deleted]
  - squeaky-clean 4y ago
    I don't think knowing what an array is would be something you can trivially Google. Sure you can look up the set of words that make up the definition, but that's not knowing what it is. Something trivially google-able is like not knowing the syntax for generating permutations of a sequence in Python. But not knowing the idea of permutations would not be trivially google-able.
  - deleted 4y ago
    [deleted]
  - jonny_eh 4y ago
    It comes down to what one considers "fundamental knowledge" that one needs to do the job. If you claim to be a programmer, but don't know what an array is, you're probably not actually a programmer. But not knowing esoteric data structure that one may encounter once in their career is not really indicative of anything.
- laluser 4y ago
  Isn't this the case for most interviews? You could simply Google in almost all scenarios. Also, you can fail a single interview and still pass assuming all other interviews go well.
  - andy_ppp 4y ago
    Using Google is the expected real world situation no? I think being able to figure something out you don't know is better than demonstrating something you know perfectly. You'll find out much more about someone if they can do this rather than asking them mundane syntax questions or if they pre-learned how to reverse a binary tree.
    - Froedlich 4y ago
      I've worked on several projects that used "Black Chamber" development. That is, local LAN only, with no access to the internet, and no internet-capable "personal electronic devices" or cellular phones permitted in the development area. You had whatever paper documentation you brought yourself, what was in your head, and whatever was in the /documents directory for that project. It's a different work mindset. I've since moved to a sysadmin position, running a closed network. When programmers decided they couldn't hack being cut off from the net, they'd quit. Dealing with vendors who signed a contract swearing their product didn't need internet access to install or function, when it won't even complete the install without internet access, is more awkward. Particularly when we call the lawyers in. Because that's why we tediously explained the while "no internet" thing in the contract. That they signed. No, not even for just a few minutes. And by the way, can you explain why your installer times out trying to contact servers in three different countries? Our network admin is curious...
      - k10er 4y ago
        I've worked in these environments before (not as a programmer though). It definitely tests your skill and you can identify who can solve problems on their own. Hopefully you have an additional network that you can do research on.
      - 4y ago
- microtherion 4y ago
  I once interviewed a candidate who (1) picked C to solve the programming problem they were given (some other languages were acceptable, and, actually, preferred) and (2) did not know how to dynamically allocate memory in that language. I did spot them the malloc() call (I certainly would not have wanted the interview to get bogged down for that), but yes, I did hold not knowing that against them in my evaluation.
lojack 4y ago
Interviewers tend to have one of two different mentalities... Some are trying to see you fail. They're looking for a reason to say "no". They tend to not be of any help on a problem, will often try to find ways to trick you. They also tend to have an ego problem -- you need to prove to them that you're worthy of joining the team. The other class of interviewers are those that want you to succeed. They will answer questions, and help clarify things. Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work. People that shut down when they get nervous tend to open up to these interviewers. They also tend to be the people that are more pleasant to work with.
- jjkaczor 4y ago
  >Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work So ~14 years ago - after about a year at Microsoft, I was encouraged to assist with interviewing new candidates. At that time, there was no official guide/rulebook for interviewing, but I was told unofficially; "We hire people with a solid technical base, who may not know EVERY thing at the time of interview, because we really want to hire on their future potential". "If a candidate is doing poorly, don't be rude - if they asked where they failed, tell them - because, they may very well interview again in 6-months, and if they show a significant improvement, they may well get hired then." "Any technology they list on their resume is 'fair game' - they had better know it, and if you have direct experience in a niche technology that they list, grill them to see if they are being 'honest'" And - we were often paired with other technical interviewers, and everyone kept detailed notes. A single veto by any interviewer during any of the multiple phone sessions (and/or eventual in-person interviews) would end that stage of the process for that candidate. It worked well - I interviewed more than one person who didn't make the cut in the first round of tech screen calls, but 8-months later - they did - and ended-up being very valuable members of our group. However - there were definately other interviewers that were basically trying to trick the candidate at every step of the process - they were not some of our better team members and honestly, should not have been involved in interviewing.
  - seanp2k2 4y ago
explaingarlic 4y ago
I know I'm not qualified to speak on your decisions or life, and you probably know more about the situation but - why "not a snowball's chance in hell"? People change, they get given second chances. I wouldn't mind giving a company a second chance, especially after they probably had a real kick-in-the-nuts because of their approach to your interview, since it most likely wasn't that easy to find another qualified MeteorJS dev.
- ipaddr 4y ago
  They probably didn't want a qualified MeteorJS dev they wanted someone they could abuse. I wouldn't even interview there after hearing the story.
  - explaingarlic 4y ago
    Fair enough. Hard to imagine a $100,000/y punching bag, maybe it's just my privilege that I haven't seen one yet.
- maerF0x0 4y ago
  Sure, but I'm not going to be risking anything to restore rapport. Sometimes you have to believe a snake is a snake until they go through the motions to show you otherwise.
ianbutler 4y ago
Complete side note, I really wish Meteor took off more than it did I really enjoyed working with that framework went to the conference back in like 2014-2015 at the UN building in New York and felt really productive with it. I know it's still viable and I might use it for a personal project but wonder how businesses that use it are holding up.
- seanp2k2 4y ago
  The whole concept of "why the heck is everyone writing models twice in two different languages to build an app" has really stuck with me even though I've never used Meteor for something that wound up in production. I've seen some super wack things in prod like objects being modeled entirely differently front vs back-end and just a lot of reinventing of wheels. Great idea, I hope it catches on more broadly.
- cultofmetatron 4y ago
  if you don't mind trying languages other than js, might I suggest phoenix's liveview? Its past what meteor could ever accomplish here's the basic operating model. you have a controller but unlike a typical web controller, you are rally controlling the lifecycle for a long lived server process thats specific to the user in a session. you get callbacks for the startup where you can load data structures into the session. You also have functions that let you write frontend components from the backend similar to server side react. Here's where it gets interesting. The frontend maintains a long lived websocket connection. if you change a piece of data on the backend, the frontend will automatically update to reflect the changes. additionally, you can set event triggers in your html that trigger server side callbacks from which you can update that server side data. so you might be asking yourself, "big deal, meteor does that" The big deal of course is that you're using elixir, a mostly functional language with immutable data structures and concurrency abstractions that make node look amateur hour. Spawning thousands of one off short lived persistent sessions, one for each user, that each have a websocket connection is a trivial task for the beam virtual machine that phoenix runs on. Scaling the backend for this is trivial compared to ding it in node which is what meteor is doing. The underlying platform is just a better fit for what meteor is trying to solve. Every thread has its own heap of memory and is isolated from others. You have no such guarantee in meteor unless you dedicate an entire OS process for each user, a task that will be expensive and nontrivial) of course, its a backend process. so phoenix liveviews can also do a few other interesting things. need to upload an image or perform a background task? have your callback send its process id to the background worker and the background worker can send a message back to your session enabling you to update your session data. the frontend will automatically reflect the change. by comparison, tailing mongodb's oplog is child's play. If you can have your data source emit events on changes, you can plug it into elixir's pubsub system and accomplish the same reactivity in a live view. Oh yea, and fly.io already works with both meteor and live view's limitation of needing the physical machine to be close to the users for keeping the latency down.
kurupt213 4y ago
This is so weird, I work in a niche field and relatively few people have the skills my team has. We are normally looking for someone who has a skill we don’t have. We can teach the right candidate everything we know on the job.
- AdityaSanthosh 4y ago
  What field do you work in?
- k10er 4y ago
  I interviewed on a team like this - they just weren't able to meet compensation. It was refreshing to be interviewed like I would be a valued addition to their team with my unique skills rather than quizzed on the information.

andy_ppp 4y ago

I find the Dropbox story completely stupid too. You should never be failed in an interview for not knowing things you can trivially Google, in my opinion.

100721 4y ago
I disagree. Consider: You're hiring for a data science role, and the candidate doesn't know what an array is. Consider: You're hiring for a senior systems software development role, and the candidate doesn't know what an instruction is. etc.
- denton-scratch 4y ago
  Would you agree that what an instruction is depends on context?
  - ovebepari 4y ago
    Yes, ofc, he is applying for the "senior systems software development" role so there is our context.
- deleted 4y ago
  [deleted]
- squeaky-clean 4y ago
  I don't think knowing what an array is would be something you can trivially Google. Sure you can look up the set of words that make up the definition, but that's not knowing what it is. Something trivially google-able is like not knowing the syntax for generating permutations of a sequence in Python. But not knowing the idea of permutations would not be trivially google-able.
- deleted 4y ago
  [deleted]
- jonny_eh 4y ago
  It comes down to what one considers "fundamental knowledge" that one needs to do the job. If you claim to be a programmer, but don't know what an array is, you're probably not actually a programmer. But not knowing esoteric data structure that one may encounter once in their career is not really indicative of anything.
laluser 4y ago
Isn't this the case for most interviews? You could simply Google in almost all scenarios. Also, you can fail a single interview and still pass assuming all other interviews go well.
- andy_ppp 4y ago
  Using Google is the expected real world situation no? I think being able to figure something out you don't know is better than demonstrating something you know perfectly. You'll find out much more about someone if they can do this rather than asking them mundane syntax questions or if they pre-learned how to reverse a binary tree.
  - Froedlich 4y ago
    I've worked on several projects that used "Black Chamber" development. That is, local LAN only, with no access to the internet, and no internet-capable "personal electronic devices" or cellular phones permitted in the development area. You had whatever paper documentation you brought yourself, what was in your head, and whatever was in the /documents directory for that project. It's a different work mindset. I've since moved to a sysadmin position, running a closed network. When programmers decided they couldn't hack being cut off from the net, they'd quit. Dealing with vendors who signed a contract swearing their product didn't need internet access to install or function, when it won't even complete the install without internet access, is more awkward. Particularly when we call the lawyers in. Because that's why we tediously explained the while "no internet" thing in the contract. That they signed. No, not even for just a few minutes. And by the way, can you explain why your installer times out trying to contact servers in three different countries? Our network admin is curious...
    - k10er 4y ago
      I've worked in these environments before (not as a programmer though). It definitely tests your skill and you can identify who can solve problems on their own. Hopefully you have an additional network that you can do research on.
    - 4y ago
microtherion 4y ago
I once interviewed a candidate who (1) picked C to solve the programming problem they were given (some other languages were acceptable, and, actually, preferred) and (2) did not know how to dynamically allocate memory in that language. I did spot them the malloc() call (I certainly would not have wanted the interview to get bogged down for that), but yes, I did hold not knowing that against them in my evaluation.

lojack 4y ago

Interviewers tend to have one of two different mentalities... Some are trying to see you fail. They're looking for a reason to say "no". They tend to not be of any help on a problem, will often try to find ways to trick you. They also tend to have an ego problem -- you need to prove to them that you're worthy of joining the team. The other class of interviewers are those that want you to succeed. They will answer questions, and help clarify things. Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work. People that shut down when they get nervous tend to open up to these interviewers. They also tend to be the people that are more pleasant to work with.

jjkaczor 4y ago
>Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work So ~14 years ago - after about a year at Microsoft, I was encouraged to assist with interviewing new candidates. At that time, there was no official guide/rulebook for interviewing, but I was told unofficially; "We hire people with a solid technical base, who may not know EVERY thing at the time of interview, because we really want to hire on their future potential". "If a candidate is doing poorly, don't be rude - if they asked where they failed, tell them - because, they may very well interview again in 6-months, and if they show a significant improvement, they may well get hired then." "Any technology they list on their resume is 'fair game' - they had better know it, and if you have direct experience in a niche technology that they list, grill them to see if they are being 'honest'" And - we were often paired with other technical interviewers, and everyone kept detailed notes. A single veto by any interviewer during any of the multiple phone sessions (and/or eventual in-person interviews) would end that stage of the process for that candidate. It worked well - I interviewed more than one person who didn't make the cut in the first round of tech screen calls, but 8-months later - they did - and ended-up being very valuable members of our group. However - there were definately other interviewers that were basically trying to trick the candidate at every step of the process - they were not some of our better team members and honestly, should not have been involved in interviewing.
- seanp2k2 4y ago

explaingarlic 4y ago

I know I'm not qualified to speak on your decisions or life, and you probably know more about the situation but - why "not a snowball's chance in hell"? People change, they get given second chances. I wouldn't mind giving a company a second chance, especially after they probably had a real kick-in-the-nuts because of their approach to your interview, since it most likely wasn't that easy to find another qualified MeteorJS dev.

ipaddr 4y ago
They probably didn't want a qualified MeteorJS dev they wanted someone they could abuse. I wouldn't even interview there after hearing the story.
- explaingarlic 4y ago
  Fair enough. Hard to imagine a $100,000/y punching bag, maybe it's just my privilege that I haven't seen one yet.
maerF0x0 4y ago
Sure, but I'm not going to be risking anything to restore rapport. Sometimes you have to believe a snake is a snake until they go through the motions to show you otherwise.

ianbutler 4y ago

Complete side note, I really wish Meteor took off more than it did I really enjoyed working with that framework went to the conference back in like 2014-2015 at the UN building in New York and felt really productive with it. I know it's still viable and I might use it for a personal project but wonder how businesses that use it are holding up.

seanp2k2 4y ago
The whole concept of "why the heck is everyone writing models twice in two different languages to build an app" has really stuck with me even though I've never used Meteor for something that wound up in production. I've seen some super wack things in prod like objects being modeled entirely differently front vs back-end and just a lot of reinventing of wheels. Great idea, I hope it catches on more broadly.
cultofmetatron 4y ago
if you don't mind trying languages other than js, might I suggest phoenix's liveview? Its past what meteor could ever accomplish here's the basic operating model. you have a controller but unlike a typical web controller, you are rally controlling the lifecycle for a long lived server process thats specific to the user in a session. you get callbacks for the startup where you can load data structures into the session. You also have functions that let you write frontend components from the backend similar to server side react. Here's where it gets interesting. The frontend maintains a long lived websocket connection. if you change a piece of data on the backend, the frontend will automatically update to reflect the changes. additionally, you can set event triggers in your html that trigger server side callbacks from which you can update that server side data. so you might be asking yourself, "big deal, meteor does that" The big deal of course is that you're using elixir, a mostly functional language with immutable data structures and concurrency abstractions that make node look amateur hour. Spawning thousands of one off short lived persistent sessions, one for each user, that each have a websocket connection is a trivial task for the beam virtual machine that phoenix runs on. Scaling the backend for this is trivial compared to ding it in node which is what meteor is doing. The underlying platform is just a better fit for what meteor is trying to solve. Every thread has its own heap of memory and is isolated from others. You have no such guarantee in meteor unless you dedicate an entire OS process for each user, a task that will be expensive and nontrivial) of course, its a backend process. so phoenix liveviews can also do a few other interesting things. need to upload an image or perform a background task? have your callback send its process id to the background worker and the background worker can send a message back to your session enabling you to update your session data. the frontend will automatically reflect the change. by comparison, tailing mongodb's oplog is child's play. If you can have your data source emit events on changes, you can plug it into elixir's pubsub system and accomplish the same reactivity in a live view. Oh yea, and fly.io already works with both meteor and live view's limitation of needing the physical machine to be close to the users for keeping the latency down.

kurupt213 4y ago

This is so weird, I work in a niche field and relatively few people have the skills my team has. We are normally looking for someone who has a skill we don’t have. We can teach the right candidate everything we know on the job.

AdityaSanthosh 4y ago
What field do you work in?
k10er 4y ago
I interviewed on a team like this - they just weren't able to meet compensation. It was refreshing to be interviewed like I would be a valued addition to their team with my unique skills rather than quizzed on the information.