Açık ilanlar
Üç ilan açık. Her biri, ürünün yanlış olabileceği belirli bir yer için.
Üçünün ortak yanı şu: hiçbiri bir ekip büyütme kararı değil; her biri, ürünün yanlış olabileceği belirli bir yer. Her ilan o yerle başlıyor, orada ne yapılacağıyla sürüyor ve size sorulan üç soruyla bitiyor. Deneyim eşikleri pazarlık konusu değil ve sebepleri ilanların içinde yazılı. Sorular da süsleme değil: başvuru formundaki tek zorunlu uzun alan, seçtiğiniz ilanın sorularına verdiğiniz cevap.
Yapay Zekâ / Makine Öğrenmesi Mühendisi
İstanbul veya uzaktan · tam zamanlı
Ürünün en kırılgan yeri, serbest metinden yapı çıkarılan yer. Bir sözleşme maddesi, bir yazışma, bir saha tutanağı — hiçbiri sizin için etiketlenmiş gelmiyor, ve bunlardan çıkarılan her alan bir hükmün girdisi oluyor. Yanlış çıkarılmış bir bildirim tarihi, yukarıda anlatılan kontrollerin hepsinin doğru çalıştığı bir sistemde bile yanlış bir sonuç üretir; çünkü o kontroller hesabı korur, girdiyi değil.
Bu yüzden burada model çıktısı cevap değil, dayanağı iliştirilmiş bir öneri. Çıkarılan her alanın metindeki yeri geri gösterilebilir olmak zorunda; emin olunmayan yerde sistem makul bir değer basmak yerine boş dönüyor, ve bu tercih ürünün üç ayrı yerinde zaten kodlu. Yazacağınız işin büyük kısmı bu: bir dil modelinin ürettiği şeyi, ona ne zaman güvenilmeyeceğini bilen bir yapıya bağlamak. Senaryo tarafında da aynı ayrım geçerli — üretilen bir sayı, hangi varsayımdan geldiğini taşımadan ekrana çıkamıyor.
Zorunlu
En az 5 yıl yapay zekâ / makine öğrenmesi deneyimi. Bu eşik esnetilmiyor: burada verilecek kararların çoğu bir modelin ne zaman yanıldığına dair, ve o sezgi okuyarak değil, yanılmış modellerle çalışarak ediniliyor.
Ayrıca aranan
Yapılandırılmamış hukuki ya da teknik metinden alan çıkarmış olmak; bir çıkarım hattını, kendi hesapladığı sayıyla değil bağımsız bir kontrolle sınamış olmak; bir modelin cevabını reddedip kural tabanlı bir yola düşmenin ne zaman doğru olduğuna dair yazılı bir görüş. Hiçbiri şart değil.
Başvururken cevaplayacağınız üç soru
- Yapılandırılmamış bir metinden alan çıkarırken modele ne zaman güvenmeyi bırakırsınız — ve bu kararı hangi ölçüme dayandırırsınız?
- Elinizde bir doğruluk sayısı var ve altındaki hataların hepsi aynı madde türünden geliyor. Sayıyı mı düzeltirsiniz, hattı mı? Neden?
- Kural tabanlı bir çözümün model tabanlı olandan daha doğru olduğu bir iş anlatın. Orada kuralı kazandıran neydi?
Sözleşme Mühendisi
Danışman veya tam zamanlı · konum esnek
Bu üründeki her hüküm, sonunda bir sözleşme okumasına dayanıyor. Bildirim sözlüğündeki her maddenin tetikleyici olayı, gideceği taraf, gün sayısı ve gecikmenin sonucu yazılı — ve bunların hepsi, bir yerde birinin okuyup karar verdiği şeyler. Yazılımın en tehlikeli tarafı da burası: yanlış bir okuma, kod doğru çalıştığı sürece hiçbir yerde hata olarak görünmez. Kendinden emin bir çıktı olarak görünür.
Aranan kişi bu okumanın sahibi. İş, ürünün sözleşme mantığını FIDIC karşısında satır satır denetlemek: hangi maddenin neye bağlı olduğunu, bir hak talebinin hangi eşikte doğduğunu ve ürünün ürettiği çıktının bir uyuşmazlıkta savunulabilir olup olmadığını söylemek. Bu bir gözden geçirme rolü değil — itiraz ettiğiniz şey değişiyor, ve neden değiştiğinin kaydı kalıyor. Yazılımı yazan taraf sizin dilinizi öğrenmek zorunda; sizin kod yazmanız gerekmiyor.
Zorunlu
En az 15 yıl sözleşme mühendisliği veya hak talepleri mühendisliği deneyimi. Eşiğin sebebi kıdem değil maruziyet: bir maddeye dair okumasının karşı tarafça reddedildiğini görmüş biri, o okumayı başka türlü anlatıyor.
Ayrıca aranan
FIDIC dışında en az bir standart form ailesiyle çalışmış olmak; bir hak talebini hazırlayan tarafta da değerlendiren tarafta da bulunmuş olmak; kaçırılmış bir bildirim penceresinin sonucunu evrak üstünde değil sonucunda görmüş olmak. Hiçbiri şart değil.
Başvururken cevaplayacağınız üç soru
- İşveren, işi yavaşlatan bir talimatı sözleşme değişikliği saymıyor. Yüklenici tarafındasınız ve bildirim penceresi hâlâ açık. İlk yazdığınız cümle nedir?
- Yazılım bir maddeyi sizin okuduğunuzdan farklı okuyor ve çıktı yüklenici lehine çıkıyor. Ne yaparsınız — ve bu kararı hangi belgeye dayandırırsınız?
- Bir hak talebinde en sık hangi kanıt eksik kalır, ve o eksikliğin sebebi genellikle nedir?
İnşaat Mühendisi
Danışman veya tam zamanlı · konum esnek
Bir yazılımın saha konusunda yanlış olması, sahada olmayan bir sırayı varsaymasıyla başlıyor. İlerleme oranı ile fiziksel gerçekleşme aynı şey değil; bir metraj, ölçüldüğü ana ve yönteme bağlı; bir imalatın tamamlanmış sayılması, sözleşmenin değil şantiyenin kabul ettiği bir eşik. Ürün bu ayrımların hepsini bir yerde varsayıyor, ve varsayımların doğruluğu ancak bu işi yapmış biri tarafından ölçülebilir.
İş, ürünün saha tarafını gerçeklikle karşılaştırmak: hakediş aritmetiğinin girdilerini, metraj kabullerini, imalat sırasını ve bir ilerleme ölçümünün gerçekte ne anlama geldiğini denetlemek — ve nerede işi kolaylaştıran bir uydurma varsa adını koymak. Bir ekranın makul görünmesi yetmiyor; o ekranın önerdiği şeyin bir şantiye şefinin imzalayabileceği bir şey olması gerekiyor. Sözleşme tarafındaki denetimden bilerek ayrı duruyor, çünkü ikisi farklı şeye kör.
Zorunlu
En az 15 yıl inşaat mühendisliği deneyimi, bu sürenin saha tarafında geçmiş olması kaydıyla. Eşik bir kıdem işareti değil: bir imalat sırasının neden bozulduğunu ofisten okuyarak öğrenen biri, o sırayı bozan şeyi bir modelin içinde tanıyamıyor.
Ayrıca aranan
Hakediş hazırlamış ya da değerlendirmiş olmak; bir metraj uyuşmazlığının iki tarafında da bulunmuş olmak; bir ilerleme raporunun neyi gizleyebildiğini yerinde görmüş olmak. Hiçbiri şart değil.
Başvururken cevaplayacağınız üç soru
- Saha gerçeği ile yazılımın modeli çeliştiğinde hangisi kazanır? Kazandığı hâlde yanlış olduğu bir durum anlatın.
- Bir ilerleme raporunun doğru görünüp yanlış olduğu en sık durum nedir, ve bunu nasıl yakalarsınız?
- Bir metraj uyuşmazlığında hangi belgeye bakarsınız — ve o belge yoksa ne yaparsınız?
Başvurular tek bir e-posta hâlinde info@valeurtechnology.com adresine ulaşıyor ve kurucu tarafından okunuyor.
Valeur.