एक विदेशी कंपनी से चुनौती या मैं कैसे एक साक्षात्कार में विफल रहा

विदेशी बाजार में अपना हाथ आजमाने का फैसला करने के बाद, मैंने विभिन्न कार्यालयों में रिज्यूमे भेजना शुरू किया। काम खोजने के लक्ष्य के साथ भी नहीं, बस किसी के क्षितिज को व्यापक बनाने के लिए। पसंद जावा डेवलपर की रिक्ति पर गिर गई। मेरे पास भाषा के साथ काम करने का कोई औद्योगिक अनुभव नहीं है, केवल व्यक्तिगत अनुभव, ओरेकल प्रमाणन केंद्र से प्रमाण पत्र, किताबें, आदि। ईमानदारी से, काम के अंतिम स्थान पर डेढ़ साल तक मैंने "फॉरेव" और "इफास" के अलावा कुछ नहीं लिखा (लेकिन यह पूरी तरह से अलग कहानी है), इसलिए मैंने फैसला किया कि वास्तव में क्यों नहीं।

नियोक्ताओं के साथ खोजों और वार्तालापों के इतिहास को छोड़ दें, तो मैं इस मुद्दे पर पहुंचूंगा। सिटी जी की एक कंपनी के ने लिखा कि समस्या का समाधान करने के बाद वे मुझे इंटरव्यू देने में दिलचस्पी ले रहे थे।

जब मैंने फैसला किया और उन्हें समाधान भेजा, तो के ने जवाब दिया कि समीक्षा कोड के बाद उन्होंने मेरे आवेदन पर विचार नहीं करने का फैसला किया। यह मेरे आत्मसम्मान के लिए एक आघात था। बेशक, मैं समझता हूं कि भाषा नई है, और सामान्य तौर पर, कुछ भी हो सकता है, लेकिन मुझे कम से कम अपने फैसले पर प्रतिक्रिया की उम्मीद थी। साथ ही कार्य वास्तव में सरल है ... मुझे आशा है कि आप कार्य में रुचि लेंगे।

नीचे कार्य का मूल पाठ है।

रेस्टुरेंट एक्सर्साइज़

रेस्टुरेंट एक्सर्साइज़ (कृपया जावा 7 सिंटैक्स का उपयोग करें)

आपके रेस्तरां में विभिन्न आकारों की तालिकाओं का एक सेट है: प्रत्येक तालिका 2, 3, 4, 5 या 6 व्यक्तियों को समायोजित कर सकती है। ग्राहक अकेले या समूहों में, 6 व्यक्तियों तक पहुंचते हैं। किसी दिए गए समूह के ग्राहकों को एक साथ एक टेबल पर बैठाया जाना चाहिए, इसलिए आप किसी समूह को केवल एक टेबल पर निर्देशित कर सकते हैं, जो उन सभी को समायोजित कर सकता है। यदि खाली कुर्सियों की आवश्यक संख्या के साथ कोई तालिका नहीं है, तो समूह को कतार में इंतजार करना पड़ता है।

एक बार बैठने के बाद, समूह तालिका को बदल नहीं सकता है, यानी आप नए ग्राहकों के लिए जगह बनाने के लिए एक समूह को दूसरी तालिका से स्थानांतरित नहीं कर सकते।

ग्राहक समूहों को एक अपवाद के साथ आने के क्रम में परोसा जाना चाहिए: यदि बाद में आने वाले छोटे समूह के लिए एक मेज पर पर्याप्त जगह है, तो आप उन्हें कतार में बड़े समूह (ओं) के सामने रख सकते हैं। उदाहरण के लिए, यदि कोई छह-व्यक्ति समूह छह सीट वाली मेज की प्रतीक्षा कर रहा है और एक दो-व्यक्ति समूह कतार में है या पहुंच रहा है तो आप उन्हें सीधे दो खाली कुर्सियों के साथ एक मेज पर भेज सकते हैं।

समूह तालिकाओं को साझा कर सकते हैं, हालांकि यदि उसी समय आपके पास आवश्यक संख्या के साथ एक खाली मेज और पर्याप्त खाली कुर्सियां ​​हैं, तो आपको हमेशा अपने ग्राहक को खाली मेज पर बैठाना चाहिए और किसी को भी आंशिक रूप से नहीं बैठाना चाहिए। , भले ही खाली तालिका समूह के आकार से बड़ी हो।

बेशक प्रणाली मानती है कि किसी भी बड़े समूह को छोटे समूहों को आते देखकर और उनसे आगे अपनी टेबल पाने के लिए ऊब सकते हैं, और फिर छोड़ने का फैसला करेंगे, जिसका मतलब होगा कि वे सेवा किए बिना कतार छोड़ देते हैं।

कृपया RestManager वर्ग को उपयुक्त डेटा संरचनाओं के साथ भरें और इसके निर्माता और तीन सार्वजनिक तरीकों को लागू करें। आपको अन्य कक्षाओं को भी संशोधित करने के लिए प्रोत्साहित किया जाता है (अपनी परीक्षा में हमारी मदद करने के लिए) और अपनी इच्छा पर नए तरीके जोड़ें।

public class Table { public final int size; // number of chairs } public class ClientsGroup { public final int size; // number of clients } public class RestManager { public RestManager (List<Table> tables) { // TODO } // new client(s) show up public void onArrive (ClientsGroup group) { // TODO } // client(s) leave, either served or simply abandoning the queue public void onLeave (ClientsGroup group) { // TODO } // return table where a given client group is seated, // or null if it is still queuing or has already left public Table lookup (ClientsGroup group) { // TODO } } 

टास्क पार्सिंग

कार्य का विश्लेषण करने के बाद, जैसा कि यह मुझे लग रहा था और अब लगता है, ठीक है, कुछ भी जटिल नहीं है। हालांकि, मैं तुरंत दो बिंदुओं पर ध्यान आकर्षित करना चाहता हूं जिन्होंने मुझे थोड़ा भ्रमित किया।

1. "बेशक प्रणाली मानती है कि कोई भी बड़ा समूह छोटे समूहों को आते देखकर और उनसे आगे की टेबल पाने के लिए ऊब सकता है, और फिर छोड़ने का फैसला करेगा, जिसका मतलब होगा कि वे बिना सेवा किए कतार छोड़ दें।"
2. RestManager वर्ग संरचना

पहले पैराग्राफ के बारे में, तथ्य यह है कि हमारी वितरण प्रणाली उपरोक्त नियमों के अनुसार काम करती है, इसलिए पैराग्राफ 1 में वर्णित स्थिति से बचा नहीं जा सकता है। केवल एक चीज जो मैंने प्रतिक्रिया पत्र में लिखी है, वह यह है कि आप एक मुफ्त तालिका जारी करने से पहले एक देरी जोड़ सकते हैं। मान लीजिए कि 3 लोगों का एक समूह एक रेस्तरां में आता है। फिलहाल 6 तारीख को केवल एक टेबल है। अधिवेशन द्वारा, हमें उन्हें एक तालिका प्रदान करनी चाहिए (आपको हमेशा अपने ग्राहक को एक खाली मेज पर बैठाना चाहिए ... भले ही खाली तालिका समूह के आकार से बड़ी हो)। लेकिन अगर आप इसे तुरंत नहीं करते हैं, लेकिन लगभग 5 मिनट के बाद करते हैं। इस समय के दौरान, एक मौका है, भले ही वह छोटा हो, जिसमें एक सीट या टेबल कम आयाम के साथ मुक्त हो। लेकिन यह निश्चित रूप से तुच्छ लगता है।
दूसरे बिंदु के लिए, कम से कम IMHO, सार्वजनिक टेबल लुकअप विधि अपनी कक्षा में नहीं है। हमें एक क्लाइंट से गेट के साथ एक टेबल मिल सकती है, जो विचार के अनुसार, टेबल के लिए एक लिंक स्टोर करना चाहिए।

सामान्य तौर पर, मैंने दो मुख्य बिंदुओं पर प्रकाश डाला:

1. आपको तालिकाओं को सही क्रम में क्रमबद्ध करने की आवश्यकता है। वांछित तालिका खोजने का तर्क आसानी से छँटाई में स्थानांतरित किया जा सकता है। पहली तालिका जो ग्राहकों के एक समूह को समायोजित कर सकती है और आवश्यक होगी।
2. केवल दो घटनाओं के लिए एक तालिका या एक ग्राहक के लिए एक तालिका खोजना आवश्यक है। यह एक नए क्लाइंट का आगमन है और समूह के अनुसार तालिका के अनुसार छोड़ दिया।

दरअसल पूरी समस्या ऊपर सूचीबद्ध दो बिंदुओं तक कम हो जाती है। वैसे, संग्रह का उपयोग करने का कोई फायदा नहीं है। कतार एक कतार है, और, किसी भी हालत में, किसी भी कतार को सेवित किया जा सकता है, जो मुक्त स्थानों और समूह के आकार पर निर्भर करता है, और परिणामस्वरूप, हम कतार से संबंधित विधियों का उपयोग नहीं करेंगे।

मैं एक समाधान के साथ git का लिंक छोड़ता हूं: RestaurantTask