- Excellent book for tough interviews : Algorithms in C++11/C++14 - 1 Update
- faster than c - 2 Updates
- faster than c - 1 Update
- Ways to write initializations - 2 Updates
| legalize+jeeves@mail.xmission.com (Richard): Apr 19 05:13PM [Please do not mail me a copy of your followup] Having interviewed many people over the past few years, I'd prefer someone who knew test-driven development and agile development practices over someone who knew how to answer "brain teaser" questions anyday. Knowing how to write testable code, how to perform incremental design, how to refactor a working system are the day-to-day skills I use all the time and those I seek to find in someone I'm adding to my team. We moved to giving people a programming problem over interviewing them because we wasted so much time interviewing people who weren't that good. The response to our programming problem was much more informative than any amount of Q&A style interviewing. If they did a decent job on the problem, then I'd prefer pair programming with the candidate over any Q&A style interview. I think I *might* have browsed the book mentioned by the OP in the bookstore. If it's the one I remember, the emphasis was all wrong for the skills needed on a modern agile team. It was the kind of things you needed to pass a Microsoft interview in the 90s or early 2000s, but completely missed any of the skills that I want in a modern team member. YMMV. For job seekers, this is my advice: - Let yourself pick the job, instead of the job picking you. This takes more time, but it is more satisfying for the applicant. Research and identify the company that *you* want to work for and approach them for a position, whether they have a posted job opening or not. From the employers perspective this means they're talking to someone who actively wants to work for them, instead of just random applications they received because they had a job posting open. Even if they say they have no positions open, ask to pair with one of their teams for a day. Volunteer to sign an NDA if they are concerned about exposing you to IP. If this doesn't result in a job and you still are interested in this company, keep contacting them every couple of months -- frequent enough to remind them that you *want* to work for them, but not so frequently as to be a pest. If this is a stable or growing company, eventually they will have an opening either due to attrition or growth and you will be top in their mind when they consider opening a position. - Ask for your interview to be in the form of a pair programming session. You'll both be working on code together in a manner that more accurately reflects what it will be like to work there. You'll get a better sense of how well you will fit into the team -- you should switch pairs every hour or so, depending on the team size. Modern software development is teamwork, not a solitary hermitic experience in a cave. Given the choice between a regular programmer that fits well in the team and an abrasive "rock star", I'd take the former. A team goes faster when everyone on it gets along well with each other. This form of interview takes longer, but it gives the applicant a chance to get over "interview jitters" and relax, focusing on solving problems together with code. - Interview the employer, instead of them interviewing you. This will happen in an unforced natural way as a consequence of the above two items, but if you're in a standard Q&A verbal or in-person interview, come prepared with a list of questions for your prospective team that you want answered. This changes your perceived attitude as an applicant from "I just want to get paid to program and I hope they hire me" to one who is actively seeking an employer and team that provides the satisfaction you want. If it's not a good fit, it's best for both sides to learn this in the interview than it is to find this out after 6 months of working there. - Make significant contributions to an open source project. This will give you a public portfolio of code that you can share with potential employers. Contribute in such a way that the employer can not only browse your code, but also the commit history. Github is excellent for this, but there are others that are just as well. - An alternative to contributing to open source is to work problems on exercism.io and share links to your solutions. Employers will be able to see your solution to a variety of problems, see iterations on your solutions and see what kind of feedback you obtained from others on your solutions. This isn't as good as doing actual features on an open source application, but its better than nothing. The above suggestions are from the perspective of "I have time to look for a satisfying and rewarding job". If you're in the situation of having immediate financial needs that can't wait, then the above approach may take too long for you. However, you can still use some elements of the above to make your interviewing process go smoother. In particular, contributing to open source or working problems in exercism.io helps you build a public code portfolio and that always helps more than phrasing on a resume. Even if you have immediate need for employment, this is something you can do right away to help yourself out. If you're currently unemployed, then this should be your full-time job until you are employed. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Ian Collins <ian-news@hotmail.com>: Apr 19 04:52PM +1200 Stefan Ram wrote: > What is this? { 1, 2, 3 } seems to be used to initialize a > temporary object whose lifetimes ends at the semicolon, so > the pointer y then would be dangling? It's an initialiser list. To quote cplusplus.com: "initializer_list objects are automatically constructed as if an array of elements of type T was allocated, with each of the elements in the list being copy-initialized to its corresponding element in the array, using any necessary non-narrowing implicit conversions." So while the object is a temporary, the data it references is not. Note that the return type of std::begin() is a const T* (constexpr in C++14). -- Ian Collins |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 19 09:27AM -0500 Ian Collins <ian-news@hotmail.com> wrote in > list being copy-initialized to its corresponding element in the array, > using any necessary non-narrowing implicit conversions." > So while the object is a temporary, the data it references is not. There is no data object the y pointer could point to. 1 is a rvalue whose address cannot be taken, and any other objects constructed from it and initialized to 1 are not guaranteed to be alive. Quoting from cppreference.com: "The underlying array is a temporary array, in which each element is copy-initialized (except that narrowing conversions are invalid) from the corresponding element of the original initializer list. The lifetime of the underlying array is the same as any other temporary object [...]" So, as the array is temporary, a pointer to its element can and will become dangling as far as I can see. Cheers Paavo |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 19 04:39AM Newsgroups: comp.lang.c,comp.lang.c++ >Again, this would be problematic in C++, unless the object is const. So >one could have: >const int* y = std::begin({ 1, 2, 3 }); What is this? { 1, 2, 3 } seems to be used to initialize a temporary object whose lifetimes ends at the semicolon, so the pointer y then would be dangling? |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 18 07:27PM -0400 On 4/18/2015 2:43 PM, Stefan Ram wrote: > And then, »T x{};« is called a »value-initialization« IIRC. > Is there any rationale for this designation? After all, a > value is what actually is /missing/ in the braces! The difference exists when the type T is not a class type, IIRC. For instance, if 'T' is an arithmetic type, 'x' will be left uninitialized if you write T x; whereas if you write T x{}; it's value-initialized, which for arithmetic types means zero-initialized. > initializier-list constructor, this initializer-list > constructor will be called for the declaration > »T x{ 2, "a" };«, but not for »T x( 2, "a" );«? Yes, I think you did get it right. Have you tried it? V -- I do not respond to top-posted replies, please don't ask |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 18 07:31PM -0400 On 4/18/2015 4:02 PM, Stefan Ram wrote: > is a copy initialization IIRC, while > T x( ... ) > is a direct initialization IIRC. (if it *is* initialization, and not a declaration of a function) :-) > Is there any case where one would prefer to write a copy > initialization instead of a direct initialization? In some cases it's easier to read the '=' form. Especially as far as built-in types are concerned. Older programmers (and C programmers) are used to seeing forms T x = expression; rather than T x{expression}; For built-in types those mean the same thing. V -- I do not respond to top-posted replies, please don't ask |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment