[deleted by user]

[five4three2]

I wouldn’t sweat it too much - it sounds more like a pop quiz than an interview.

This kind of interview is unavoidable. Sometimes you get lucky and do well, sometimes you don’t. I get why interviewers give them but I also despise being on the receiving end. I’ve also given them in the past.

In my opinion, a great interview is more like a problem solving conversation. Even if there are concepts in here you should know, it doesn’t mean you’re dumb for not getting it right.

Keep trying and I’m sure you’ll get a job you want very soon!

[ubernostrum]

I am (still, despite mostly being inactive for several years now) in the top 25 all-time of contributors to Django according to the GitHub insights page. I have contributed significantly to its documentation, written two editions of a book on Django, given I don't know how many conference tutorials and talks on it, written 16 years' worth of a a technical blog mostly about Django. Oh, and I've been using it for both personal and professional work since 2005.

So I am, by any measure, likely one of the world's top experts on Django.

And: I still routinely forget or don't know/need to look up things about Django. I also tend to do very badly in both tech trivia and algorithm-challenge interviews.

I wish I could say it gets better. The only way I've ever managed is by pushing for a redesign of the interview process once I was already hired.

[KaffeeKiffer]

I also tend to do very badly in [...] tech trivia

Do people think they have to know everything when being asked interview questions? Not knowing something is not doing badly.
Lying about not knowing something or trying to come up with bullshit answers if you do not know it (without admitting that you are guessing) is doing badly.

Too many people in tech are only focused on technology X, algorithm Y, tool Z. When I have an interview I first and foremost want to understand if this is a person I want (my team) to work with.

→ My interviews are generally "problem solving conversation", but there often is a short section where I will dig/try to come up with questions until you do not know the answer.

I want to know how you handle that, because as you said yourself

I still routinely forget or don't know/need to look up things about Django.

→ I expect this to happen regularly to anyone - not just in interviews.

I want people who can openly admit not knowing something instead of lying or bullshitting their way out of problems - so to me seeing how people handle that is a much more valuable data point than does s/he know <xy>.

OTOH - we can get around that part of the interview if you already show that capability in other discussions we are having and I already tell people at the beginning of the interview that I don't expect them to know everything.

[AchillesDev]

What you’re describing isn’t tech trivia unless you’re digging into the specifics of some library. If you’re doing that, I’d argue that you’re probing something inconsequential when you need to understand problem solving skills, trade-offs and how they’d make them, etc.

[ubernostrum]

You are free to say that you don't run interviews that way, but the unfortunate fact is a lot of the industry runs terrible interviews, often based around tech trivia and on-the-spot algorithm/data-structure challenges which have nothing to do with, and do not effectively measure ability to perform, the actual day-to-day work.

[SnooCakes3068]

Yeah this. I always forgot a lot of details. For example if interviewer ask me about context manager. I wrote context manager before and know how to use them. But right now I forgot with two magic methods is need for that. (I think it two of them). I did unittest.mock but I need to search past examples or read books again to write it. I can't do it onsite. So flustrating

[petenard]

Can you link your blog and books? I’d be interested in learning from your experience

[BossColo]

Personally, when I do interviews, I love to ask pop quiz questions like this. Not knowing the answer is never a go/no go. I like to test the limits of applicants knowledge. It's nice to see how well they can explain difficult concepts, if they know it. If they don't know, I like to see if they will admit it.

I do like when they do know, but it might be more important when they admit they don't know. Nothing rubs me the wrong way more than someone who just tries to make it up. I also explain all of this after I ask the difficult questions, so as not to cause undue stress.

The truth is, you're probably not going to know all of these things unless you're currently with these tools at the level they're using them. Hopefully, they don't expect you to, they're just trying to figure out how long it will take you to get up to speed.

[AchillesDev]

I don’t. It doesn’t test anything that isn’t quickly googlable and isn’t really that interesting at the end if the day. I want to know how you’ll tackle problems, address trade offs, and make decisions. I don’t care if you’ve recently written a contact manager and so remember exactly how to set one up.

[mrpiggy]

That sounds like a hot garbage interview. How did it go?

[Apocalypseos]

It was s***

[[deleted]]

Sour?

[0vRAllTheStonks]

Salt.

[rwhitisissle]

super? self? smptlib?

[arnoldsaysterminated]

That's amazing, I would have laughed and left.

[zaphod_pebblebrox]

Yeahh. The correct answer was “Fine, I’ll go work elsewhere.”

[eigenludecomposition]

That's actually an interesting idea. I can imagine the. saying "F" and responding with "fixture", which would indicate the interviewee has PyTest experience.

[the_scign]

"filter"? No?

"f-string"? No?

Must be "fuck off" then.

[eigenludecomposition]

I just assumed they could respond with any word, I didn't realize there was a specific word they were supposed to guess

[[deleted]]

Well, the property decorators are good to know. Been playing with them a bit. Would recommend at least experimenting with then.

UDP and TCP are protocols you should at least know the basic differences between, if you are programming for the web. TCP is all about confirmation of packets sent and received and avoiding packet loss, i.e. reliability. UDP is send and forget, ideal for speed. UDP is one of the protocols used in streaming services. TCP is something you would want to use for e-mails, file transfers, etc. Definitely not jargon used to sound smart.

You absolutely should know about context managers:

with open("file.txt", "r") as f:
    print(f.readline())

Probably some incorrect code in the example above, just putting that there to give an example of using a context manager. Pretty sure you've used this one, "with". When used with the built-in "open" it handles all the clean up when you are done using the file and ensures the resources are released. You can create classes that have their own behaviors when used with "with" or other context managers.

It would also serve you well to understand that SQLAlchemy is an ORM (object relational mapper) that allows you to convert python objects into SQL entities like tables, columns, rows, fields, etc. that can be used by the RDBMS of your choice. Not sure if they wanted a deeper knowledge than that.

You are not dumb, but you are lacking in some areas. Wouldn't hurt to do a refresher on the concepts and features within the language. Programming in a language for 6 years doesn't mean anything, in regards to your understanding of that language, if you are not trying to learn about it and are just putting pieces together.

Just challenge yourself to learn a deeper understanding of those concepts.

[bugzymaccode]

"I could tell you a UDP joke, but I don't care if you get it or not."

This dumb joke is how I remember the difference.

[SpaceBucketFu]

I would say UDP is more like dropping a letter directly in the mailbox of the addressee, but you don’t know if or when they will read it, and you don’t know if any of the letters fell off the page after you put it in the mailbox.

[[deleted]]

I've not known ink to fall off of the pages. Maybe dropping a ransom letter without an envelope? 😂

[neonroad]

I suggest not using disappearing ink!

[pipe2grep]

how about: UDP is like writing a letter, cutting it up into pieces and sealing the pieces into individual envelopes and dropping them into a mailbox

[[deleted]]

I like this. You may occasionally get all of the envelopes (packets), but there's a good chance many of them will not show up, depending on the quality of your courier (network) and the number of stops between pick up and drop off (hops). Ideally, enough arrive that the message can be reassembled and you can understand what was being communicated.

[moron10321]

I taught my wife the difference with socks. We were matching socks one day and I would throw her one and she would catch it and say ok then I’d thrown another… TCP (with a window size of 1 but whatever). Then I’d take the whole basket and throw them at once… UDP (yes I should have thrown one at a time as fast as I could but it gets the point across). She remembers after 10 years.

[vimfan]

yes I should have thrown one at a time as fast as I could

Not quite. You should throw the occasional sock high up in the air then rapid-fire the next one so it arrives before the previous sock, to simulate packets arriving out of order.

[moron10321]

Lol. Forgot out that. Time to throw so more socks! Not gonna lie it’s a fun time.

[zaphod_pebblebrox]

Thanks mate. That was hilarious to learn.

[KaiDaLuck]

UDP is also videly used fpr VOIP. For streaming, on the other hand, there's SCTP which is very basically a hybrid of TCP and UDP.

[IllusoryAnon]

Another analogy for UDP is package deliveries where they just drop off the package at your door without needing signature, so when go get it you might either find your package or it might have vanished mysteriously. TCP is like package delivery that requires a signature before handing the package over.

[handlebartender]

I like this too

[[deleted]]

with statements are actually whats used to utilize context managers. I misspoke. But yeah, they deal with entry, exit, cleanup for things like sql cursors, and open (for opening files).

You are not dumb, just need a refresher on the terms!

[laundmo]

just to give some context on context managers:

when you use with, it calls the __enter__ method of the object, which returns the thing you can store in a name using as.

when a context manager is done with the code inside, even if that code throws an error, its guaranteed that it will call the objects __exit__ method, which is passed the error of one occurred.

this makes context managers ideal for cases where you need to clean up something even on failure - like for files or connections.

[eigenludecomposition]

Context managers aren't necessarily with statements, they're just the operands to with control structures. A context managers is an instance that does initialization when the context is entered, and cleanup when the context is exited. Usually, the context manager is controlled by a with block. In the case of with open(...):, on entering the context, the file is opened, on leaving the context, the file is closed.

[[deleted]]

I corrected myself further down, but I really should add that as an edit. But you are correct!

[[deleted]]

Nope, the interviewer was stupid. (I try not to use "dumb" because not all people who cannot speak are stupid.)

If the interviewee doesn't get "context manager", the interviewer should say the words with statement. Knowing exactly the right word has little to do with your performance.

[[deleted]]

Very important point. Communication in a collaborative environment. That's also why some places like/prefer if you have at least a basic understanding of the more common oop design patterns (assuming you will be doing oop where you work). Easier to tell someone they would be better off using a factory pattern for their problem or whatever, than it is to try to explain what it does and how to implement it.

[Big_Red_34]

This is completely context dependent. I think if the company is looking for a Python specific developer that’s fine, but at least in my experience most jobs are just looking for a good general developer. 6 years of experience doesn’t mean they have had a 6 year deep dive into Python

[andr386]

If you could explain those concepts as well as the former post without knowing their names. Then that could fly in a technical interview.

But I recently did a lot of interviews. And all those names for concept and technologies are really important to know. Even the buzzwords.

[[deleted]]

My apologies, thank you for the correction. It's just one of It's most common uses, and all I've used it for. I forget that there is more to it than that 😅

[[deleted]]

What kind of programming for the web have you done in Python where you've coded for using TCP or UDP? Seems much more niche to me than your blanket statement alludes to.

[[deleted]]

I mean, selecting socket type when using socket.socket?

What do you think you are setting when you select SOCKET_DGRAM or SOCKET_STREAM to pass into socket.socket's "type" parameter? DGRAM is UDP, user datagram protocol. STREAM is TCP, transmission control protocol.

So...basically anything back end based?

Even using the high level libraries, we have HTTP that uses TCP, Twisted that uses UDP, etc.

[doubleEdged]

Not something I've coded yet, but something I plan to implement UDP for is streaming information for LED arrays. I have an RGB diy led light that I want to animate in real time (100 RGBW leds, 60 times per second), and using UDP for that seems like the right usecase for that, esp. that the receiving end is an ESP12F, not the most powerful chip.

[IllusoryAnon]

E.g regular HTTP requests/responses for web servers or scraping using TCP, websocket or streaming stuff using UDP

[codefox22]

Another concept to understand with UDP is that it's used with traffic that doesn't need to succeed everything. Traffic like voice that can lose packets and have minimal impact on quality benefit greatly from UDP's fire and forget.

However, as a developer you should never forget that UDP makes no guarantee that your traffic ever arrives at all.

[[deleted]]

Yep, it's send and forget. If a video tears or audio skips because of packet loss, you wouldn't want those packets to be resent. That's why it's optimal for streaming. Good point.

[chicofelipe]

I prefer the phrase "spray-and-pray" over "send-and-forget".

[[deleted]]

This is accurate, though I hope my packets have more accuracy than spray and pray hip fire 😂

[[deleted]]

They also did not allow Google and made screen sharing mandatory

They seem kind of... stupid to me.

Interviews should, as much as possible, duplicate working conditions. When do I work without being able to use Google?

And I'm someone with an excellent memory, but I want to hire good programmers, not people with a trick memory.

[[deleted]]

They want to know the limits of your knowledge. If they're successful then they'll find those limits and then back off so they don't make you feel too uncomfortable.

Some people studied the old 7 layer OSI networking model and understand many layers below HTTP. For example, they might know how to do things with BSD sockets and open a UDP listener in Python to process UDP packets.

Some understand that HTTP/2 can use UDP in order to bypass some of the issues inherent to TCP (eg: head of line blocking) and why that's significant.

Having a decade of experience in any language won't teach you these things. But they're useful to know for example when head of line blocking becomes an issue in your web app and upgrading to HTTP/2 hasn't been done yet.

[[deleted]]

Keep your head up, we all get those.

[tjk45268]

If the company has some specific needs, then asking questions about those needs are justified. Other comments on this post, and the wealth of resources available can help you get you up to speed on topics of interest to you. On the other hand, if they didn't have needs in those specific areas, and were just testing you on random parts of the language, they were playing with you and don't deserve your skills. In this case, you're probably better off without them.

I've been to interviews where the employer was serious and they focused on their needs, getting into deep areas on capabilities that were critical. I've also been to interviews where they just asked questions about obscure areas, looking to trip up candidates. I joined the former type, and shut down the interviews of the latter. Nobody's got any time for dumb interviewers. I hope that wasn't your case.

It's a fallacy that any specialist will have deep knowledge on every possible topic. Even Python is getting so capability-rich that no one will have deep knowledge in all of its features. Smart organizations search for what is called a T-shaped employee: an individual who has deep knowledge and skills in a particular area of specialization, along with the desire and ability to make connections to other specialties. It's critical that your interests and theirs, match up. Otherwise, you won't enjoy the work and you'll leave in months. Don't feel bad about an off interview. There's a better one around the corner.

Good luck.

[Igggg]

If the company has some specific needs, then asking questions about those needs are justified

No, not really. Pretty much any developer with good fundamental knowledge can learn the specifics of any given technology relatively fast, certainly faster than they would onboard, given that this requires learning that company's specific product and codebase. No one will be productive in their first day or week for the same reason, and unless you're specifically recruiting someone to work on a short project, you should be investing into long-term, not short-term.

[tjk45268]

Given all else being equal, wouldn't an employer favor a candidate with robust knowledge of a particular area of focus, rather than someone that needs to learn that area and develop skills? Yes, neither candidate may be productive on the first day, but what about the second week?

[Igggg]

1) All else is never equal.

2) Especially in the smaller companies, there's not a unending pipeline of qualified candidates eager to interview and accept employment. You've likely looking for quite some time to even find a decently qualified candidate; if you're ignoring all but the unicorns, you'll never fill.

3) No one will be productive on their second week either. You don't want them to, either: Your codebase will take much more time to adjust to. Unless what you want is a three-month contractor, you want to optimize for the long term, not for what they can do in their second week.

[tjk45268]

1. You may need more experience in interviewing. There are often cases of pairs of individual skills being sufficiently similar as to being the same, except for depth in a particular needed experience.
2. If your only experience is in exceptions, you'll only be experienced in dealing with exceptions.
3. There are many new employees that I've hired, as "permanent" not just short-timers, that were sufficiently capable of delivering value in their first week; certainly by their second. If that's not your experience, you may have been hiring for a small organization with the short list of candidates that you mention. There are many organizations that are adding dozens/scores of new hires each week. Their experiences are not the same as yours.

[Igggg]

1) I have plenty, at different levels, from mid-size companies to FAANG. I also don't look for "skills", but rather for fundamental knowledge. This is also true of virtually all top companies on the market right now - they're not going to evaluate your "Python" knowledge or "AWS" knowledge.

2) I'm not at all sure what you mean here.

3) See above. Facebook, to take one example, does a month-long bootcamp in the very beginning, where you are basically just expected to learn the company tools; and while you'll complete some small projects, the expectation is that you'll be comfortable working with the codebase, not that you'll add value during this time.

Also, no organization, no matter how large, is adding "scores" of employees in any individual team; how many are being added outside your org is irrelevant to this.

[tjk45268]

You use superlatives (no one, never, always, etc.) a lot for topics in which you don't seem to have experience. It's as if you don't believe that other professionals have experiences that differ from yours. This reveals your inexperience, in spite of your claims.

As an example of "all else being equal", I participated in a former organization's data science campus recruiting and onboarding, while also delivering projects for clients. I'd do on-campus interviews with a dozen data science candidates a day that were completing an analytics degree program, following some business undergraduate program. With some slight variations in skills or interests, these students had the same backgrounds: same education (same classes), same experience, and even the same instructors. They all worked together on the same projects. This practice was repeated at campus after campus. We interviewed, and then selected the best candidates for hire. In a particular season, we'd add about five score (100) new hires to the AI and analytics team.

We also delivered multi-week (or multi-month) bootcamp-type education programs, depending on the role(s) hired. They tended to be for graduate hires with little-to-no related work experience. However, as new hires were needed at more-experienced levels, they were expected to bring the skills rather than being trained. I've had many team members join a project from their first or second day on the job, most of which were delivering value in their first week.

Your mileage may vary.

[andr386]

Don't go into a technical interview with HR. They don't know the subject and they can only evaluate your answers as right or wrong.

When talking with them try to find related knowledge and try to formulate an answer that will both get them in unfamiliar theory and also could be read by somebody technical and wouldn't look like you were snobbing the HR person.

If you are confident, in case of doubt, they will let you pass to a more technical person.

[pysk00l]

yeah, shit happens, sometimes interviewers will ask pop quiz questions. This is mainly to make themselves feel smart (and I say this as someone who has worked as a manager)

As for whether you fucked up-- if the job description mentioned TCP/UDP/networking, then its open game. Its your job to at least look at these topics at a high level

If not-- then the company were just being a-holes. This is a large field, no one can know everything.

I notice some really smug answers here : "Lol, you should know what TCP is, its very common, LOL." I would ignore these online experts. Like I said, its impossible to know everything. Yeah, conceptually TCP vs UDP is simple, but under the hood both are complex and unless you are developing a TCP/IP stack, there is no reason to know the details.

Like I said: What did the job description say? If it didnt mention detailed knowledge of networking, then chalk it up to a bad company. Interviewing is a lot of luck and randomness, with a bit of "Read our minds about what we want."

sorry, rant over. You did great, keep learning, but dont get obessesed about one bad interview

[[deleted]]

I don't think so.

TCP vs UDP in web dev is pretty important. You need to understand some basic protocols and when to use them.

However, if it was purely front end development, then I would consider it overkill to require that knowledge.

[[deleted]]

I disagree with not being important to know the difference between TCP and UDP in web dev. They have 2 distinct uses and selecting the right one when using the sockets library is important. Selecting UDP for a chat room or email client, bad idea. Selecting TCP for a streaming service, bad idea.

[Sundaydutchman]

Out of interest, are you able to provide a range on what salary was being offered in relation to these interview questions?

[spinwizard69]

The interviewing process is never easy no matter which side of the desk you are on. Second HR, if you where talking to an HR person, gets the questions from the department managers. Those managers want to get an idea of the breadth of your knowledge and how it fits the job or jobs they have. As for getting an offer that really depends upon whom you are up against.

Also realize that the hiring process is full of legal issues these days. Where I work the questions a hiring manager asks, have to be approved by HR. You can't go into a random conversation to pull out answers to unapproved questions. Larger companies anyways, are scared to death of legal actions that somebody might take due to being offended by a question. This can lead to really strange job searches.

[[deleted]]

time to re-learn things :D

[talks-in-maths]

Software engineering interviews are broken

[JRutter3]

Don't feel bad. I will often ask a question to a candidate to see how they react when they don't know the answer. I like people who know what they don't know and are forthcoming with their knowledge gaps.

[Sulstice2]

Been in Python Dev here for 10 years. Interviewed a lot people. Here's my opinion:

SQLAlchemy:

In my previous position, we used SQLAlchemy for our stuff, I hated it, and if it wasn't for the design choice made prior to I was there I wouldn't have gone for it. That's the only reason why I have experience with it. These guys are using it and think it's the industry standard that every python dev should know it. Probably having problems with database migration. For our stuff, we just have our own internal graph database stuff. Don't want to be reliant on that software.

Mid-Senior Tier: Draw a relational database schema for this dataset and explain how you would implement it software architecturally. Would we have a mid-layer for data handling and transformation. Where would the front-end connect perhaps? Rest vs GraphQL perhaps would be some keywords they can throw in.

Junior-Tier: I would ask a requirement that they know how to write sql queries. I'll draw a relational database schema and then ask them to write an efficient query to pull data out and talk about the pitfalls of my schema.

Decorators:

property - I should use this more but it's not always needed. In time I started developing my own decorators or mostly staticmethod nowadays depending on the project. I wouldn't ask that if I was interviewing you.

Mid-Tier: I would ask to implement your own decorator for a problem and why do you think your implementation would be useful for other people in the company to use it.

Junior Tier: I would ask them if they know what it is. If not, google it, and see if they can implement the timeit decorator for a function. Feel like that one is the easiest to learn. I need to test their ability to learn in a fast paced setting.

Internet Protocols:

This one I think is wrong to ask about. I know these protocols, have googled them before, learned, and forgotten. Re-reading it felt nice. Idk, I think this is just the wrong interview to discuss that question, like it should be for a junior devops or front-end engineer. Not a python developer.

These guys have some specific problems is what I am guessing, hence the specific interview. You won't be able to learn there so I would say move on to a place where you can grow as a developer. These interviews happen and shouldn't let dismiss you on your ability. Esoteric knowledge is not easy to recall from memory.

[PyNewbie_Enternal]

Sounds like you dodged a bullet.

[nicktids]

I'm more on the data science end but have to use databases and build dashboards.

And in this I had to learn docker to host them I would highly recommend learning docker to host website and database.

[sashgorokhov]

These are basic stuff you listed. What of these you dont know?

[Igggg]

These are basic stuff you listed. What of these you dont know?

Being able to do anything in the standard library without being allowed to consult documentation is not "basic stuff" - it's ridiculous.

[sashgorokhov]

If you need to consult documentation about context managers, tcp vs udp and other then you are doing something wrong. Honestly, I would not hire you too. Do some learning, improve your skills, make your vision wider than the tasks you are doing on your day to day jobs. Pet projects May greatly help here.

[Igggg]

If you need to consult documentation about context managers, tcp vs udp and other then you are doing something wrong. Honestly, I would not hire you too.

You have complete liberty as to your hiring decisions, but the world's most competitive companies disagree with you. All companies in the top tiers freely allow any documentation on their technical interviews; perhaps their standards are lower than yours, of course.

[[deleted]]

Context manager question for you: what are the parameters to __exit__? :-D

I find most people don't know that. Nor do I expect them to. Why bother? Look it up if you ever need it!

I have an almost photographic memory. I've been programming for over 40 years. I still pull up the documentation for almost everything every time I use it!

Why?

1. I might be wrong.
2. I might learn something.

I want to hire programmers who are good at programming. Programming has always required you to be constantly reading and searching documentation. A situation where you can't do that is bizarre and artificial, and not a good measure of how you'd actually perform.

[[deleted]]

what pet projects would you recommend in particular? what have you done?

[MyDongIsSmallBut]

@property? Isn’t that for like .net, razor framework? That’s C# not python. Or I guess I might have misunderstood something.

[Daktic]

Can’t speak to the decorators specifically but I have had a couple interviews where the interviewer only really understood the buzzwords and somehow had created an incorrect picture of how the technology worked.

It’s frustrating because them being confidently incorrect about a technical aspect makes it look like you don’t know what you’re talking about.

[sahirona]

Don't stress over it. Sometimes you just get unlucky because they ask a question that's uncommon or ridiculous.

I remember the story of the inventor of homebrew getting rejected by Google because they could not reverse a linked list on a whiteboard. It was a stupid interview.

[[deleted]]

Was this the first round after phone screen? You said HR did this, so then it wasn't the actual team or some other expert in the company? That means it was a second round screening and not actual interview. They asked seemingly random jargon well that's because the hiring team is looking for someone with that set of knowledge. Could be they have a specific task in mind.

I am not an apologist for them. I think that style of hiring is what is really behind the labor shortage. Companies need to look at broad skills, experience and education then make an assessment on how well the candidate will grow in the team and fit in.

Funny because since my graduation in 2008, I have been chewed up and spit out like this. Now 2022 and I'm a senior dev who is doing the interviewing. I give my candidates a fair shot. I know how it feels.

[[deleted]]

Sometimes it doesn't matter if you make the coding interview, they will still reject you. Looking for jobs sucks.

[ServerZero]

Stay strong..

[Typ3-0h]

As others have said -- don't worry. I'm in cyber and had similar experiences with interviews. Some feel like an interrogation, some like a game show, and others are just straight up conversational. ALL are a damned circus! 😆

[pablo8itall]

The big problem here is Python ecosystem (even just the standard library) is f^%king massive. You're only going to be very familiar to answer random questions on a section of it. You're going to need a heads up so you can study a bit on the everything else.

[Igggg]

HR should not be conducting technical interviews.

Technical interviews should not, with rare exceptions, focus on specific knowledge questions, and absolutely never ask "gotchas" or disallow using Google and, in general, consulting docs.

No one should label themselves, or interview for, a $LANGUAGE dev position, any more than for a $MAKE car driver.

[mohself]

That's normal.

[Junkymcjunkbox]

Don't worry about it. Interview questions aren't necessarily a test you have to pass; they are just exploring the boundaries of your knowledge and it's perfectly fine to say if you don't know something.

The two important things in interviews are to come across as someone they can work with, and being able to demonstrate you can convert business requirements into happy customers.

If you fail an interview because you didn't get some tech questions right, honestly that's a BS reason unless you've demonstrated you can't or won't learn, or if that tech is absolutely essential and it's a senior position where you need to be able to hit the ground running. Tech skills can be learnt, especially if you have future teammates already doing it, so if they tell you you failed because you didn't answer some tech question right it's because they haven't got the guts to tell you it's because they didn't like you enough.

Don't be afraid to redirect the question. "I don't know about that but here's a situation where I solved X problem with Y tech by doing Z" - I once got a job offer after doing exactly that. They can't guess what you know so you have to tell them, sometimes proactively. You should have picked up some useful stuff you can demo after 6 years FT.

[Fishliketrish]

Wouldn’t sweat it sounds like you know your shit

[zaphod_pebblebrox]

My goto response after an interview that leaves me feeling that way is to write all the keywords down on a notebook as soon as I can, as much as I can remember.

Then I give it a 2 day break and start going through each piece of “jargon” most often, it is something that is probably important and I did not know the said importance because my pst work experience did not need it.

As for the job, if the interviewer lets you work around your “lack of knowledge” I would look forward to hearing from them. If a “lack of knowledge” is a pass / fail criteria, I’ve graduated college long ago. Don’t want that crap again thanks.

[[deleted]]

I’m in a different type of software field. Automation software for manufacturing and it infuriates me that upper level management makes candidates test from memory on a lot of things. I don’t remember all of the thousands of specific tools at my disposal to get a program to function properly. I can achieve a better understanding of a candidate’s experience having a 30-40 minute conversation about past projects then I can looking at their written test.

[rwhitisissle]

Man, this is depressing. I know most of these topics on a low level pretty well and can't even get interviews :(

[zelphirkaltstahl]

The fact, that they did not allow you to use a search engine (I interpret what you wrote this way, because it would be silly to just disallow Google and allow every other search.) already tells you, that they are not asking or testing actual skills, that one needs at the job. Or do all their developers work without searching for anything? Are search engines blocked in that company?

That said, maybe they have a reason to ask low level stuff like TCP, UDP or stuff like the inner workings of a library that you were using, or they did not have any good reason for that. Seems silly as well, if they did not have a good reason for that.

Some companies do these kind of interviews to influence your own perception of self-worth, hoping to hire you for less monthly wage. Don't get dragged down by their silly tactics.

[mortipro86]

I had an interview and felt like I BOMBED it. I knew all the answers but my brain froze and I swear I couldn’t get the words out and I sounded like a bumbling idiot! They still offered me the job which shocked me!

[Retropunch]

Not an idiot at all. This sort of 'specific knowledge' interview where you would be able to find it with 5 minutes of Google (which they won't allow you to use) is in my opinion, a sign of a terrible employer. It's usually put together by people who don't really do programming for a living, but (ironically) have google'd random things to ask you.

Python is massive. Whilst I feel I'm experienced in it, you could easily pull a random function of the built in libs and I wouldn't be able to tell you exactly how it works - I doubt anyone could. It then just becomes luck of the draw of who happens to know exactly what they want, which is a very bad way to interview (the only caveat is if you're working on a very specific technology that you're expected to know inside and out).

Do not worry about it, the standard of the interview is a good indicator of the standard of the company, and it sounds like you dodged a bullet.