Gimana sih Rasanya Interview untuk Posisi Frontend Developer?

Satu dua tahun belakangan ini mungkin bukan merupakan tahun-tahun terbaik karir saya karena dua kali terpaksa harus mencari pekerjaan baru sebagai software developer: satu karena kena lay-off (employer gagal gaet investor), yang satu lagi karena kontrak tidak diperpanjang (akibat pandemi COVID-19). Dan jujur saja, bagian yang paling tidak saya sukai dalam masa-masa job searching adalah proses interview-nya. Sangat. Menguras. Tenaga.

Artikel ini saya tulis atas request Mas Azam “Udah Solat?” sewaktu ngobrol-ngobrol soal kerjaan. Yasudah coba saya tuangkan pengalaman interview saya dengan salah satu payment platform terbesar di Belanda (sebut saja XXX) untuk posisi frontend developer sedetil dan sepadat mungkin di artikel ini. Ingin juga share pengalaman interview dengan perusahaan lain, tapi saya rasa proses interview dengan XXX sendiri sudah cukup mewakilkan. Saya akan banyak gunakan format list dalam menyantumkan poin-poin atau pertanyaan-pertanyaan saat interview agar lebih straightforward.

Kita mulai dari tahapan interview. Pada umumnya proses interview posisi frontend developer (mungkin posisi lain juga sama) dapat terbagi menjadi empat tahapan:

1. “Say Hello” interview
2. Technical assignment
3. Technical interview
4. Final interview

Setiap perusahaan mungkin memiliki urutan dan nama yang sedikit berbeda. Tapi dari pengalaman saya beberapa kali interview di berbagai perusahaan, hampir semua menggunakan format ini.

”Say Hello” Interview

”Say hello” bisa saja terdengar santuy, tapi interview ini adalah gerbang ke tahap selanjutnya karena pihak perusahaan akan menilai kepribadian, pengalaman kerja, preferences, dan motivasi kita (why join us?). Jadi harus dipersiapkan secara matang. Pernah sekali saya gagal di tahap ini karena pada waktu itu tidak menyiapkan materi apa-apa. Ketika interview, jawaban-jawaban yang saya lontarkan terdengar dibuat-buat, tidak otentik, dan kurang berbobot. Keluar ruang interview, saya sudah tahu jawabannya tanpa harus menunggu email dari mereka lagi.

Mulai saat itu saya selalu membuat dokumen khusus tentang poin-poin yang akan saya sampaikan ketika interview. Bisa tiga jam sendiri menulisnya. Agak lebay sih memang. Padahal interview ini biasanya hanya berlangsung selama 30 menit saja. Tapi kan siapa yang tahu 🤷🏽

Berikut saya cantumkan outline dokumen persiapan saya saat apply ke XXX 👇🏻

About me:

• I’m a software developer with ~5 years of experience, proficient in building complex web applications. I have extensive experience with React and Typescript ecosystem. And I’m excited to be applying for the frontend developer position at XXX!
• Working at YoungCapital at the moment
  • Mostly maintain the legacy projects: refine, refactor, write a lot test cases to capture business rules and behaviours
  • Develop green projects (one-cockpit, voice, peer feedback)
  • Introduce TS to frontend folks
  • Migrate some apps to Typescript to better document how the data moves
• Previous experience: I was as well exposed to some backend work, I was a fullstack developer. I handled Laravel for quite a year, did some side projects with Slim framework 3, Redis clustering, big database migrations, maintained several Node.js projects
• Things I like: Functional programming, Domain Modelling, Testing, Type-Driven Development

Projects I’ve worked on:

• Product Management System (forms, tables, computations, live data)
• Webshop gifting (different incentives on different times & locations)
• Labor rules: legacy project. Shows so many fields that some of them depend on another field change
• Voice, Peer feedback -> TS (almost zero runtime errors)

Why XXX:

• Big, international company. You said you have 85+ different nationalities. When you work within an international team, you can learn so many things that are outside your main job/function: languages, cultures, backgrounds, personalities etc. When you know and work with different types of personalities and backgrounds, you tend to be more open to ideas.
• Impact. I care about what my next destination would be. I care about working at a company that delivers huge impacts and benefits to others. I believe XXX is giving good impacts to merchants all over the world. By working at XXX, I want to see the impact yada yada yada…
• Culture. You say on the website that one of XXX’s cultures is to launch and iterate fast. That also works well for me since I’ve developed my career in agile culture. So working under a culture that is already familiar to you I think, is always a good thing.
• Explicit communication. I love writing explicit code, and I’d like to see the same explicitness in real life, in team work, and in communication. I like when people talk to me directly, in an honest way, I don’t have any problems receiving feedback. I’m all open. That being said, if you’re embracing explicit communication, teamwork could be much better. I’m a team player. I’m used to working with colleagues across departments, taking initiative to talk to them to better know their requirements. Sometimes, if not often, it’s quite effective to just cut the line.
• Complex domain. TBH I don’t know much about how a payment is done under the hood, but I could imagine it involves a lot of factors, a lot of business rules, and some edge cases here and there. I’m accustomed to building such applications, and more importantly, I love doing it.
• etc…

Preferences:

• I’d like to be more exposed to backend technologies:
  • I don’t want to limit myself in one field, I want to expand my knowledge as well
  • Sometimes it’s good when you can help other team members. Or when you’re out of tickets
• Avoiding too many context switchings (i.e handling a number of projects at the same time)
• Working in agile environment
• etc…

Kalau dari pihak mereka sendiri, selain memperkenalkan tim dan cara kerja sehari-hari, mereka juga akan menanyakan hal-hal dasar seperti:

• Tinggal dimana sekarang?
• Kenapa mau relokasi?
• Tau perusahaan ini darimana?
• Kenapa mau apply? Adakah yang membuatmu kurang nyaman di tempat kerja sekarang?
• Pernah handle proyek apa aja?

Yaa lebih ke arah ta’aruf aja 🙂

Technical Assignment

Setelah lolos interview tahap awal, pihak perusahaan biasanya akan memberikan technical assignment untuk melihat kemampuan pemecahan masalah kita dengan code. Assignment ini sifatnya homework, jadi bisa dilakukan saat weekend.

Beberapa assignment yang pernah saya buat di tahap ini:

• Room lock management beserta log history-nya: 🔗 Github link
• Video playlist: 🔗 Github link
• Mencari tiket termurah + weather info: 🔗 Github link
• Game “tap the beat”: 🔗 Github link

Oh ya, saya juga punya beberapa tips dalam mengerjakan technical assignment:

• Jangan terpaku dengan requirement yang diberikan. Improvise! Buat mereka terkesan. Boleh kita “langgar” asal punya reasoning kita sendiri.
• Jangan segan bertanya bila requirement kurang jelas.
• Jangan lupa tulis test (unit, integration, etc)
• Pastikan README jelas dan mudah dibaca
• Lampirkan link demo online di README. Bisa menggunakan Netlify, Vercel, dkk.
• Dan yang paling penting, jangan habiskan lebih dari 8 jam. Mereka sadar kok code ini bukan code terbaik kita dan tidak mencerminkan kapasitas asli kita. Mereka tahu waktu luang yang kita miliki juga berharga.

Technical Interview

Technical interview dilakukan setelah pihak perusahaan merasa oke dengan assignment kita. Selain ditanya mengenai hal-hal umum seputar frontend development, beberapa technical decision saat mengerjakan assignment juga akan ikut disinggung. Ini dimaksudkan agar mereka tahu betul bahwa kita benar-benar aware akan segala keputusan teknikal yang diambil.

Di bawah ini adalah catatan saya tentang hal-hal yang ditanyakan saat technical interview dengan XXX (related repo: https://github.com/dewey92/flight-weather\). Sesuai janji di awal artikel, pertanyan-pertanyaan tersebut saya tuangkan dalam format list.

• We’re not Typescript folks but, I’m curious what are some downsides of using Typescript?
  • My answer:
    • Sometimes it yields cryptic error messages
    • Need some time to be productive
• How to protect your API keys in frontend? (they were concerned about this)
  • My answer: Well I can exclude the .env file from git of course, but eventually, since it’s client-side app, everyone can see those keys with devtools. So there’s no way to do it in the frontend. Possible solution is to create a proxy server and hit the required services with your API keys from there
  • Their response: You’re right
• How would you refactor calling a URL with many query strings? (they were concerned about this)
  • My answer: I’m not sure actually. But I’ll try using new URL
  • Their response: Yes, you can use new URL. But you can also pass a config object containing params to axios third argument
• What’s your strategy to avoid API rate limit?
  • My answer: Create a Redis server to cache the result. That’s what we did for some projects
  • Their answer: Yeah could be, but before that we can use throttling
• How do you test a legacy project that’s quite large?
  • My answer: Let’s say I’m working on a feature. What I’d do is just ask PO or stakeholders about the business rules or requirements around that feature along with the potential behaviour changes being introduced when it’s finally implemented. Those are the ones I would test first. Then if time permits, the components I touch
• Can you explain how Promise actually works?
  • My answer: Can’t say much, but I think it’s run after the stack is empty (?) TBH I’m not sure. Can’t give a detailed answer
  • Their response: Cool no problem
• How do you draw the line between using a State Management Library and just using local state?
  • My answer:
    • Use SML when you have a shared state consumed by many components
    • Use SML when you have a state that’s changed rapidly. SML usually has a diffing algorithm
    • Go with React Context when the state is needed by children deep inside the tree, AND the state is not changed rapidly
    • Otherwise, use local state, and just pass down to children
• What are common problems when dealing with async calls?
  • My answer: Let me think for a second.. I think one instance is when there’s a UI change while data is not done being computed. You can solve this with some sort of AbortController (for HTTP calls), or maybe use Rxjs to make handling async operations easier
• What are your considerations if you’d like to use 3rd party libs and why not writing your own solution? (they were concerned about this)
  • My answer:
    • If possible, I’d go with 3rd party lib, just to reduce maintenance cost
    • Bundle size, but I don’t think that matters anymore since modern libraries support Tree Shaking already
    • Opt for more popular ones, cause it’s just easier for everybody. I mean, everybody learns it
  • Their response:
    • If we only use a bit of their functionalities, just write your own
    • Look for their licenses. Some licenses require its adopters to also open source their work
• Can you describe a process when an object is being spread into another object?
  • My answer: It will just shallow-copy its values. What I mean by shallow-copy is that the values on the first level are copied by value. Any nested values will be copied by reference
• About CSS, how would you prefer writing your own CSS? Are you going to define them in the components (like styled-tag), or use external styles?
  • My answer: I’d just use SCSS and import it from the component. This is called CSS modules. Benefits:
    • A dedicated solution for styling, it’s not all should be in Javascript
    • Editor support
    • BEM convention. Pretty straightforward, UX/UI team is already familiar
    • No global naming clashes
  • Their response: Similar to mine
• Why did you write import * as React from 'react' as opposed to import React from 'react'? (they were concerned about this)
  • My answer: TBH, I only do that for this assignment, I never used it before. I only came across a tweet saying that React doesn’t yet support tree shaking when doing default import. So it’s only specific to React
  • Their response: Yeah we often do named imports instead

Kebetulan di XXX technical interview dilakukan dua kali. Dan interview yang kedua ini lebih berfokus pada pengetahuan level senior saya tentang JS. Alhamdulillah semua bisa saya jawab dengan benar. Beberapa pertanyaan yang saya ingat:

• What is the final value of a? And why?
  • My answer: Stays true, cause a is of the primitives

    let a = true
    let b = a
    b = false

• What’s the output? And why?
  • My answer: undefined, because of scoping

    function bla() {
      console.log(a)
      var a = 10
    }

• What does null == undefined evaluate to?
  • My answer: true. Not a strict equality check
• What’s static method?
  • My answer: The one that belongs to the class, not the instance
• Can you name a few of built-in static methods
  • My answer: Array.from, Object.keys, etc
• How can you iterate over an object
  • My answer: Use Object.entries(obj).map(..). Or for in
• Name a few array methods!
  • My answer: map, filter, reduce
• When would you use array.reduce?
  • My answer: When you want to transform an array into another data structure
• Are you following ES latest features?
  • My answer: Not really, but I know opt chaining & null coalescing
• Can you define a function in JSON?
  • My answer: No
• What’s the data type that exists in JS but not in JSON?
  • My answer: undefined
• Explain shallow copy
  • My answer: First level, copy by value. Otherwise, by reference
• Can you deep clone an object using JSON?
  • My answer: Yes, using JSON.parse(JSON.stringfy(obj))
• How can you delete a key of an object?
  • My answer: Use delete keyword
  • Theirs: Or just use object destructuring
• How can you add a new value to the first element of an array?
  • My answer: Well, array spread [newVal, ...oldArr]
  • Theirs: True. You can also use unshift
• What’s the return of an async function?
  • My answer: Promise
• How would you implement infinite scroll?
  • My answer: Make a little calculation of scrollTop, offsetHeight, etc
  • Theirs: Or utilize IntersectionObserver

Dan masih banyak lagi. Tapi yang lainnya lupa 😅

Final Interview

Biasanya kalau sudah lolos technical interview, kita bisa agak santai sedikit. Final interview ini nggak semenyeramkan technical interview. Sekarang saatnya main cocok-cocokan sama perusahaan. Namun tetap perlu persiapan. Di tahap ini mereka akan mencoba mengenal lebih dekat kepribadian kita, preferensi lingkungan kerja, diskusi mengenai team work, mengenai masalah-masalah umum ketika development yang tidak berhubungan dengan code (misal bagaimana me-manage deadline), atau mengenai motivasi dan value sebagai individu.

Beberapa pertanyaan yang saya ingat:

• Coba cerita dong kenapa mau jadi developer?
• Kenapa mau relocate ke Belanda?
• Apa yang bakal kamu lakukan jika kamu sedang mengerjakan fitur, tapi tiba-tiba ada bug di production? Pada saat yang bersamaan, department lain juga sedang butuh bantuan kamu?
• Bagaimana strategi kamu dalam menyelesaikan suatu proyek?
• Apa hal yang tidak kamu harapkan di tempat kerja yang baru nanti?
• Kamu punya pengalaman di React dan TS, sedangkan kita pake Vue dan JS biasa. Bagaimana menurutmu?

Sebenarnya untuk menjawab pertanyaan-pertanyaan di atas, let it flow aja jawab sesuai dengan pengalaman dan preferensi. Namun yang menurut saya tetap harus dipersiapkan adalah perlunya mengenal diri sendiri, motivasi sehari-hari, tujuan jangka panjang, dan cara kerja yang ideal. Jika sudah tau elemen-elemen tersebut, saya rasa tahap ini akan lancar, insyaallah.

Saya pribadi tidak “lolos” interview terakhir ini. Lebih karena kurang cocok dari segi cara bekerja. Mereka bilang ke saya, “We’re afraid if you end up working here, you will not like us because of the way we work. So we decided not to give you an offer. Do you feel the same way?” Yang kemudian saya jawab, “Yeah I feel it too TBH”. Memang bukan jodoh 😄

Beberapa Tips

Ada beberapa tips yang belum saya sebut yang bisa diaplikasikan saat interview.

• Atur napas sebelum interview. Saya selalu deg-degan setiap kali sebelum interview. Bisa dikurangi dengan menarik napas selama 6 detik, menahannya selama 2 detik, dan menghelanya selama 7 detik
• Don’t try to bluff. Kalau memang tidak tahu akan sesuatu, jawab dengan jujur. Katakan, “I don’t know” atau “Well, from what I know, bla bla bla bla bla. But I’m not even sure if that’s really the case”. Ini bisa jadi nilai plus tersendiri karena kita mampu mengakui bahwa kita memang tidak tahu segalanya.
• Ajak diskusi. Interview itu bukan interogasi. Jadi kalau memang bisa, cobalah ambil alih kemudi interview di saat-saat tertentu. Misal setelah menjawab pertanyaan yang agak sulit, tanyakan, “I don’t know if my aforementioned approach is effecient, what do you think about it?“. Atau misal setelah cerita tentang pengalaman buruk, bisa di-follow-up dengan pertanyaan, “How do you guys as a team handle this sort of situation if one of the team members is having the same problem?”
• Siapkan pertanyaan untuk akhir sesi. Awkward silence sering terjadi di akhir sesi interview, entah karena mereka kehabisan stok pertanyaan, atau memang waktunya aja yang kepanjangan. Situasi ini bisa disiasati dengan menanyakan beberapa hal ke mereka.
  Questions to HR:

  • Is there any performance review for certain periods? What is it like?
  • Are you also open for hiring junior developers?
  • You’ve been at this company for a while. What keeps you motivated?
  • If there’s one thing that you’d like to change at XXX, what would it be?
    Questions to developers:
  • How many products are you maintaining?
  • If they are many, how do you manage to maintain them?
  • How’s the development culture in general? Is it push, push, push? Or is it more relaxed?
  • How do you keep your code nice and clean? And how would you balance that with shipping products?
  • Is there a thing that you perhaps don’t like (working as a developer) and would like to improve?

---

Looking back, dari semua interview yang pernah saya jalani, interview di perusahaan XXX ini yang menurut saya terasa paling menantang karena banyaknya pertanyaan yang diuji. Recruiter saya juga mengaminkan ini (katanya, banyak testimoni dari senior developer yang bilang memang cukup menantang). Walaupun Alhamdulillah hampir semua bisa saya jawab, bahkan lolos sampai final interview. Proses interview di perusahaan lainnya justru lebih banyak seperti mengobrol dan diskusi. Jadi, kalau teman-teman merasa pertanyaan-pertanyaan di atas bisa dijawab, selamat, kamu juga bisa “lolos” interview 😃

Semoga bermanfaat.