CSCareerQuestions

Don't be too hard on yourself. A great interview explores the limits of your experience with the interviewer. That ideally includes some questions you simply cannot answer.

I have, very rarely, interviewed someone who had every answer I was looking for. In that case, she went on to build the entire team. But usually I don't need someone with all the answers, but just someone with enough experience to do the job while growing into it.

So sometimes missing some questions still lands you the job, and just informs my training plan for after I hire you. It's hard to tell right after the interview which way it went.

And sadly, I don't know for sure, until I've interviewed every candidate, so I rarely can give meaningful feedback right after the interview.

Also, if you were honest and communicated clearly, you likely grew your professional network, whether you get the job or not.

All that to say - you might not have bombed, after all.

Sorry to hear your interview bombed. That sucks, buddy. It happens to all of us at some point.

At a career fair at college a long long time ago, I was recruited by the local government for what was described as a networking job “plus some other stuff” related to networking. I hated coding but loved networking work so I agreed to apply. There were some basic screening questions that were low level, easy stuff. I got an interview.

The interview was conducted by two electricians and a project manager. None of them knew what the fuck they were talking about. I’ll never forget one of the questions was whether a device can be on multiple networks. I said sure, just dual home it. They told me I was wrong, a device cannot be on two networks. I was dumbfounded. They were dead wrong. It was clear really fast that these were electricians pretending to be IT guys, not IT guys working in an electrical field.

For the coding portion of the interview, they put me in front of a software I’d never heard of before and told me to code some shit then left the room. It was all in ladder logic. I had no idea what the fuck that was. I jumped into the programs FAQ and realized you could write in JavaScript, so that’s what I did. The autocomplete really helped. I did that and walked out with a program that worked well enough. They told me they didn’t know what I had done but it was wrong. None of them could read or write real code. I had seen in the documentation that you could output the code in ladder, so with them standing there I converted it and then showed them the ladder logic. They looked at me like I was a fucking alien.

They thanked me for my time. I knew I wasn’t getting the job and was thanking my lucky stars because the people running the place didn’t have a fully functioning brain between the three of them.

Anyway, my internship gig at another place fell thru soon after due to money troubles. I had put all my eggs in that basket and was well and truly fucked. A couple months later I got a call from the city offering me the job. I asked later why they hired me and they said I was the only one that could output any code at all during the interview process. They thought I was an idiot. I thought they were too, but I took the job cause I had to.

Maybe the worst job I ever had. I was right. They were idiots.

And that’s how I became a PLC programmer.

Oh yeah. One time I interviewed at this accounting firm and mentioned that I was fairly familiar with SQL, which was a true statement. The VP on the call proceeds to start grilling me about really in depth performance tuning stuff and then acts all flustered when I don't have the answers. I said "fairly familiar" not "10 years as a database admin".

Then they went radio silence for a year, after which they called and asked if I was still looking for a job. Even if I were, I wouldn't have gone to work for them.

Technical questions can give you a feel for how familiar a candidate is with a given tech stack. But then there are some people who just get off on making others feel inferior.

Interviewing is a skill in itself, and one that you can practice. I would encourage you to apply for all sorts of positions you don't actually want just for the experience.

Sometimes, these questions aren't meant to get an accurate answer. They're meant to see how you approach an issue, especially under pressure. I've seen people print out multiple pages of indecipherable code and ask a candidate "what does this code do?". Of course, if you can answer it correctly you're hired, but no one realistically can. But they can watch how you break down code you've never seen, in an unfamiliar environment, to piece it together.

Sometimes the questions are meant to call a bluff, or reveal a know-it-all. In a good interview, you'll flat out say "I have no idea" a couple of times. But you'll follow it up with details on how you would handle it. For instance, I've never heard of a dict in Python until now, so I googled it. It seems they're the same as key-value pairs that are common in other languages.

They will never find a perfect candidate. The question in their minds is whether you're close enough and can be trained.

Sorry to hear that. At low level there is a need to know your baseline, so dumb questions like that are needed, if someone can't answer basic questions and some gotcha/well-known questions there is little sense to continue. To be honest, in my experience new internal positions/promotions are filled before interview.

Sounds to me like the failure wasn't yours, but the interviewer's; you came prepared for questions relevant to the role, and they went all out-of-pocket on you.

Like if you show up for a tech job and they start going "paint me a word picture… tell me about your personal philosophy…"

Like you said, if they just googled some BS to ask you, or followed the corp-approved "starting questions", that's their fault.

Maybe you could reach out to them (or HR?)and go "hey, I was surprised by some of the interview questions, but I really do think I'm a strong match - can we get together and come to an understanding on the relevance of those questions?"

Sorry to hear. That happens from time to time. The feeling sucks. You'll do better next time

the difference between list and dict is basically ordered list vs key value pair. the advantage of dict is that key value pair, finding or changing something (using its key) is big O of (1). its generally important for accessing data in a large pool of data quickly (as O(1) < O(n)

its one of things where its a fundamental concept question check that one would usually learn in school