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
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.
>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.
"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'"
Such a strange stance for MS to take (IMHO). I've got 20+ years experience in lots of different languages and different technologies. I've been looking for a new job and have been brushing up on skills for interviewing. I just don't think it's possible for me to be ready to be grilled by a current expert on 15+ languages that I've shipped high quality, production code. The flip side is to only list the three I can take a grilling on today on my resume? It seems like a pretty short sighted approach. Maybe they have moved on in this stance?
Grilling may not be the best word there, but if you say you worked with language X, I think it makes sense to give you some questions about it to gauge how good you are with it. Some people stuff the resume by mentioning every language that they did for a toy project once in college, and then we don't want them to be put in charge of the project which requires deep knowledge of the same language. Better to find it out in advance. That doesn't necessary means that candidate will fail and not be hired - just maybe not for the project that requires the knowledge they don't have.
Having done plenty of interviews, it's surprising how many candidates list every technology they may have touched for the briefest of moments. For me, "grilling" someone on something like a programming language is about determining if they've _really_ used it or not.
If a candidate lists multiple languages on their resume, I'll often ask them to do a compare and contrast -- what do they think are the strengths and weaknesses of the languages? What did you use language X for? Do you think language Y would have been better/worse/same to attack the same problem?
I'm not looking to trip them up, just find out if their resume is an accurate reflection of their experience.
"I used it so I wouldn't need to rewrite the 300 proprietary internal libraries and dependencies our company also paid to write and maintain in that language" is probably a valid answer for many BigCo employees.
I just had an interview with MS, they seem to have a far better approach these days.
I was surprised that they approached me because the team works primarily in C# and Go, and I've been doing JVM languages mainly, and only a small amount of Go, but the interviewer emphasised that they want people who can learn and enjoy learning.
They then asked me to choose a language I know well and describe a strength and weakness of it.
Interviews exist in this weird space disconnected from the reality of the work and being judged by those closest to the work. Not many real on-the-job situations would require someone, for example, to be able to recall the protocol number for a given protocol without looking it up, yet that's one of the questions that a particular very famous tech company has their recruiters ask, and you get auto-rejected for not knowing. It's unfortunate when a place becomes so large and so desirable that they'd rather force people to try multiple times to get through an arbitrary obstacle course and succeed on some combination of chance and skill vs attempting to more honestly assess if a given candidate could actually succeed in the role they're hiring for.
I hate 'trivia' interviews with 'gotcha' questions dealing with experiences their team may have recently dealt with (and probably took weeks to identify/resolve).
I would say the port/protocol memorization may be required depending on what job you are interviewing for. If its for a tech support job, maybe the ports/protocol question is pointless.
I have no respect for such people. Not because of their lack of "niceness", but because that kind of behaviour betrays a lack of technical confidence.
That remark isn't just about interviewers; it applies to all colleagues. More generally, I tend to respect people who are smart enough to know what they don't know, and honest enough to admit it.
> behaviour betrays a lack of technical confidence.
Yes agreed. I've seen this in interviewing and in teaching. People who are insecure make it about how smart they are, people who are confident make it about helping others.
In a former role, I got the opportunity to be on the interviewer side of the table.
I considered it a privilege to have the potential to influence progress in someone else's career.
I am very much in the latter category of wanting to see folks succeed.
We had one candidate that didn't have experience in the particular technology we were interviewing for, but I could tell he was highly intelligent, just very nervous.
I asked him questions on another complex technology that he'd listed on his resume, to try and draw out some of his thinking on his problem solving skills.
He did great.
I suggested to him that he should come to us with questions, and interview us as much as we were interviewing him. I wanted to see him get the job.
He didn't… at first.
The others on the panel didn't give him their vote. We'd picked someone else that ended up flaking out.
I went back and tried to make the case that we should extend him an offer.
They ended up doing so… dude was an absolute ROCKSTAR.
Please be the one that wants people to succeed. Interviewing is hard, people.
> 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.
That's how I go about it. Even unprepared candidates can return someday with more experience/knowledge, or apply to a different position where they can succeed - or letting their friends/acquaintances know about the role.
Also, as we can see in this post, a bad interview experience can really taint a company's image, which can to some degree prevent people from applying
Nonsense. Misleading people is hardly ever the right or long term beneficial approach. If the candidate is insufficiently experienced, skilled or prepared then it's not wrong to let them know (they might actually appreciate to learn why they don't get the job). This doesn't have to be done in an impolite way though.
a) I think as interviews as auditions rather than exams.
b) I try to find someone's edges, so that the hiring manager has better information. In other words, if I were to give a candidate full marks, I've probably failed as interviewer.
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.
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.
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.
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.
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.
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.
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...
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.
When I interview a candidate, if they don't know the answer but say "they could Google it" I would then ask them what they would Google.
If what they Google would provide them the correct answer, I'm OK with someone who knows how and when to Google something. Those that don't think about researching themselves usually end up asking me in-person. And I usually then ask them if they have done any research themselves.
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.
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.
that largely depends on your machine's specs but the limit is much higher that you are going to get in go, python or ruby (yes I know action cable uses go)
but to get a better handle, here's some interesting reading
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.
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.
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.
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.
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