Parsing length of work experience using Composite design pattern
You wrote this:

    Pattern p = Pattern.compile("\\d+miesi[e|ę]cy|\\d+ miesi[e|ę]cy");


but it would be more natural to express it without alternation:

    Pattern p = Pattern.compile("\\d+\\s*miesi[e|ę]cy");


I wonder if you maybe wanted to throw in a CASE_INSENSITIVE | UNICODE_CASE flag.

public interface ExperiencePattern {


Many projects would choose to spell this IExperiencePattern.

DRY - don't repeat yourself. It seems odd that you have a pair of copy-n-pasted identical classes with different Pattern constants, rather than one class that accepts a Pattern parameter.

        tmp = tmp.replaceAll("\\D", "");


Thank you for teaching me about the "non-digit" pattern. But the more natural way to express your intent would be to delete this, and put a capture group in your regex:

    Pattern p = Pattern.compile("(\\d+)\\s*miesi[e|ę]cy");


Then Integer.parseInt(m.group(1)) gives you exactly what you want.

        if (x &lt; 40) {
            result = x * 12;


Ok, I guess in a straight refactor you would need to pass in two parameters, a Pattern and also maxAcceptableValue. But it's probably better to stick with a single parameter and let the caller do range checking.

public interface Algorithm &lt;T&gt; {

    public T calc(String textToLower);


Both of those identifiers are hopelessly vague. Give the Gentle Reader a clue, please. Also, adding some /** javadoc */ would help.

public ExperienceAlg0(List&lt;ExperiencePattern&gt; list){
    listPatterns = list;
}


It is customary in a ctor to explicitly mention "this": this.listPatterns = list;

    for(ExperiencePattern ep : listPatterns) {
        result.add(ep.getPattern(text));
    }


This is perfectly lovely. But generalizing to exactly 2 cases is maybe on the small side. Rather than this loop, I encourage you to hoist the range check test up to this location, which will feature a pair of nearly identical calls using each of your patterns.

    Collections.sort(result, new DescendingComparator());
    return result.get(0);


That's cool. I like it. Very clean way to discard chaff.

You asked if the design is OK according to OOP. Well, that would be easier to evaluate if you added one-sentence javadocs at top of each class, explaining the single responsibility of that class, especially for any interface classes. That would e.g. help a reader pin down which layer the range-checking belongs in.