Amerika’da Yazılımcılık – Vize Türleri

Merhaba arkadaşlar.

Bu yazıda Amerika’da çalışma izni sağlayan vize türlerinin en yaygın olanlarından bahsedeceğim. Bu yazı dizisi bilgisayar/yazılım mühendislerine yönelik olsa da vize türleri konusu çoğu meslek için aynı. Ancak şunu da söylemem lazım, burada anlatılanlar kısa bilgilendirmelerden ibaret olacak. Her bir seçenek için detaylı kurallar ve geçmeniz gereken süreçler olduğunu unutmayın.

F1 üzerinden OPT

Amerika’da bulunan Türklerin büyük bir kısmı F1 yani öğrenci vizesine sahip. F1 vizesinin nasıl alındığına çok girmeyeceğim ama özetle ABD’de belli şartları sağlayan yükseköğretim kurumlarından birisinden kabul alıp vizeye başvuru/onay süreçlerini tamamlamanız gerekiyor. ABD’de bir yükseköğretim kurumunda öğrenim gördüğünüz sırada veya mezun olduktan sonra OPT (Optional Practical Training) denilen ve size geçici olarak çalışma hakkı sağlayan bir programdan faydalanabiliyorsunuz. Burada önemli olan bir detay şu: çalıştığınız iş okuduğuz alanla direk alakalı olmalı. Zaten bu programın amacı da öğrencilere okudukları alanla ilgili iş tecrübesi kazandırmak. Alternatif olarak okuduğunuz alanla ilgili bir iş fikriniz varsa kendi şirketinizi de kurabilirsiniz. Ancak bu prosedürü daha ağır bir seçenek olduğu için çok iyi araştırmak ve planlı olmak şart.

OPT ile çalışma hakkınız 12 ay, ancak belli bölümlerde okuyan/mezun olmuş kişiler bunu 24 ay daha uzatabiliyorlar. Bu uzatmayı alabilmek için çalıştığınız şirketin de E-Verify denilen sistemi kullanıyor olması gerekmekte. Bu sebeple eğer OPT alıp sonra da uzatmak gibi bir planınız varsa işvereni buna göre seçmek gerekiyor. Hangi bölümlerde okuyanların bu uzatma hakkına sahip olduğunu öğrenmek için buraya bakabilirsiniz. (Spoiler: çoğu mühendislik, bilgisayar, programlama, yapay zeka vs alanlarında okuyanlar bu uzatma hakkına sahip)

OPT ile ilgili önemli başka bir konu da zamanlama. OPT programına belli zaman aralıklarında başvuru yapabiliyorsunuz. Yani okul bitsin de bakarız gibi bir hataya düşmeyin. Mutlaka okulunuzla görüşüp bu detayları öğrenin ki sonra başınız ağrımasın. Bu zamanlama konusu ve OPT programıyla ilgili diğer güncel bilgileri bu sayfadan görebilirsiniz.

Şunu da söylemek lazım, OPT bir vize değil. F1 vizesine sahip ve gerekli koşulları sağlayan öğrencilere geçici olarak çalışma hakkı sunan bir program. Eninde sonunda bu süre biteceği için, eğer ABD’de kalıp çalışmaya devam etmek istiyorsanız OPT ile çalışırken H1-B gibi bir çalışma vizesine geçmeniz gerekiyor. Bir sonraki başlıkta bunu inceleyeceğiz.

H-1B

H-1B ABD’de geçici olarak çalışma hakkı sağlayan bir vize türü. Bu vize ancak işveren sponsor olursa alınabiliyor, yani bireysel olarak başvuramıyorsunuz. Tabi her meslek de bundan faydalanamıyor. En azından lisans seviyesinde bir eğitim seviyesi gerektiren bir meslekse ve siz de bu meslekte yetkin olduğunuzu bir diploma vs. ile kanıtlayabiliyorsanız o zaman bir şirket size sponsor olup bu vizeyi alabiliyor. Bu diplomanın ABD’deki bir eğitim kurumundan alınmasına gerek yok. Türkiye’de aldığınız diploma yeterli olabiliyor ancak bu durumda başvuru sırasında denklik alabilmek için ek evraklar sunmanız gerekiyor.

Bu vizenin problemli taraflarından bir tanesi her sene belli bir kotası olması. Her sene 65 bin lisans, 20 bin de yüksek lisans eğitimi gerektiren pozisyonlar için toplamda 85 bin vize veriliyor. Son senelerde bu vizeye olan aşırı talepten ötürü, dağıtılacak 85 bin vize için bunun çok daha fazlası başvuru kabul ediliyor ve sonrasında kurayla değerlendirilecek 85 bin başvuru belirleniyor. Maalesef kurada çıkmayanlar şansına küsüp bir sonraki seneyi bekliyor. Nisan ayının ilk iş günü açılan başvurular genelde birkaç gün sonra kapanıyor, yani başvuru yapabileceğiniz (şirket avukatları aracılığıyla) aralık çok da geniş değil. Dolayısıyla bunu önceden planlamak en iyisi. Unutmadan söyleyelim, bu bahsettiğim kotadan muaf olan bir iki istisna sektör de var. Yükseköğretim kurumları veya kar amacı gütmeyen kuruluşların bazıları bu kotadan muaf olarak vize alabiliyorlar.

H-1B vizesi belli bir şirketin sponsorluğunda alınsa da, iş değiştirmek isterseniz başka bir şirket bu vizeyi transfer ederek sizi işe alabiliyor. Bu sıfırdan vize almak kadar zor bir olay değil, yukarıda bahsettiğim kotadan da etkilenmiyor. Bir kere vizeyi aldıktan sonra uzatma ve transfer işlemlerinde kotaya tabi olmuyorsunuz, ancak yine de geçmek istediğiniz şirketin bu transferi yapması ek bir yük olduğu için her şirket bunu yapmıyor. Mülakatlar sırasında insan kaynakları ve işe alım müdürü ile görüşürken bunu mutlaka teyit etmenizi öneririm.

H-1B vizesi size 6 senelik bir çalışma hakkı tanıyor. İlk seferde 3 senelik bir vize alıyorsunuz, sonrasında tekrar 3 seneliğine yenileyebiliyorsunuz. Vizenizi başka bir şirkete transfer ettirseniz de süre baştan başlamıyor, toplam süre 6 sene. Eğer 6 sene dolmadan yeşil kart (green card) başvurusu yaparsanız, yeşil kartınız çıkana kadar yine ek uzatma alabiliyorsunuz. Aksi taktirde bu sürenin sonunda çalışma hakkınız dolmuş oluyor ve tekrar başvurabilmek için en az bir yıl süreyle ABD dışında yaşamanız gerekiyor

L1

L1 vizesi yine şirket sponsorluğu ile alınan bir vize ancak H-1B ile çok farklı. Eğer ABD’de iş yapan bir şirketin ABD dışındaki bir ofisinde çalışıyorsanız, şirket size L1 vizesi alarak ABD ofisine taşıyabiliyor. Tabi her çalışan bu olanaktan faydalanamıyor. Şirkette belli bir süre çalışmış olmanız ve belli bir alanda uzmanlaşmış olmanız olmanız gerekiyor. Bunun başka kuralları da var tabii ki ama genel olarak özellikle Amazon, Microsoft gibi büyük şirketler bu yolla çok sayıda çalışanını ABD’ye getiriyor. Bunun da aslında iki çeşidi var. L1-A yönetici pozisyonundaki kişileri ABD’ye transfer etmek kullanılıyor ve 7 seneye kadar uzatılabiliyor. L1-B ise diğer pozisyonlar için geçerli oluyor ve 5 seneye kadar uzatılabiliyor. Ek olarak, eğer ABD dışında iş yapan bir şirketiniz varsa ve ABD’de bir ofis açmak istiyorsanız yine bu vizeden faydalanarak eleman göndermek mümkün olabiliyor.

Bu vizenin H-1B’den farklı başka tarafları da var. İlk olarak L1 vizesi alıyorsanız H-1B’de olduğu gibi bir kota veya çekiliş falan yok. Çalıştığınız şirket ve siz çalışan olarak gerekli şartları sağlıyorsanız bu mümkün olabiliyor. Ancak işin kötü tarafı ABD’ye geldikten sonra aynı şirkette çalışmak zorundasınız. H-1B’de olduğu gibi transfer ettirip başka bir şirkete geçeyim diyemiyorsunuz. Başka bir şirkete geçmeniz için şirketin size H1-B veya yeşil kart alması gerekiyor.

Ve diğerleri

Şimdiye kadar bahsettiğimiz vize türleri en yaygın kullanılanlar ancak bundan çok daha fazlası var. Örneğin bir şirket sahibi veya yatırımcı iseniz ve ABD’de istihdam yaratacak bir iş fikriniz varsa E sınıfı vizeler, üstün yetenekli bir atlet, bilim adamı veya sanatçı iseniz O sınıfı vizeler mevcut. Daha fazla bilgi için bu adrese bakabilirsiniz.

Tekrar söylemek istiyorum ki burada anlatmaya çalıştıklarım tamamen bilgilendirme amaçlı ve kulak dolgunluğu olması açısından faydalı olabilir. Her biri için karmaşık süreçlerden geçmeniz gerekiyor ve zaten bu vizeleri almak için şirket avukatları ile çalışıyorsunuz. Onlar sizi daha doğru yönlendirecektir.

Dikkat ederseniz bu çalışma vizelerinin hepsinde bir zaman sınırı var. Zaten bunlar geçici işçi kategorisinde belirli bir süre için verilen haklar. Eğer siz ABD’de kalıcı olmak istiyorsanız yeşil kart almanız gerekiyor. Bunun da çeşitli yolları var, bir sonraki yazıda bunu konuşalım.

Kaynakça

https://www.ice.gov/sites/default/files/documents/Document/2016/stem-list.pdf

https://www.uscis.gov/working-in-the-united-states/temporary-nonimmigrant-workers

https://www.uscis.gov/working-in-the-united-states/temporary-workers/h-1b-specialty-occupations-dod-cooperative-research-and-development-project-workers-and-fashion

https://www.uscis.gov/working-in-the-united-states/students-and-exchange-visitors/optional-practical-training-opt-for-f-1-students

Share

Effective Java Madde 49: Parametrelerin Geçerliliğini Kontrol Edin

Çoğu metot ve yapıcı metot parametre geçilen değerler için kısıtlamalar koyar. Örneğin dizin (index) değerlerinin pozitif tamsayı olması ve nesne referanslarının null olmaması gibi kısıtlamalarla sıklıkla karşılaşırız. Bu kısıtlamaları metot gövdesinin başında uygulamalı ve açıkça belgelemelisiniz. Bunu yaptığımız taktirde hataların olabildiğince erken saptanması mümkün olabilir, aksi taktirde bunu geciktirmiş oluruz ve bir hata ile karşılaştığımızda nereden kaynaklandığını bulmak zorlaşır.

Bir metoda geçersiz bir parametre verildiğinde, eğer metot kod işletimine başlamadan önce parametrelerin geçerliliğini kontrol ediyorsa erkenden hata üretecek ve mantıklı bir aykırı durum fırlatarak işletimi durduracaktır. Bunu yapmadığı taktirde birkaç farklı durumla karşılaşabiliriz. Birincisi uygulamanız işletimin farklı bir yerinde kafa karıştırıcı bir aykırı durum fırlatabilir. Daha kötüsü, metot işletimini tamamlar ancak yanlış bir sonuç üretebilir. En kötüsü ise bir nesnenin durumunu bozarak ileride tamamen alakasız bir kod parçası işletilirken hataya yol açabilir.

public ve protected erişim belirtecine sahip metotlar için Javadoc’un @throws etiketini kullanarak parametreler geçersiz olduğunda fırlattığınız aykırı durumu belgeleyebilirsiniz. (Madde 74) Genellikle bu aykırı durumlar IllegalArgumentException, IndexOutOfBoundsException, veya NullPointerException olacaktır. (Madde 72) Metot parametrelerine getirdiğiniz kısıtlamaları ve bu kısıtlamalara uyulmadığı taktirde fırlatacağınız aykırı durumları belgeledikten sonra, bunu koda dökmek çok basit olacaktır. İşte bir örnek:

/**
* Metodun yaptığı hesaplamanın detayları..
*
* @param m (modulus), pozitif olmalı
* @return this mod m
* @throws ArithmeticException m sıfıra eşitse veya daha küçükse
*/
public BigInteger mod(BigInteger m) { 
    if (m.signum() <= 0) { 
           throw new ArithmeticException("Modulus <= 0: " + m);
    }
    ... // Hesaplama kodu
}

Dikkat ederseniz bu metot m == null ise NullPointerException üretecektir ancak biz metodu belgelerken bundan bahsetmedik. Bu aykırı durum metodun içinde bulunduğu BigInteger sınıfının kendi dokümantasyonunda belgelenmiştir, bu sebeple metot için tekrar yazmaya gerek yoktur. Bu yöntemi kullanarak sınıf içindeki her bir metot için ayrı ayrı NullPointerException belgelemekten kaçınabilirsiniz.

Java 7 ile dile eklenen Objects.requireNonNull metodu null kontrolü için esnek ve kolay bir seçenek sunmaktadır. Bu sebeple null kontrolünü kendiniz yapmanıza gerek yoktur. Bu metot aykırı durum için istediğiniz bir mesajı geçmenize izin verir ve geçtiğiniz parametreyi geri döndürdüğü için değer ataması yaparken de kullanabilirsiniz:

// Java'da null denetimi için örnek kullanım 
this.strategy = Objects.requireNonNull(strategy, "strategy");

Tabii ki isterseniz bu geri dönüş değerini yok sayabilirsiniz ve sadece null kontrolü için kullanabilirsiniz.

Java 9’la birlikte java.util.Objects sınıfına checkFromIndexSize, checkFromToIndex ve checkIndex gibi aralık kontrolü (range checking) yapan metotlar da eklenmiştir. Bunlar her ne kadar requireNonNull kadar kullanışlı ve esnek olmasa da ihtiyacınızı karşıladığı taktirde kullanabilirsiniz.

Dışarıya açık olmayan metotlar için (private ve package-private), istemcinin kontrolü tamamen elinizde olacaktır. Bu metotların parametrelerini denetlemek için assert anahtar kelimesini kullanabilirsiniz.

private static void sort(long a[], int offset, int length) {
    assert a != null;
    assert offset >= 0 && offset <= a.length;
    assert length >= 0 && length <= a.length - offset; 
    ... // Metot gövdesi
}

Esas itibarıyla bu assert ifadeleri, belirtilen koşulun doğru (true) olması gerektiğini simgelerler ve istemcilerin paketinizi nasıl kullandığından etkilenmezler. Normal geçerlilik kontrollerinin aksine, assert ifadeleri eğer true üretmezlerse AssertionError hatası fırlatırlar. Assert ifadeleri bilinçli olarak etkinleştirilmedikleri sürece devre dışı olurlar, aktifleştirmek için java komutuna -ea (veya -enableassertions) parametresini geçmek gerekir. Bu ifadelerle ilgili daha fazla bilgi için buraya bakabilirsiniz.

Eğer bir metot geçilen parametreleri kendisi kullanmıyor ancak daha sonra kullanılmak üzere bir alanda saklıyorsa, bu parametrelerin geçerliliğini denetlemek daha büyük bir öneme sahip olmaktadır. Örneğin Madde 20‘de yazdığımız, parametre olarak bir int dizisi alıp bu dizinin List görünümünü döndüren intArrayAsList isimli statik fabrika metodunu hatırlayalım. Bu metoda istemci null geçerse, Objects.requireNonNull denetiminden dolayı NullPointerException fırlatılacaktır. Bu denetimin koddan çıkartıldığını varsayarsak, metod bir List döndürecektir ancak istemci bunu kullanmaya çalıştığı anda NullPointerException hatası alacaktır. Ancak istemcinin kullanım anında bu List nesnesinin kaynağını anlamak kolay olmayabilir ve bu hatanın çözülmesini güçleştirebilir.

Bazı durumlarda ise bir hesaplama yapmak için kullanacağımız parametrelerin geçerliliğini önceden kontrol etmek çok da mantıklı olmayabilir. Buna örnek olarak, kendisine verilen nesneleri sıralayan Collections.sort(List) metodunu verebiliriz. Sıralamanın yapılabilmesi için verilen listedeki nesnelerin birbiriyle karşılaştırılabilir olması gerekmektedir. Eğer sıralama esnasında buna aykırı bir durum bulunursa ClassCastException hatası üretilecektir ve aslında sort metodunun yapması gereken de budur. Dolayısıyla, listedeki elemanları birbirleriyle karşılaştırılabilir olup olmadığını önceden kontrol etmek bize çok bir fayda sağlamayacaktır.

Bu maddeden metot parametrelerine zorunlu olmayan kısıtlamalar koymanın iyi bir şey olduğu sonucunu çıkartmayın. Tam tersine, metotlarınız geçilen parametre değerleriyle mantıklı bir işlem yapabildiği sürece kısıtlamalardan kaçınmaya çalışın ki daha geniş bir kullanım alanı bulabilsin.

Özetle, bir metot veya yapıcı metot yazarken parametreler üzerinde ne gibi kısıtlamalar olması gerektiğini iyice düşünün. Bu kısıtlamaları belgeleyin ve metodun hemen başında gerekli denetimleri uygulayın. Bunu bir alışkanlık haline getirmek önemlidir. Sarf edeceğiniz bu küçük çabanın karşılığını geçerlilik denetimleri hata bulduğu zaman fazlasıyla alacaksınız.

Share