As software eats the world, the programming languages used to build the software themselves grow and evolve. When new programming languages start out, they are often the product of an individual or a small group of people, though there are several famous examples of top-down programming language design where the PL is designed by committee from the outset (e.g., ALGOL . However, when a PL gets to a certain level of adoption, the inventors sometimes submit the PL to one of the standardization bodies: ISO C++, ANSI C, ANSI FORTRAN, ECMA/ISO C#, and ECMA ECMAScript. Others continue to retain their independent governance bodies (e.g., Python, Java). In either case, the governing bodies specify a process for evolving PLs: Java: Java Specification Requests C++: C++ papers Python: Python Enhancement Proposals Rust: RFCs C#: Language Proposals ECMAScript: ECMAScript Proposals Each of these governance bodies is like a small government. Many have voting ...
It's a challenge to outperform all the other candidates in a competitive tech job only, but there is hope. You can improve your performance with practice and watching out for these gotchas: Make absolutely sure you are solving the right problem: I ran into this the other day. It is entirely a communication issue. When doing an initial screen over the phone, this problem is compounded. For example, maybe an interviewee is hacking out a function that returns the k highest priced products when the interviewer is expecting the kth highest priced product. One can squander a lot of time due to these misunderstandings. A good interviewer will try to guide you back to the right path, but you can't expect this. Be sure to ask questions. Confirm that the input and output are exactly what you expect. Use examples. Don't ever give an interviewer the impression that you are avoiding writing real code. This is an impression thing. This is a coding interview so you should be expecting...