"I have a proven track record of building and leading amazing engineering teams."
"Okay. What's the difference between a character and a string?"
*crickets*
We all have our specialities, but jesus ¢@&#ing christ: if you're interviewing for an engineering role, of any sort, you should be able to answer basic questions.
I interviewed an ex-FAANG (developer) currently working as a software executive for a director role at a previous company. This person included 5 years-ish of Haskell experience on their resume. I don't know Haskell at all, but am aware of the language and its design principles, so I figured a lot of my technical questions would be pretty easy for him
Boy was I wrong. My first question was "Name the most common data structures you use day to day". He stayed silent for a bit and then said "What, do you want me to just list them?" I said yes. After some more silence he said he couldn't recall any. The fact that he said "list" was particularly ironic.
I kind of gave up on expecting used-to-be software developers to have retained a single bit of knowledge from their time as a dev after they've moved on to "leadership" or "management". I believe it's important for technical leadership
to understand technical problems and their solutions in broad strokes, but it seems I'm mostly in the minority in the real world. That interview (and trying to hire for that role) really showed me how little engineering leaders remember about software.
I write code every day and I still had to ponder your question for quite a while before I could think of a data structure I use regularly by name.
It is not exactly useful knowledge to keep top of mind. It is not like you need to look up how to use daily data structures. I had an easier time remembering the names of data structures I almost never use, or even have never used, as retaining their names actually has some usefulness.
In an interview situation, I expect I would also give up with stating I could not recall any to save the awkwardness of sitting there silent for half an hour racking my brain.
I'm sorry, but what? If you can't even remember what list/set/map whatever is called, how are you going to use them? We're not talking about exact syntax here, just what data structures you use...
> If you can't even remember what list/set/map whatever is called, how are you going to use them?
Certainly not by dictating their names to my coworker. Why would I need to know their names? I suppose some languages require you to know their names in order to use built-in implementations, but lots of languages use other syntax – often void of natural language (e.g. [], {}, etc.) – to do the same.
I eventually got there, but it took awhile to remember. That's great if you have prioritized trivia to occupy your mind's space, but I have found no reason to.
> Why would you need to _communicate about programming_? Because it's a core part of your job...
Honestly, I am not sure I have personally ever had to communicate low level details like that with anyone else. The people I have talked pogromming with in my life have all be capable technologists, which allow us to discuss in high level detail. If a list is the right data structure for whatever high level problem we are trying to solve, it is assumed we know that and understand how to use it.
> Every interview question can be characterized as trivia if you squint hard enough.
Well, I suppose. And there isn't anything wrong with trivia per se. But at the same time it should not be surprising when someone doesn't have an answer. A lot of this stuff just isn't worth having in immediate memory – unless you enjoy trivia, in which case, cool!
> Honestly, I am not sure I have personally ever had to communicate low level details like that with anyone else. The people I have talked pogromming with in my life have all be capable technologists, which allow us to discuss in high level detail. If a list is the right data structure for whatever high level problem we are trying to solve, it is assumed we know that and understand how to use it
This feels like either hyperbole or extremely rare/almost impossible, but regardless for myself and those I hire, I believe it to be a core competency.
> This feels like either hyperbole or extremely rare/almost impossible
Why's that? Aren't these basic knowledge items almost always able to be left unspoken? "Here is what we are trying to accomplish, and you must use a map in your implementation" never seems pertinent. There is faith in the people I work with that they will understand how to best implement something.
Furthermore, if there were some reason to bring up, say, a list then I could fumble around with some other ideas to get the group there. "I'm blanking on the term, but you know, the thing you can build with square brackets.", "Oh, you mean a list?", "Yeah, that!" But that doesn't satisfy the question posed here which specifically asked for the structure by name. In normal situations you don't need that kind of thing at your beck and call like you do when you are playing with a trivia master.
> I believe it to be a core competency.
And, to be fair, if I were knowingly about to enter a developer interview I'd probably brush up on the language ahead of time knowing that it is likely that an interview very well might want to talk about the trivial basic building blocks to weed out those who have never programmed before. But I personally haven't interviewed for a job in 20-some-odd years, so again, not something in the forefront of my mind before this discussion happened.
However, of note, the interview in question was for a people-based job, not a technical role. Who is going to think to study the technical language ahead of time in that situation? It wasn't pertinent to the job. The interviewer just went there because it was noticed the person once was a developer in a past life.
> Aren't these basic knowledge items almost always able to be left unspoken
Nope.
> "I'm blanking on the term, but you know, the thing you can build with square brackets."
Data structures are unrelated to brackets, so I assume this is hyperbole.
> In normal situations you don't need that kind of thing at your beck and call like you do when you are playing with a trivia master.
Are your friends names also trivia? The word "car", "tree", "sun"?
Hyperbole.
> But I personally haven't interviewed for a job in 20-some-odd years, so again, not something in the forefront of my mind before this discussion happened.
Respectfully, my assumption is that you also don't work in technology, or always work alone.
> the interview in question was for a people-based job, not a technical role
Technical leadership requires some amount of software knowledge as a core competency.
> Who is going to think to study the technical language ahead of time in that situation?
Someone claiming to have 10+ years of developer experience should know the word "list". Full stop.
> It wasn't pertinent to the job
It was pertinent to the job.
> The interviewer just went there because the person once was a developer in a past life.
Well, no not really. Because the person was expected to communicate intelligently about software, and knowing the basics of data structures is again a core competency.
> Communicating about work is a core part of work.
Absolutely, and the work I do is solving problems to further business objectives. As such, we talk about business things. Lists, sets, and maps are not normally business-related terms. Indeed, programming is the tool we most often use to implement the solutions to the particular problems we face, but it is not the work any more than a hammer is the work.
> Respectfully, my assumption is that you also don't work in technology, or always work alone.
I do not work alone, but I use the tools alone, yes. I expect most do. I don't see much evidence that pair/mob programming has ever caught on in a significant way.
> Data structures are unrelated to brackets, so I assume this is hyperbole.
They are indeed related as some programming languages use [] syntax to denote use of the data structure mentioned. If the people involved in the conversation are familiar with those languages, they can infer what is meant through the process of communication.
> Someone claiming to have 10+ years of developer experience should know the word "list". Full stop.
You're going off the rails here. A developer of 10+ years will know the word "list". That is not in question. The topic of conversation is how they will not necessarily have it at the tip of their tongue, because why would they? Unless you are caught in the 10 years of experience doing the same thing over and over trap, leaving you forever a beginner, it is not something people normally talk about.
Again, what would seasoned developers need to talk about lists, sets, and maps for? They should know them inside and out, backwards and forwards. "Hey colleague, I need a list here, but I forgot how to do it. Can you help?" never comes up. "Good news everyone, I discovered this great new thing... It is called a list!" – not going to happen. If we were talking about esoteric data structures, that's a little more conceivable, but we are talking about the ones you use essentially every time you write some code.
I think the part of the question that throws people is “most common”. It begins to sounds like a trick question, because it hat is the most common? Its going to very from code base to code base.
Maybe id the question was name 3 data structures, any 3 it might sit well.
But even so. The question did devolve into list of things somebody should know as a ex developer.
> I think the part of the question that throws people is “most common”. It begins to sounds like a trick question, because it hat is the most common? Its going to very from code base to code base
That’s pretty textbook overthinking for an interview. The point is that it varies from codebase to codebase. Tell me about what you normally use and I’ll ask questions.
> Maybe id the question was name 3 data structures, any 3 it might sit well.
Trying to get every human to agree on the wording for an extremely easy and general question isn’t a worthwhile use of time though.
> But even so. The question did devolve into list of things somebody should know as a ex developer.
Interesting use of “devolve”. An an interviewer for a technical role, am I not allowed to have a set of required skills? And is a basic understanding of common data structures not allowed to be in that set?
Languages and English is hard. So asking clear questions is important. Proof is in this conversation. As you seem to have suggested so much from so few words.
It devolved, because it went from what looked like a structured question with a finite expcted result, "Name the most common data structures" , to something more loose, a list of structures, any structures.
Further more, we agree, the candidate was trash, and I don't think the wording would have helped. But I do think a more precise question, or maybe a less loaded, or bias inducing question of "name some data structures". Namely, because "common" is subjective as I pointed out. If you are writing lisp all day, well, list are your most common. If you happen to be in assembly then registers are. So to be a better interviewer you don't want to taint the question with your notions.
Sounds like a trap. The first structure that came to mind was an r-tree. While I have a superficial understanding of when to use one, I have never needed to and would need to look up the details for the next question that is no doubt to talk about it in detail.
It came to mind first because I don’t know the intimate details and would need to look them up should I ever need that structure. That leaves reason to keep the name in active memory, unlike the structures you use daily, which never have reason to communicate outside of artificial situations.
> And is a basic understanding of common data structures not allowed to be in that set?
It may not be unreasonable, but the question didn't ask that. Granted, it is unlikely the interviewer was skilled in interviewing and the ill-conceived question was born out of their own lack of ability in the the job they were thrown into doing. The reality is that very little effort goes into researching the science of hiring in the first place, and it is even less likely to find people who are both experts in technical matters and experts in what little we do know about interviewing. For how critical businesses claim the hiring process is, it is amazing how they will so often happily throw the first bumbling idiot they can find willing to accept the interviewer role into it like it doesn't matter.
That's interesting ... Might be my specific view on Haskell, but there is a lot of emphasis on using the right data structure for the right job. That's probably because due to Haskell being immutable you have to rethink which standard data structures you can reasonable use.
What role were you interviewing for? Sure anyone with a serious CS degree at some point knew the difference between a char and a string. But if you're hiring a VP or product in a larger org, it doesn't matter whether they remember because the people they'd be managing wouldn't even need to know.
It’s quite possible to avoid learning this. A trivial way is to do all of your coding in python, and then never do anything more advanced than a todo MVC app. Do this for 3 years then get promoted to management and stop coding.
When money was cheap, delivery didn’t matter for a while.
I've interviewed and approved people for hiring who probably did not know the actual difference between a char and a string. And they've done more than a TODO MVP. They were great employees. For python dev work you really don't need to know about that, since it doesn't have a dedicated char type. They could probably answer questions about Django and RabbitMQ that OP couldn't.
But I'm assuming OP is hiring for a lower-level language role where that knowledge is necessary. I've interviewed people with similar levels of incompetence. Again for that Django role, people who did not know the difference between GET and POST. I'm amazed they made it past the first phone screen with our hiring manager. And I'm curious how bad the people who did not pass the phone screen were.
In their defence, many companies advertise various "leadership positions", but once you get to an interview stage, you see they are looking for another JavaScript monkey in the team, and the whole leadership thing is a pie in the sky in lieu of a competitive salary.
Presumably something like "a string is a sequence of characters" would be a good first answer, though it might prompt some follow-up questions.
I love how questions like this suddenly become more complicated when you have a deeper understanding of the internals. Your first instinct of an answer might not be 100% correct. If I were asked this question unexpectedly, I'd probably trip over myself a few times as I thought through it out loud.
My high water mark was the basics... and then the candidate drawing an analogy between char as primitive and char-array-based-strings as object oriented classes that offered additional functionality on top of chars.
That sounds like someone who will make a four-page fizzbuzz solution, which was at one stage a highlight for us.
What I try to get candidates to do in interviews is find the project they are most proud of, and get them to talk about it at a technical level - the constraints, challenges & solutions. That’s much harder to fake than pretty much anything else, and works at any technical level. My theory is that if they can communicate technical things in enough detail, and show that they have sufficient depth in at least one area they should be able to move sideways into our stack and context.
I also ask the same question. Because of my current industry, usually with the caveat that they have to be able to get into some technical details without breaking NDA.
Some of my favorite other questions are:
1 - You're diving into one of our repos for the first time and you need to add X feature. Let's assume everything is perfect, what would you want to see in the repo and what are your first steps in learning the code?
2 - Tell me about your favorite bug? It doesn't have to be one you caused. And it doesn't have to be a super technical obscure bug. Just your favorite bug.
3 - What are some of your personal philosophies when it comes to programming. In other words: What are some of your opinionated takes. I understand, when working here you'll follow company policy. But what if you were the person who wrote the company policies.
All are great jumping off points for further discussion and open up a lot of followup questions. I find they're pretty hard to fake after the conversation goes on for more than a minute or so.
> You can tell pretty quickly how involved they were and if they were thinking through solutions vs just doing as told.
Yes, but which has more utility for you.
Do you tell people what you are indexing for? Its not a fair assessment if you don't tell which has more utility for you, or don't tell the recruiter how to help people prepare and just gaslight people with "there's no right/wrong answer, I just want to see how you think" if you actually want someone that does what they were told or someone that synthesized solutions. Many people have experience in both environments and have an answer for both environments.
Not the OP but I'd expect the desired answer to be some kind of semi-technical discussion that shows they understand the fundamentals even if they've forgotten all the details and can have a healthy conversation, not that they know the answer.
Possible good indicators: "I haven't written C code in a decades, but one is a byte, one is a structure" "I'd be in over my head with Unicode but.." "What are you looking to solve?"
Bad indicators: Hostility. Authoritative wrong answers.
(For a director of Product role once, I was asked the difference between REST and SOAP -- not because he cared that I knew the answer, but because he wanted to see how I could work with an engineer who was focusing on the wrong problem)
It's a grab bag, tell-me-something-interesting icebreaker question. I'm looking for some evidence of the fact that you can differentiate the two in some meaningful way.
Not intended to be a gotcha question! Just a quick test of basic CS knowledge to get the candidate comfortable.
There’s nothing irrelevant about measuring someone’s technical understanding of the very basics at the same time that you gauge their ability to have a conversation about the domain.
The Nintendo Help Line could be argued to be a microtransaction. However, callers talked to knowledgeable players who had the game in front of them, with maps, boss strategies, etc, available.
You could also send them a letter for free. The local rental place didn't have the manual for Wizardry and it's not exactly clear what many of the spells in the game do, since they have names like halito, mahalito, dios, badios, etc.
Nintendo sent me a letter explaining what this all did back in the day.
no advantage over the smaller more modern dishes, as the more modern dishes are made with better shape tolerances, so they can be smaller and still get the same amount of signal to the satellite.
People say lawyers are assholes, but they don't think about why lawyers are assholes.
It's a lawyer's job to imagine the worst future outcomes and guard against them in the present.
Everybody focuses on "It's crazy you put that clause in there that was never needed," but few folks appreciate "Thank god we included that clause just in case."
Which isn't to opine there's a right or wrong, only multiple parties each negotiating (skillfully or poorly) in their own interests.
If you're a developer and don't want your code to slide into corporate controlled ownership... well, there are licenses for that.
I think every single one of my attorneys over the years has made it clear that if something is in the contract/license/etc, you absolutely have to assume it will be enforced, to the letter. No matter how stupid, no matter how unlikely. If it's written down, it was written down for a reason.
One of the worst mistakes you can make in life is believing anyone who says things like "oh, that's just boilerplate...we'd never act on it" or "don't worry, we would never enforce that" or similar. That's someone who is deliberately setting you up to get screwed.
Indeed. My mental rule of thumb is to assume that if we're at the point of a legal argument then bridges have already been burned and neither party is inclined to do any favors to the other. Ergo, the legal language is the only language that one can depend on.
Not necessarily. I recently reviewed a french work contract that included weird clauses. But after looking at the case law, it turns out they are illegal and thus void anyway if taken to court. In that case, there is no need to spend energy trying to get them removed: this may backfire and push the other party to write a new legal version that actually screws you. Sometimes it's best to accept a weird clause that you know will not hold up in court.
Wrong. Putting you in the situation where you have to go to court to defend yourself from an illegal clause is screwing you. And the assumption that just because one court say "that's wrong" automatically means the one your litigating in will too is comically bad.
The legal system isn't a computer that has deterministic outputs.
I don't know which country you're in, but in France we have quite strict rules as to how some clauses must be structured in a work contract to be valid.
For instance an non compete clause which is not limited to a certain geographic area is invalid, period. Yet some companies apparently don't know this. They copy paste boilerplate which doesn't hold up in court.
And no court can rule against this as the supreme court has already decided what makes a non compete clause valid and it is very precise in the requirements.
As a rough analogy that my lawyer told me early on, lawyers are like software engineers, and the law is like the operating system. A good lawyer writes robust "code" designed to deal with edge cases and unexpected conditions gracefully.
I think what we're seeing is people want something in between. It's hard to codify social norms. Many devs I know don't want to deal with the additional work that a partial GPL ecosystem involve. Most don't even care that changes to their code are published. On the whole, they want others to be able to do what they want with the source. What they don't want is the project to be co-opted or to be put out of business by a service provider that's leveraging their presence elsewhere (e.g., an entrenched cloud provider adding a competing SaaS option).
AGPL is possibly the only one that could guard against the latter, but it brings with it other limitations the author may not want. It almost certainly cuts down on the pool of contributors. While it fixes one problem, it creates others.
I think the fundamental problem is that open source licenses apply equally to everyone and really only govern what you can do with source modifications. The proposed solutions seem to be of the form "make it onerous to use and sell commercial licenses on the side." But, I don't think that's really what many people want. For one, it changes the business model. Moreover, they don't want something that restrictive for most parties. It's just that "don't bite the hand that feeds" is hard to codify.
At the core of it, these folks want something that functions like open source for the majority case but affords protection in the extreme. It has little to do with the ideals of software freedom. For better or worse, the BSL attempts to address that problem.
I think we largely overestimate how much the average person even cares about open source. I can only speak to my own experiences, but most devs I know haven't even read the major open source licenses. And that extends to how they consume source. Plenty of them take code from public repos without any declared license. They crib answers from Stack Overflow without attribution. They never check the licenses of their full dependency graph. Unless the legal team requires explicit approval of adoption of new open source projects, they don't go through that exercise. What they want is something they don't have to pay for that they can easily modify; open source happens to satisfy that problem.
It'll be interesting to see how this plays out. I'm not sure the BSL will clear legal approval at many companies. So, the companies using the license may find it's not any more advantageous than GPL. After all, if devs can't use your software, you haven't really gained anything. But, I'm curious to see how this all plays out. It's the first concerted attempt at solving a problem that open source licenses don't solve in a satisfactory way for many of us.
The AGPL doesn't prevent Amazon from competing with you if they wanted to (although they don't yet). There was an AWS employee just the other day saying that the AGPL isn't very hard to comply with. I'm sure that they could do that if they wanted and probably will do at some point.
Fair enough. I'm sure Amazon has a legal team that's examined this far deeper than I have. If that's the case, it furthers my belief that GPL-like licenses aren't really providing what many are after.
Yeah, what many are after is proprietary licenses, not open source ones. Any license that prevents the competition Hashicorp and others don't like just isn't an open source (as originally defined) license. As Drew Devault wrote, open source means surrendering your monopoly over commercial exploitation.
Same. I think it's a mix of that and this "presenter voice" everyone thinks they have to use. My ADHD brain doesn't focus on it well because it's too slow so it's useless to me but all my life I've been told when presenting I should speak slowly and articulately while the reality is that watching anyone speak that way drives me nuts
What's great about writing is that readers can go at their own pace. When speaking, you have to optimize for your audience and you probably lose more people by being too fast vs. the people you lose by talking too slow. I have to say I appreciate YouTubers that go a million miles an hour (hi EEVBlog). As a native speaker of English, I can keep up. But you have to realize, most people in the world are not native speakers of English.
(The converse is; whenever I turn on a Hololive stream I'd say that I pick up 20% of what they're saying. If they talked slower, I would probably watch more than every 3 months. But, they rightfully don't feel the need to optimize for non-native speakers of Japanese.)
This is why I hate the trend of EVERYTHING being made into a video. Simple things that mean I have to watch 4-5min of video and have my eardrums blasted by some dubstep intro so some small quiet voice can say "Hi guys, have you ever wanted to do _x_ or _y_ more easily?" before finally just giving me the nugget of information I came for.
I wish more stuff were available in just text + screenshots..
Some of those people seem to be speaking so slow that it is excruciating to listen to them. When I find someone who speaks at a normal speed and I have to slow the video down, they usually have more interesting things to say.
That said, tinkering before and after youtube has been two different worlds. I really like having video to learn hands-on activities. I just wrapped up some mods to a Rancilio Silvia, and I noticed my workflow was videos, how-to guides and blog posts, broader electrical information documentation, part specific manuals / schematics, and my own past knowledge. I felt very efficient having been through the process before, and knowing when to lean on which resource. But the videos are by far the best resource to orient myself when first jumping in to the project, and thus save me a lot of time.
- Nuclear power
- Access to Earth orbit
- GPS
- Mapping of the world's oceans
- Miniaturized circuits
- The Internet
- Interstate road systems
- Hubble Space Telescope
- Earth observation satellites
For such a horrible technology, humanity seems to have made out okay.
As someone who recently started surfing, I understand the cultural timing a lot more now.
Good surfing requires pretty particular types of waves. Which in turn requires particular wind. Even at good locations, these are transient conditions that can appear and disappear at the whim of nature (even over the course of an hour).
Ergo, surf's up = drop things that don't need to be done ASAP
They'll be there later. Good waves probably won't.
Oof, those are some gnarly waves. Wave structure as a surfed experience is my favorite part so far: there are so many wave nuances I never noticed before.
Australian slabs - the big ones out of the polar south tend to have waves within waves and can even "triple curve" over; I'm in the west The Right (last of the three) was my local for a few years.
CS degree.
"I have a proven track record of building and leading amazing engineering teams."
"Okay. What's the difference between a character and a string?"
*crickets*
We all have our specialities, but jesus ¢@&#ing christ: if you're interviewing for an engineering role, of any sort, you should be able to answer basic questions.