Elfforkusu
Member
Obviously it also a ton if you have a connection to skip the front door interviews.Getting hired at Google is 100% how well you do on the interview. Which itself is about 60% luck.
Obviously it also a ton if you have a connection to skip the front door interviews.Getting hired at Google is 100% how well you do on the interview. Which itself is about 60% luck.
Obviously it also a ton if you have a connection to skip the front door interviews.
The screening interview is harder than the "real" interview for a certain type of engineer. Has to do with the sort of questions they ask (I assume you've taken it? Study up on your combinatorics, even if you haven't used it since college you might be expected to know it!)Doesn't matter how many connections you have, you're not skipping the *real* interview, which is by far the hardest part. Connections might make it easier for you to get a call back from HR, but it means absolutely zero when it comes to passing the interview. And even then, if you don't get a call back from HR, you probably weren't going to pass the interview anyway (i.e. HR is overly liberal in who they call back, so there are very few false negatives at that early of a stage)
The screening interview is harder than the "real" interview for a certain type of engineer. Has to do with the sort of questions they ask (I assume you've taken it? Study up on your combinatorics, even if you haven't used it since college you might be expected to know it!)
But yes, you need to pass the real interview regardless. Well, if you're a wizard maybe they don't even bother, but odds are you are not a wizard.
Agreed. What I'm getting at with the screening interview is that you have a non-zero chance of bombing it, so your chances of landing the job will obviously be (slightly) better if you get to skip it.The thing is, everyone asks something different, and every interviewer has a different amount of experience interviewing, and a different amount of experience with the question they're asking (having experience asking a question is surprisingly important for questions of that caliber)
Phone screen questions tend to be softballs, but there's always the chance you get the interviewer who's never phone screened before, chose a bad question, or it just happens to be your anti question (ie every person -- no matter how good -- has one subject they will bomb if asked about)
I don't know of anyone ever having skipped the interview, so I'm going to say it's either not possible or you have to have be world renowned in a particular subject area
True you have a non zero chance of bombing it, but i think the conditional probability of passing the onsite given you've bombed the phone screen is very close to 0. That's literally the intent of the phone screen, to save them from wasting 5 engineers' time on someone who isn't going to pass anyway. I agree it's probably not exactly 0, but I don't think its significantAgreed. What I'm getting at with the screening interview is that you have a non-zero chance of bombing it, so your chances of landing the job will obviously be (slightly) better if you get to skip it.
I agree it can be dauting the first time you do it, but honestly it's not that hard. And you're going to have to do this no matter if you're using Visual Studio, Makefiles, CMake, or anything else. The reason is that your program and the unit test runner are two separate executables that need to share the same code -- the code that is being tested.
The way you share code in this way is by creating libraries.
To get up and running the quickest, you can literally change your entire project to a static library. Right click the project node, choose Properties, click General, and set Configuration Type to Static Library (.lib). Change your main function to be called something else like RunProgram(), make a header file and declare RunProgram() in the header file. I'll just call this header file foo.h, but make it something more appropriate.
Now create a new project, this time an Application (.exe). But do it by right clicking the root node in Solution Explorer and choosing Add -> New Project. When VS finishes creating it, you'll now have two projects in the same solution. In your new application project, add a #include "foo.h", then in main() simply call RunProgram().
To make it automatically link the library into the application, right click the project node of the application, choose Build Dependencies -> Project Dependencies, and then click the checkbox for the library. You'll probably need to set the include directories in your exe project to find the folder where the include files for the library are. This is in Project Properties -> C/C++ -> General -> Additional Include Directories.
In a production environment, you would probably create a more realistic separation between your driver / application and your core functionality that you're testing, instead of simply having your main() function be one line that calls the static library. For example, command line parsing, user input, etc would all be handled in the application while processing and utility libraries etc would be handled in the library.
In any case, when you've got all this working, creating the unit test suite is not much different than the application. Make a new Application, add a dependency, go to the Linker and Include settings and add the appropriate paths for gtest, then #include files from your library and start using them in yoru tests.
One common solution for handling the situation with include file paths is for a project to do something like this:
Code:project |__ project.sln |__ src |__ application |__ main.cpp |__ application.vcxproj |__ library1 |__ lib1.cpp |__ lib1.vcxproj |__ library2 |__ lib2.cpp |__ lib2.vcxproj |__ include |__ application |__ library1 |__ lib1.h |__ library2 |__ lib2.h
Now, in every project, you set your Additional Include folders to $(SolutionDir)include. Then in your application.cpp, you can simply write something like this:
#include "library1/lib1.h"
#include "library2/lib2.h"
And it will automatically find it. This way you dont' have to go manually screw around with the include path settings for every single project. It's always exactly the same value for every project, just "$(SolutionDir)include".
Anyway this is a lot to take in the first time you do it, but it's fairly intuitive once you get used to it.
It's pretty interesting. You can get an odd panel lineup and get roasted, and an engineer who isn't as talented overall ends up skating through. Combination of the right questions, right interviewers.Getting hired at Google is 100% how well you do on the interview. Which itself is about 60% luck.
+1Hey, it has a mocking framework included so that's a huge plus! Chrome + LLVM + cpp_is_king is enough endorsement for me.
As long as the interviewers are relaxed and have know how to progress a conversation, its awesome. If they're kinda geeky/nerdy than even better, just talk about code all day lol
Oh god.... gulp. I'm using sublime note 2, would I just be able to use #include and the name of the library or would I have to do a separate file named "foo.cpp" and change my main function to RunProgram() and then include that file into my new project and call RunProgram() in that main function? Where would the library be coded in if I were to do the later? I'm a complete novice when it comes to this so I just wanna learn how to do this.
#include <stdio.h>
#include <cs50.h>
#include <string.h>
#include <stdlib.h>
#include <ctype.h>
int main(int argc, string argv[]) {
//Set key to command line value
string key = argv[1];
//Prompt user for text to be encrypted
printf("Enter text to be encrypted: ");
string input = GetString();
string output = input;
for(int i = 0, n = strlen(input); i < n; i++) {
int vKey = (key[i % strlen(key)]-96);
if(isalpha(input[i])) {
output[i] = input[i] + (vKey % 26);
if (!isalpha(output[i])) {
output[i] -= 26;
}
}
}
printf("The output is %s\n", output);
}
So I'm really bad at... user-proofing(?) my programs at this point. Does anyone have any pointers? For example, in this Vigenere cipher I was working on, what would be the best ways to make sure users don't enter in things? Especially through the command line?
I think that's one of the things TDD is supposed to help with. Even if you don't do TDD, just documenting the edge cases before writing the code itself would go a long way (in making you better at identifying them, but also in making the code less breakable)So I'm really bad at... user-proofing(?) my programs at this point. Does anyone have any pointers? For example, in this Vigenere cipher I was working on, what would be the best ways to make sure users don't enter in things? Especially through the command line?
South Italy. Great sea,but not much going on in terms of techWhere do you live exactly? You can always try chat rooms for programmers.
I usually try to imagine things that could make each line go bad...So I'm really bad at... user-proofing(?) my programs at this point. Does anyone have any pointers? For example, in this Vigenere cipher I was working on, what would be the best ways to make sure users don't enter in things? Especially through the command line?
string key = argv[1];
string input = GetString();
Returns NULL upon error or no input whatsoever (i.e., just EOF).
strlen(input)
int vKey = (key[i % strlen(key)]-96);
isalpha(input[i])
output[i] = input[i] + (vKey % 26);
if (!isalpha(output[i])) {
output[i] -= 26;
}
Since you weren't the original person who asked the question, I'm not sure if you're using the same environment as him. Are you using Visual Studio or something else?
Also if you just want to make a simple program, you don't have to do this. I was just explaining how to set up a project that facilitates sharing code across multiple applications. In this case it's for the purpose of unit testing, but it applies in pretty much any large-scale project as well.
South Italy. Great sea,but not much going on in terms of tech
I did check on meetup.com but the only events I found are from a certain polical movement lol.
If I understand your question correctly*, it only needs to be somewhere in the path, but also that the version is compatible, which is sometimes tricky (although I'm not sure it's the case with libstdc++) You can also get into problems when people try to double-click on the executable and the working directory is not the one where you put the dll, if you decide to distribute the program with it.I'm just using sublime with MinGW as my compiler. If I were to ever release an .exe for people to try out, I'm worried that they would need a specific library that makes cout work in C++. The name of the library is libstdc++-6.dll
For my .exe's to work, I need to include this file in my folder and I want to know if just using #include libstdc++-6.dll will work without it being in the folder.
int* temp1 = new int[6]; //make the new dynamic array
int* temp2 = GAF; //make a new pointer to point at the array GAF points to.
GAF = temp1; //GAF now points to the new array
delete [] temp2; //deallocate the old array
temp2 = 0
You don't need two temporary pointers for that, just one. The idea is:I'm not quite sure I understand how to work with dynamic arrays.
Lets say I have
int* GAF;
then I initialize GAF with new int[5], and then later set the values of the array to 1, 2, 3, 4, and 5.
So now we have the dynamic array {1, 2, 3, 4, 5}.
Now lets say my program later needs to add an element to the array. Well the array is already full. So now I want to make a larger array. But I still want it to be dynamic, and I want GAF to point to this new array rather than the old one. Is this how I would accomplish it?
Code:int* temp1 = new int[6]; //make the new dynamic array int* temp2 = GAF; //make a new pointer to point at the array GAF points to. GAF = temp1; //GAF now points to the new array delete [] temp2; //deallocate the old array temp2 = 0
Basically what I want to do is create a new larger dynamic array, have GAF point to that new array, and then deallocate the older smaller array.
You don't need two temporary pointers for that, just one. The idea is:
1. Allocate the new array.
2. Copy over all the contents of the old array into the new one.
3. Delete the old array.
4. Make the old array pointer point to the new array.
You've done step 1, 3 and 4, (although not in that order, which meant you're using an extra, unnecessary pointer). You're missing step 2.
int* GAF; (lets say GAF is dynamic array {1, 2, 3, 4, 5}
int* temp1 = new int[6];
for (i = 0; i < 5; i++)
{
temp1[i] = GAF[i]; //copy over old values into temp1
}
delete [] GAF //dallocate old array
GAF = temp1
Correct. Memory allocated on the heap has to be freed manually. The temp1 variable will go out of scope once the function is over, but that's only the pointer. The memory it points to won't be freed. This is why you have to be careful with dynamically allocated memory. Removing the pointer doesn't actually free the memory. So if the pointer disappears, the memory is still allocated, but you have no pointer to it so you can't free it or use it and you get a memory leak.Question: Lets say this were a function instead. GAF is a global variable. But temp1 is a local variable created by the function for copying over values. When I set GAF = temp1 in that function, and then the function exits... does that cause problems? Or will it be ok because it is a dynamic array and the memory is in the heap not the stack?
void memoryLeak() {
int* terribleness = new int[64];
}
If you make it a function, setting what GAF points to won't actually change the original pointer, though.
Unless you're using references, arguments are passed by value. Even pointer arguments. It's just that when using a pointer, the value you're passing is the value of the pointer, i.e. the memory adress.Why is this the case?
int* GAF = new int[5];
int* GAF2 = GAF;
GAF2 = 10;
void replaceArray(int* array) {
delete[] array;
array = new int[6];
}
replaceArray(GAF);
int* array = GAF;
delete[] array;
array = new int[6];
Thrashing is a pathological phenomena that could happen as the underlying array resizes at threshold X. If an element is added at X+1, the underlying array is enlarged. If an element is removed leaving X-1, the underlying array is shrunk.
"If a client calls push, pop, push, pop then it's going to be doubling, halving, doubling, halving creating arrays on every operation taking time proportional to N on every operation and therefore quadratic time for everything. The efficient solution is to wait for the array to get one quarter full before you halve it... There won't be another resizing operation until it gets totally full or half again full. So the invariant of that is that the array is always between 25% or 100% full and that every time time you resize you've already paid for it in an amortised sense."
If I understand your question correctly*, it only needs to be somewhere in the path, but also that the version is compatible, which is sometimes tricky (although I'm not sure it's the case with libstdc++) You can also get into problems when people try to double-click on the executable and the working directory is not the one where you put the dll, if you decide to distribute the program with it.
* not sure I am because of the #include... You don't want to put a #include of a dll inside the source file? Because it would be a totally wrong idea...
That being said, I'd suggest you to get rid of the dependency by statically linking the library when you build your executable.
If I'm not mistaken, the option required is -static-libstdc++
I'd also suggest -static-libgcc
Regarding dynamic arrays, if you're in C++ don't you really want to use vectors for that purpose since a vector is basically an automatically resizing array?
Otherwise if you're just using regular arrays and you anticipate a variable number of resizes to your array, you may want to resize in a way that avoids thrashing:
http://javaagile.blogspot.com/2013/02/thrashing-and-amortization.html
Languages have evolved since the 1980s. Most modern languages use references instead of pointers. It's basically doing the work for you - improving your productivity and eliminating the possibility of a class of bugs.Is there a dumbed down explanation I could read for why Python does not really have pointers like C++ does?
Is there a dumbed down explanation I could read for why Python does not really have pointers like C++ does?
Languages have evolved since the 1980s. Most modern languages use references instead of pointers. It's basically doing the work for you - improving your productivity and eliminating the possibility of a class of bugs.
Jetman, take me in as your pupil.
"Evolution" sounds synonymous with "supeior". Garbage collection is not superior to explicit memory management. It serves a different need, and while it might be superior in some aspects, it is inferior in others.
I'm just using sublime with MinGW as my compiler. If I were to ever release an .exe for people to try out, I'm worried that they would need a specific library that makes cout work in C++. The name of the library is libstdc++-6.dll
For my .exe's to work, I need to include this file in my folder and I want to know if just using #include libstdc++-6.dll will work without it being in the folder.
You're right, evolution isn't about superiority. It's about the adaptations of populations to survive in a niche. But the niche for manual memory management has shrunk significantly. I don't know what CornBurrito wants to make, but chances are good he can jump on the GC/ARC train and never look back."Evolution" sounds synonymous with "supeior". Garbage collection is not superior to explicit memory management. It serves a different need, and while it might be superior in some aspects, it is inferior in others.
You're right, evolution isn't about superiority. It's about the adaptations of populations to survive in a niche. But the niche for manual memory management has shrunk significantly. I don't know what CornBurrito wants to make, but chances are good he can jump on the GC/ARC train and never look back.
The rich comparison is a way to get more control over a comparison between objects. In general your tiles will have some value (maybe in self.value?) which you can compare to tell if two tiles match by doing tile1.value == tile2.value.I don't really understand what rich comparison method is, despite looking it up. I could really use some help or just general direction to figure this out this matching problem. Thanks in advance GAF!
Sorry, I wasn't clear enough... It's an option for the compiler, so you have to put it in your gcc invocation line among other options.Would I write that in code or type that in the command prompt beforehand? I read the same thing on a forum and didn't quite understand where I needed to do this.
Not sure it's so common, since I've had this problem on all my Windows computers. Easy fix when you know what you're doing, especially if you have MinGW installed, but when you distribute the code, it make things more difficult. Windows support for shared libraries isn't great...but I would strongly advise using dynamic linking unless you have a very very good reason to use static linking. These libraries are installed by default on most peoples' systems anwyay.
It suggests you to define a class for tiles, and a way to compare different tiles.I don't really understand what rich comparison method is, despite looking it up. I could really use some help or just general direction to figure this out this matching problem. Thanks in advance GAF!
class CaseIndpString :
def __init__(self, string):
self.string = string
def __repr__(self) :
return 'CaseIndpString("'+self.string+'")'
def __str__(self) :
return self.string
...
In [329]: a = CaseIndpString('toto')
In [330]: b = CaseIndpString('toto')
In [331]: a == b
Out[331]: False
def __eq__(self, other) :
return other.string == self.string
In [334]: a = CaseIndpString('toto')
In [335]: b = CaseIndpString('toto')
In [336]: a == b
Out[336]: True
In [337]: b = CaseIndpString('Toto')
In [338]: a == b
Out[338]: False
def __eq__(self, other) :
return other.string.lower() == self.string.lower()
In [341]: a = CaseIndpString('toto')
In [342]: b = CaseIndpString('Toto')
In [343]: a == b
Out[343]: True
I tried using Swift for a week, but it's too painful to code without full type inference.
If you want to learn Swift, study Haskell for a few weeks first. Swift is great because it elegantly mixes a lot of functional concepts into a traditional C-family language. My problem is I jumped into the deep end of functional programming a couple months ago and it's painful to go back to object oriented programming. I definitely prefer Swift to C++ or Java because it at least meets me halfway.Yeah as mentioned elsewhere, Swift is very hard to wrap your head around if you are used to C++ or Java(like in my case).
I feel that if I wanted to seriously learn Swift I should step away from iOS development (the two go hand in hand in almost every tutorial I found) until I get a good feel of how it works.
func multiply(a: Float, b: Float, c: Float) -> Float{
return a * b * c
}
let multiply a b c = a * b * c
Bleh having issues with what resume template to use. One of my dev friends mentioned he used this.
https://jsonresume.org/
Tried it out and have tried the slick and simple themes. Unless there's a better template, I'm thinking I should just go with one of these templates and call it day.
edit: Nvm I need to highlight some other stuff 1st since I'm going entry level. Going to look around for a diff template I can completely customize instead. Gah this is frustrating. Also doesn't help I'm so picky and want it to be perfect lol.
Online-only? Otherwise moderncv with LaTeX.
I wanted to follow up this post with two clarifications for anybody reading.I agree it can be dauting the first time you do it, but honestly it's not that hard. And you're going to have to do this no matter if you're using Visual Studio, Makefiles, CMake, or anything else. The reason is that your program and the unit test runner are two separate executables that need to share the same code -- the code that is being tested.
The way you share code in this way is by creating libraries.
To get up and running the quickest, you can literally change your entire project to a static library. Right click the project node, choose Properties, click General, and set Configuration Type to Static Library (.lib). Change your main function to be called something else like RunProgram(), make a header file and declare RunProgram() in the header file. I'll just call this header file foo.h, but make it something more appropriate.
Now create a new project, this time an Application (.exe). But do it by right clicking the root node in Solution Explorer and choosing Add -> New Project. When VS finishes creating it, you'll now have two projects in the same solution. In your new application project, add a #include "foo.h", then in main() simply call RunProgram().
To make it automatically link the library into the application, right click the project node of the application, choose Build Dependencies -> Project Dependencies, and then click the checkbox for the library. You'll probably need to set the include directories in your exe project to find the folder where the include files for the library are. This is in Project Properties -> C/C++ -> General -> Additional Include Directories.
In a production environment, you would probably create a more realistic separation between your driver / application and your core functionality that you're testing, instead of simply having your main() function be one line that calls the static library. For example, command line parsing, user input, etc would all be handled in the application while processing and utility libraries etc would be handled in the library.
In any case, when you've got all this working, creating the unit test suite is not much different than the application. Make a new Application, add a dependency, go to the Linker and Include settings and add the appropriate paths for gtest, then #include files from your library and start using them in yoru tests.
One common solution for handling the situation with include file paths is for a project to do something like this:
Code:project |__ project.sln |__ src |__ application |__ main.cpp |__ application.vcxproj |__ library1 |__ lib1.cpp |__ lib1.vcxproj |__ library2 |__ lib2.cpp |__ lib2.vcxproj |__ include |__ application |__ library1 |__ lib1.h |__ library2 |__ lib2.h
Now, in every project, you set your Additional Include folders to $(SolutionDir)include. Then in your application.cpp, you can simply write something like this:
#include "library1/lib1.h"
#include "library2/lib2.h"
And it will automatically find it. This way you dont' have to go manually screw around with the include path settings for every single project. It's always exactly the same value for every project, just "$(SolutionDir)include".
Anyway this is a lot to take in the first time you do it, but it's fairly intuitive once you get used to it.
I wanted to follow up this post with two clarifications for anybody reading.
1. In VS2015 the include directories option is under Project > <PROJECT_NAME> Properties... > VC++ Directories
2. I had to add a reference to my program's library in my executable project. Right click the References listing in solution explorer > Add Reference > check your library > OK.
Not at my computer now either. I'll edit this post in an hour.1. Do not touch that setting. That's the wrong place. I'm not at my computer now but go back to my original instructions and see if you can make it work with what i wrote. If not i can write more when I'm not on mobile
Not at my computer now either. I'll edit this post in an hour.
I totally care and that's all amazing to know. Thank you so much.TL;DR - Don't use the one you used. Use Configuration Properties -> C/C++ -> General -> Additional Include directories.
Long explanation
So technically I guess it doesn't matter. But the place you've modified is a legacy holdover from old versions of MSVC, that has gradually changed throughout the years. The recommended way has always been to use the Additional Include Directories under C++. If you read the descriptions it gives a hint why:
The one you've set says:
Include Directories
Path to use when searching for include files while building a VC++ project. Corresponds to environment variable INCLUDE.
The other one says:
Additional Include Directories
Specifies one or more directories to add to the include path; separate with semi-colons if more than one (/I[path])
So the first one is setting an environment variable, and the second one is using a command line switch to the compiler. The second is better from a "purist" standpoint, because for example you could go to the Command Line tab, copy the command line out, run it, and get the same results as building from the IDE. Whereas if you use the other one you would get an error with the command line.
From a management standpoint, there's also one other benefit of using Additional Include Directories. Set your VC++ Directories / Include Directories to fff and set your C/C++ Additional Include Directories to sss. Now right click your main.cpp and hit properties. Notice there is no VC++ Include Directories here, only a C/C++ Additional Include Directories setting. And if you view it, it says sss. This is Visual Studio's property inheritance system, which is a really powerful way of specifying project settings. If you set something at the project level, it propagates down to all the children (i.e. source files), and you can override them on the individual file level if you want.
But if you use the first setting (the one I said not to use), it can't be overridden on a per-file level.
Anyway, you probably don't care about all of this stuff, but the point is, just get in the habit of doing it the right way, because one day it will make your life easier.
Thanks for the heads up. I googled around and read briefly about LaTeX but had no idea wtf it meant lol. So guessing this article should be a good start?. http://www.maxburstein.com/blog/creating-resume-using-latex/
edit: Or this?.
http://www.latextemplates.com/template/moderncv-cv-and-cover-letter
Also yay I don't have to deal with Word. I was dreading having to make a nice Word resume. Funny thing is I find reading that LaTeX text editor way more readable and fun now compared to Word. And I used to love typing up docs since English was my best subject in school.