481–490 of 674 posts
Earlier quoted context omitted.
I think you're right to thank them for their difficult job. I seriously got bored just reading the description of your setup. What percent get through to the second email? Is it like 10%? 50%?
They said 200 emails/month to the general and one every six months to the second email, so that's well under 1%
There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…
I agree. Personally, I'm a bit horrified at the idea that someone who wants to be an "expert at object oriented design" would turn up their noses at "binary-tree-traversing questions". It sounds like a formula for aspiring Architecture Astronauts. It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process, although t…
It's also not realistic, given the wheat-to-chaff ratio
out there, for a manager to interview all the candidates
directly without an elaborate screening process
I'm a hiring manager. If I say someone should spend 8 hours attending an in-person interview before I'll spend 5 minutes reviewing their resume/github, I'm saying my time is a hundred times as valuable as theirs. I can understand someone taking umbrage at that - especially someone who had better skills than me. And I want to hire people with better skills than me.
There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…
Not to be overly nit-picky here, and technically O(n) is correct as well (it's also the un-amortized worst case of insertion), but you probably meant to say that the amortized time is O(1), or θ(1) to be even more precise :)
Earlier quoted context omitted.
I believe I should learn from my mistakes and move on rather than have rabid obsession over big O. It's not even an obsession. Those pieces of knowledge could be fully mastered in about a half hour. It's first principles knowledge , like chemistry or thermodynamics. I can tell in a minute that something like "Solar Freakin Roadways" is a scam, whereas so many people gave that scam literally millions of dollars. Knowl…
We agree to disagree. I absolutely don't disagree with optimizing when it's obvious (two for loops instead of one, etc.) All I'm saying is that, when you have thousands of lines of code (millions?) and even more complicated/intricate connections in your head of different modules, all the while when trying to reach a deadline, things aren't as obvious. You have to make compromises, it's inevitable. Amazon or Google di…
What we disagree with, is the expansion of one's knowledge of what constitutes "obvious." Many people would say that the scam nature of "Solar Freakin Roadways" was far from obvious. Other people would smack their foreheads and ask why some people didn't pay attention in middle school and high school physics!
Earlier quoted context omitted.
Keep in mind - the CEO in question could be writing personal e-mails out from an ATS / Sourcing tool that helps keep track of communications. Tracking links are not always == shotgun approach
Tracking links are always extremely bad form, though. I'd be interested in hearing from the other side, though, why such behaviour would be considered acceptable.
There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…
If you look at the current AI, machine learning, and deep learning fields it's an absolute must that you have some experience with algorithms.
Earlier quoted context omitted.
This same exact argument could be used to require every interview candidate to know assembly. Have you ever done the standard Comp Sci compiler implementation class? Do you write C++ and use the C++ standard library? If you answered yes to both questions, then you should know from first principles how just about everything in the standard library is implemented, and can use those tools with complete knowledge of when…
>It's the developer who has a clue about algorithms who is more likely to make the valuable insight. The ability to implement the sorting algorithm in the C++ standard lib is completely orthogonal to people who have this insight. People who have an understanding of complexity analysis is really all it takes to have that insight. Memorizing a bunch of datastructure algorithms has almost no bearing on this ability.
Weak example! Exactly when would you want to use a shared_ptr, and when you you absolutely not want to use a shared_ptr? Why? And what pieces of 1st principles knowledge would let you simply know that in about a minute?
People who have an understanding of complexity analysis is really all it takes to have that insight. Memorizing a bunch of datastructure algorithms has almost no bearing on this ability.
Note that in this thread and others I've been advocating for First Principles knowledge. If you have that knowledge, then you'd probably know several of the most basic algorithms and their analysis from having learned that. I'm not advocating that people just be able to spit out a memorized text!
Earlier quoted context omitted.
...because knowing assembly is actually useful to a high level developer? If it were, then yes, I'd say they should know assembly too. But I know assembly; I've written entire published games in assembly language. To expand on what you are saying: If you're doing "high level development" on a business app in C++ 11 then knowing assembly and having been through a bog-standard undergraduate CS Compiler Development cour…
> If you're doing "high level development" on a business app in C++ 11 then knowing assembly and having been through a bog-standard undergraduate CS Compiler Development course will actually help you use a whole bunch of things in the C++ standard library Agreed, and my understanding of assembly does help in those ways. I actually feel like compiler design was one of a very few classes in college that really, really…
Earlier quoted context omitted.
>Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. This same exact argument could be used to require every interview candidate to know assembly. >and the person who likes to think about such things…
This same exact argument could be used to require every interview candidate to know assembly. Have you ever done the standard Comp Sci compiler implementation class? Do you write C++ and use the C++ standard library? If you answered yes to both questions, then you should know from first principles how just about everything in the standard library is implemented, and can use those tools with complete knowledge of when…
People create value with software when they use code to solve problems.
For some people, that means tackling a gnarly complex problem and by a combination of wits, experience and education, come up with an efficient and elegant solution. Typical example: someone working in a specialized role in back-end (i.e. not user-facing) systems in a large company (small companies can't usually afford specialized roles). Concrete example: V8 JIT engineers.
For other people, it means looking up from the keyboard, figuring out the company strategy and product fit, and seeing what can be most efficiently (in terms of effort) put together to improve or align both. Creating a proof of concept that gets buy-in for a more in-depth solution.
The second category almost always delivers much more value than the first. And there's a spectrum in between, a spectrum of people who are all very good at what they do, all very good at creating value; the spectrum extends from the guts of the machine all the way out to the interface with the customer.
I've worked in some very different industries in my career; ranging from compiler engineer to web app developer. Compiler engineers leave their fingerprints on far more code, and the job is intellectually stimulating. But realistically, most of the reward of the job comes from the fun of job itself. As a web app developer, I apply my knowledge of compiler techniques to things like SQL generation from filter predicates represented as ASTs, for efficient display of the user's data. But I could only deliver that because I saw the possibility of connecting the back end we had with an Excel-like experience we could give the user; and I had to take it on.
I've seen other people take a bunch of open source components - not knowing in depth how they worked - and put them together to create surprisingly credible solutions very cheaply, the kinds of solutions that win 7-figure SaaS deals. You don't get there with your knowledge of binary trees or compiler principles.
Earlier quoted context omitted.
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenate…
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. True. And people who clutter their code by using some fancy "StringStream" class when they could've just used a concatenation are also part of the problem! Sa…
Knowing the typical time and space complexity for an algorithm (without even understanding one bit about the implementation details) in a given category might be considered too trivial to be even basic, but I submit it's about the most "advanced" piece of knowledge for what a typical engineer really must know to write good, high quality and performant enough code.
Most can get by using a given language's library implementation of an "obvious" data structure and naive algorithms around it. For example, in Python, the "obvious" structure to map keys to values is a dict, and iteration over the keys or item tuples is a typical access pattern. An engineer doesn't need to know whether the dict insert or lookup is amortized O(1) or any other value, and he doesn't need to know the space required is O(n), etc. In almost every case he's likely to put it to use for the dict is fine.