A lot of other answers are going over the various problems with your solution. I'd like to focus my answer on how to approach coding from a better angle - let me discuss why I would frown at hiring you from the code sample you provided.
vector<int> findPrime(int[] input, int size){
vector<int> output;
for (int i= 0; i < size; i++){
for (int j= 0; j < input[i]; j++){
if(input[i]%1== 0 && input[i]%j == 0){
continue;
}
if (i== j){
output.push_back(input[i]);
}
}
}
return output;
}
Okay, so let's start at the top: your function name: 'findPrime'. Does this function find a prime? No, it finds all the primes in a list. Your function name isn't merely bad, it's downright lying. Seeing the name, I'd expect it to find a prime number, or failing that, to check whether a given number is prime. I certainly wouldn't expect it to pass back a filtered output based on which input numbers were prime!
- So element number one you need to keep in mind: Making sure you name your functions something that accurately describes what they do.
Next up, and related to that first element: your variable names. Take a look at your variable names: input, size, output, i, and j. Input and Output aren't terrible, but why 'size'? Why not 'inputSize' or 'inputArrayLength' or something that actually describes what data it holds? Likewise, you shouldn't be using single-letter loop counters if the loop is more than 1-2 lines long.
And that actually comes back to bite you! This error was pointed out in a few answers:
if (i== j){
But this mistake isn't easy to spot. The reason it's not easy to spot is because you used useless variable names, so it's not immediately obvious there's a problem here. But what if I changed your code to:
for (int arraySlotNum= 0; arraySlotNum < inputArrayLen; arraySlotNum++){
int valueToCheck = input[arraySlotNum];
for (int divisorToTry= 0; divisorToTry < valueToCheck; divisorToTry++){
if(valueToCheck%divisorToTry == 0){
continue;
}
if (arraySlotNum== divisorToTry){
output.push_back(valueToCheck);
}
}
}
... suddenly, that particular bug seems a bit more obvious - why would you be comparing the divisorToTry with the arraySlot? The other bugs become a bit more noticeable as well.
Also notice: I added a variable that you didn't have. Technically, I could've put 'input[arraySlotNum]' whereever I would've put 'valueToCheck'... but by adding that variable, I helped document what my code is doing.
- So Element #2 is... actually use good variable names. I'd suggest getting into the practice of not using single-name variables at all until you've formed a good habit of using appropriate variable names. It's not gonna hurt you to use a longer variable name. And you've seen that it can definitely hurt you if you don't!
Third, your function composition - your code architecture. What does your function, as-intended (not necessarily as-written), do?
- it loops through the collection of elements
- for each number, it begins a second loop from 2 to the value-1, and gets a modulo.
- if the number divides cleanly, it adds it to the output
... here's the problem: you've got code in this function that determines whether a number if prime or not. Don't you think that deserves its own function?
This is NOT a minor point. If I had two candidates, one who wrote:
vector<int> filterForPrimes(int[] input, int size)
{
for (int i=0; i < size; i++)
{
// code for correctly determining whether input[i] is prime embedded inline
// add to output if prime
}
}
... vs the second who wrote ...
vector<int> filterForPrimes(int[] input, int size)
{
for (int i=0; i < size; i++)
{
if (isPrime(input[i]))
{
// add to output
}
}
}
bool isPrime(int numberToTest)
{
// terribly inefficient method of checking for a prime goes here.
}
... I'd rather have the second applicant. Oh, sure, the method for checking a prime number sucks. But it shows that they've got the ability to actually structure their code appropriately - and it means that their codebase is likely going to be much easier to work with and improve.
I mean, let's say the boss screams "The prime checking is too slow! Use the Sieve of Eratosthenes algorithm on it!" All I have to do in the second example is look at the isPrime and optimize it so that, given an input value, it quickly determines whether it's prime. In the first example, I have to consider how all the code I'm changing affects everything else in the function its embedded within.
- So element number three you need to keep in mind: spend some time trying to figure out how to break things into nice clean functions. Remember SRP (Single Responsibility Principle). Read Clean Code by Robert Martin (or reread; this is the sort of book that programmers should re-read every year or two.)
